Btrfs convient-il comme système de fichiers de sauvegarde?

En ce moment, j'ai une structure de système de fichiers de sauvegarde assez traditionnelle au-dessus d'ext4. Chaque fois qu'une sauvegarde est effectuée, un nouveau dossier backup-DATEest créé dans lequel les fichiers sont rsyncés (avec des liens physiques créés en utilisant l' --link-destoption de rsync ).

Depuis que j'ai lu sur bitrot, je voudrais avoir une somme de contrôle pour tous les fichiers, de manière transparente. Apparemment, ext4 ne peut pas faire cela, mais btrfs offre un support pour les sommes de contrôle des données (et même un mode RAID1 intégré). Pour commencer, je voudrais utiliser btrfscomme un système de fichiers "stupide" qui prend en charge les sommes de contrôle des données sans utiliser ses fonctionnalités avancées telles que le RAID, les instantanés de sous-volume, l'envoi / la réception, etc.

Cependant, leur wiki n'inspire pas vraiment confiance dans le système de fichiers à des fins de sauvegarde:

"Bien que de nombreuses personnes l'utilisent de manière fiable, des problèmes subsistent. Vous devez conserver et tester les sauvegardes de vos données et être prêt à les utiliser." - Mise en route

"Btrfs est-il stable? Réponse longue: [..] Quoi que vous fassiez, nous vous recommandons de conserver de bonnes sauvegardes testées hors système (et hors site)." - FAQ .

Mon cas d'utilisation est d'avoir une sauvegarde hors ligne. Pour cette raison, le disque sera très peu utilisé (comme en heures) et sera fréquemment branché / débranché (eSATA ou USB 3.0). Avoir un système de fichiers fiable est indispensable. Il ne doit pas être pire que ext4 wrt. pannes de courant, coupures impures, etc.

Est-il réellement recommandé d'utiliser btrfs comme système de fichiers à des fins de sauvegarde? Y a-t-il d'autres propriétés de btrfs qui peuvent le rendre moins (ou plus) approprié?

— Lekensteyn
source

Voir unix.stackexchange.com/questions/140360/… . Avec BTRFS, vous pouvez utiliser des instantanés de sous-volume au lieu de liens physiques.

— StrongBad

Vous pouvez lire un bon article sur l'utilisation de btrfs ici mais pour les sauvegardes, je recommanderais ZFS (qui se trouve sur les systèmes BSD et Solaris). Vous pouvez également l'utiliser sur le wiki

— kirill-a

@StrongBad un indicateur fiable d'espace libre est certainement quelque chose où btrfs n'excelle pas vraiment. La question n'est cependant pas de remplacer les liens physiques par des instantanés de sous-volume, mais plutôt la fiabilité de btrfs en tant que système de fichiers pour un disque de sauvegarde.

— Lekensteyn

@ kirill-a J'ai envisagé ZFS, mais comme il n'est pas intégré, j'hésite à l'utiliser.

— Lekensteyn

@Lekensteyn Je pense que les instantanés de sous-volume sont qualifiés de "Y a-t-il d'autres propriétés de btrfs qui peuvent le rendre moins (ou plus) approprié comme système de fichiers de sauvegarde?"

— StrongBad

Réponses:

Je vais simplement fournir une réponse courte, car je pense que cela est trop réfléchi.

Si vous lisez le wiki du noyau principal sur les commandes (sous-) btrfs , vous constaterez qu'il existe deux commandes pour:

faire une "sauvegarde" :btrfs-send
et restaurer :btrfs-restore

Au cas où, cela signifie qu'il ne s'agit pas (conçu pour être) une sauvegarde, mais pour être un système de fichiers instantané, avec l'idée de revenir en arrière si nécessaire, non pas comme une sauvegarde mais comme "flexible".

Par conséquent - non, ne l'utilisez pas comme sauvegarde - utilisez-le comme un système de fichiers versionné où vous pouvez tester des choses et revenir en arrière. Ne vous y fiez pas.

— txomon
source

J'ai récemment eu des problèmes avec un système de fichiers btrfs sur un noyau 4.10.0 à jour. Le système de fichiers a été détruit dans une machine virtuelle Virtualbox parce que TRIM ne semble pas être correctement implémenté quelque part, et AFAIK, cela avait quelque chose à voir avec les numéros d'index des sous-volumes. Après le passage à VMware, le système de fichiers était toujours corrompu et, étonnamment, btrfs checkn'a pas pu trouver et corriger l'erreur. Enfin, je suis revenu à ext4.

La bonne chose: je n'ai pas perdu de données. btrfs semble être toujours cohérent au moins pour la lecture, mais cela m'a montré qu'il est encore loin de la préparation à la production.

Quoi qu'il en soit, sur un serveur, je l'utilise toujours comme volume de sauvegarde, car j'ai besoin de la fonction de copie de vache pour la déduplication (exactement votre cas d'utilisation). Les données sont tout simplement trop volumineuses pour un système de fichiers traditionnel.

Mise à jour

J'ai toujours le système de fichiers sur mon serveur (voir ci-dessus), mais il s'est cassé juste après l'avoir posté ici. Maintenant, j'ai un gros volume de sauvegarde en lecture seule de 700G qui s'élèverait à ~ 7 To sur ext4 si j'essaie de tout copier à l'aide tar|tar. Par manque de temps, je n'ai pas encore vérifié si les nouvelles versions du noyau pouvaient le gérer. Le problème réel est un "abandon de transaction" qui se produit environ 2 secondes après le montage en écriture et qui remonte le volume en lecture seule. La cause d'origine est probablement une version cassée de btrfs-convert, que j'ai utilisée il y a des années lorsque j'ai créé ce volume, et encore un ensemble limité de fonctionnalités du courant btrfs checkqui devrait au moins être en mesure de trouver tous les dommages sur un volume qui conduisent de manière reproductible à une interruption de transaction. ou tout autre problème, au lieu de simplement dire que mon système de fichiers est sain.

— Daniel Alder
source