Ist btrfs als Backup-Dateisystem geeignet?

Im Moment habe ich eine ziemlich traditionelle Backup-Dateisystemstruktur über ext4. Jedes Mal, wenn eine Sicherung erstellt wird, wird ein neuer Ordner backup-DATEerstellt, in den Dateien synchronisiert werden (mit Hardlinks, die mit der --link-destOption von rsync erstellt wurden ).

Da ich über Bitrot gelesen habe, möchte ich eine Prüfsumme für alle Dateien transparent haben. Anscheinend kann ext4 das nicht, aber btrfs bietet Unterstützung für Datenprüfsummen (und sogar einen integrierten RAID1-Modus). Zunächst möchte ich btrfsein "dummes" Dateisystem verwenden, das Datenprüfsummen unterstützt, ohne die erweiterten Funktionen wie RAID, Subvolume-Snapshots, Senden / Empfangen usw. zu verwenden.

Ihr Wiki weckt jedoch nicht wirklich das Vertrauen in das Dateisystem für Sicherungszwecke:

"Obwohl viele Leute es zuverlässig verwenden, gibt es immer noch Probleme. Sie sollten Backups Ihrer Daten aufbewahren und testen und darauf vorbereitet sein, sie zu verwenden." - Erste Schritte

"Ist btrfs stabil? Lange Antwort: [..] Was auch immer Sie tun, wir empfehlen, gute, getestete Backups außerhalb des Systems (und außerhalb des Standorts) aufzubewahren." - FAQ .

Mein Anwendungsfall ist eine Offline-Sicherung. Aus diesem Grund wird die Festplatte nur sehr wenig genutzt (wie in Stunden) und wird häufig ein- / ausgesteckt (eSATA oder USB 3.0). Ein zuverlässiges Dateisystem ist ein Muss. Es darf nicht schlimmer sein als ext4 wrt. Stromausfälle, unsaubere Abschaltungen usw.

Wird tatsächlich empfohlen, btrfs als Dateisystem für Sicherungszwecke zu verwenden? Gibt es andere Eigenschaften von btrfs, die es möglicherweise weniger (oder mehr) geeignet machen?

Ich werde nur eine kurze Antwort geben, weil ich denke, dass dies überlegt wird.

Wenn Sie das Hauptkernel-Wiki über die btrfs (Unter-) Befehle lesen , werden Sie feststellen, dass es zwei Befehle gibt für:

1. Erstellen eines "Backups" :btrfs-send
2. und wiederherstellen :btrfs-restore

Nur für den Fall, dies bedeutet, dass es sich nicht um ein Backup handelt, sondern um ein Snapshot-Dateisystem mit der Idee, bei Bedarf ein Rollback durchzuführen, nicht als Backup, sondern als "flexibel".

Verwenden Sie es daher - nein, verwenden Sie es nicht als Backup - als versioniertes Dateisystem, in dem Sie Dinge testen und zurückkehren können. Verlasse dich nicht darauf.

Ich hatte kürzlich Probleme mit einem btrfs-Dateisystem auf einem aktuellen Kernel 4.10.0. Das Dateisystem wurde in einer Virtualbox-VM zerstört, weil TRIM anscheinend nicht korrekt implementiert ist, und AFAIK hatte etwas mit den Indexnummern der Subvolumes zu tun. Nach dem Wechsel zu VMware war das Dateisystem immer noch beschädigt und btrfs checkkonnte den Fehler überraschenderweise nicht finden und beheben. Schließlich wechselte ich zurück zu ext4.

Das Gute: Ich habe keine Daten verloren. btrfs scheint zumindest beim Lesen immer konsistent zu sein, aber es hat mir gezeigt, dass es noch weit von der Produktionsbereitschaft entfernt ist.

Auf einem Server verwende ich es trotzdem als Backup-Volume, da ich dort die Funktion des Kuhkopierens für die Deduplizierung benötige (genau Ihr Anwendungsfall). Die Daten sind für ein herkömmliches Dateisystem einfach zu groß.

Aktualisieren

Ich habe immer noch das Dateisystem auf meinem Server (siehe oben), aber es ist gleich kaputt gegangen, nachdem ich dies hier gepostet habe. Jetzt habe ich ein großes schreibgeschütztes Backup-Volume von 700G, das sich auf ext4 auf ~ 7 TB erweitern würde, wenn ich versuche, alles mit zu kopieren tar|tar. Aus Zeitgründen habe ich noch nicht geprüft, ob neuere Kernelversionen damit umgehen können. Das eigentliche Problem ist ein "Transaktionsabbruch", der ~ 2 Sekunden nach dem Mounten beschreibbar auftritt und das schreibgeschützte Volume erneut bereitstellt. Die ursprüngliche Ursache ist vermutlich eine gebrochene Version btrfs-convert, die ich vor verwendet Jahren , als ich dieses Volumen erstellt, und nach wie vor eine begrenzte Funktionsumfang des Stroms , btrfs checkder sollte zumindest in der Lage sein zu finden alle Schäden auf einem Volumen , das reproduzierbar zu einem Transaktionsabbruch führen oder andere Probleme, anstatt nur zu sagen, dass mein Dateisystem fehlerfrei ist.