• [^] # Re: Faut pas rêver

    Posté par . En réponse au journal devenez un développeur linux. Évalué à 7.

    Le format de backup de btrfs est documenté et assez clair (c’est grosso-modo un journal de modifications, pas un dump brut du FS).

    Ce qu’apporte btrfs c’est qu’il sait à priori bien mieux qu’un outil externe ce qui a changé depuis le dernier snapshot, le tout en gérant au poil la concurrence (modification pendant la sauvegarde). De fait, la notion de snapshot est un truc assez central dans btrfs et s’adapte particulièrement bien à la problématique. Les outils classiques qui ne se basent pas sur le FS sont obligés de :

    • soit faire un diff complet à la volée entre la source et la destination... ce qui interdit de fait de chiffrer les sauvegardes sur la machine d’origine sans que la machine de destination ait la possibilité de déchiffrer
    • soit garder l’état en mémoire, ce qui est une horreur d’un point de vue maintenance (par exemple avec duplicity, si tu veux ne garder que les clés de chiffrement sur la machine, et garder les clé de déchiffrement hors-site et hors-ligne, c’est un bordel incroyable si l’index local est corrompu/perdu : il faut le télécharger depuis la machine de sauvegarde sur la machine qui possède les clé de déchiffrement, déchiffrer les index, les renvoyer sur la machine original)

    Et dans les deux cas gérer le cas « modification du FS pendant qu’on sauvegarde » est un vrai cauchemar. Bon OK c’est pas moi qui gère ça mais les devs de duplicity/rdiff-backup/unison/whatever, mais quitte à faire confiance à une tierce partie je préfère faire confiance à btrfs (qui par design est bien mieux équipé pour gérer ce cas de figure) qu’à des devs externes qui doivent gérer toute cette complexité sans aide du FS.