Titel: BTRFS - Inkrementelle Subvolumen Backups
Beitrag von: Sebastian am 18. Mai 2025, 09:00:31
Vorwort
Hallo Linux Community, ich schreibe dieses Tutorial, um BTRFS Anwendern das meiste aus ihrem BTRFS herauszuholen. In der Absicht, dass dieses Tutorial anderen hilft. Dieses Tutorial richtet sich dabei nicht an Anfängern und ich gehe davon aus, dass typische BTRFS Grundlagen und eigen Begriffe wie Subvolumes, Snapshots etc. bekannt sind. Sollte man also nicht wissen was ein Subvolumen ist, oder worin der Unterschied zwischen ein Subvolumen und eines Snapshot liegt (da gibt es einen kleinen, aber nicht unwesentlichen Unterschied) so empfehle ich euch erst die Grundlagen euch anzueignen.
Die Suletuxe selbst haben dafür in ihrem Wiki auch einen guten offiziellen Dokumentation (https://www.suletuxe.de/wiki/doku.php?id=tutorials:dateisysteme:btrfs:btrfs]Eintrag[/url], die als Einstieg neben der [url=https://btrfs.readthedocs.io/) dienen können
Einführung
In Btrfs können mit den hauseigenen Btrfs Tools send/receive Subvolumen auf ein anderes Btrfs übertragen werden. Dabei werden Metadaten, Reflinks und komprimierte Daten beibehalten. Sodass Daten, die schon auf dem Ziel Btrfs existieren, nicht noch einmal neu übertragen/komprimiert werden müssen. Und da Reflinks auch beibehalten werden, nehmen auch wirklich nur neu hinzugekommene Daten der Snapshots auf dem Zielsystem Speicherplatz ein. eine Deduplizierung auf Extent Ebene ist somit auch gegeben, wenn zuvor ein Referenz Snapshot angeben wurde (Parent Snapshot).
Damit können effektive Depublizierende, Komprimierte, inkrementelle Backups erstellt werden.
[color=Red]Achtung beim Defragmentieren! Sollten auf dem Quell bzw. Zieldatenträger Verzeichnisse/Dateien oder ganze Subvolumes defragmentiert werden wollen, so behaltet im Hinterkopf, dass dadurch die Reflinks zu den Extens auf den die Daten liegen, zerstört werden. Bedeutet, es geht euch die Deduplizierung von Daten verloren, Subvolumes, Snapshots und Dateien, die sich Extens geteilt haben, werden nun unabhängig voneinander betrachtet und nehmen jeweils selbstständig Speicherplatz ein. Hier tritt eine große Dateisystem Überlauf Gefahr auf! [/color]
Daher ist es am besten, falls man vorhat Daten zu defragmentieren, vorher alle Subvolumes zu löschen, die sich Daten mit dem aktuellen Subvolumen, die die zu defragmentieren Daten beinhalten teilen. Damit man keine böse Überraschung bekommt. Das bedeutet aber auch, dass ab diesen Zeitpunkt kein inkrementelles Backup mehr möglich ist, da der Parent Snapshot nach dieser Empfehlung auch gelöscht wurde. Zumindest spart man sich aber die Defragmentierung auf dem Zieldatenträger, da hier sowieso dann noch mal ein volles Backup des letzten Snaphots gesendet werden muss, um wieder inkrementelle Backups machen zu können. Das als ein Datenstrom gesendet wird und somit vom Ziel btrfs Allocator auf dem Datenträger verteilt wird. Und im Nachgang alte Snapshots gelöscht werden können, um wieder Speicherplatz freizugeben.
Einsetzten von Send/Receive
Erstellen eines Snapshots
Hinweis: Es können nur Readonly Subvolumes übertragen werden
|
|
Um also ein Snapshot eines Subvolumen zu erstellen, der auch gleich Readonly ist, verwendet man die -r Option des btrfs subvolume snapshot Befehls.
[color=Red]Wichtig! Denkt daran, falls ihr Verschaltete Subvolumes habt, das diese nicht im Snapshot mit enthalten sind. Da diese Quasi als eigenständige Dateisystemgrenzen angesehen werden. Wenn man hier eine Analogie zu anderen Dateisystemen ziehen möchte. [/color]
Beispiel:
Code:
# btrfs subvolumen snapshot -r /mnt/rootvol/@home /mnt/rootvol/snapshots/home.2025-06-18T120005
|
|
Damit haben wir nun ein Readonly Snapshot unseres @home Subvolumes im Verzeichnis /mnt/rootvol/snapshots/ mit dem Namen home.2025-06-18T120005 angelegt.
Senden und Empfangen des Snapshots
Um diesen Snapshot auf unser Ziel Btrfs zu übertragen, das wir unter /mnt/target gemountet haben. Verwenden wir nun btrfs send mit btrfs receive zusammen.
Dabei möchten wir bereits komprimierte Daten beibehalten, sodass diese auf dem Ziel Dateisystem auch komprimiert ankommen. Dafür verwenden wir die Option --compressed-data. Möchte man dies nicht oder man hat keine komprimierten Daten (aus Sicht eines Btrfs). So möchte man stattdessen die Option --proto 2 hinzugeben, um das effizientere send Protokoll in Version 2 zu verwenden. Dies wird bei der Option --compressed-data automatisch verwendet.
Code:
btrfs send --compressed-data /mnt/rootvol/snapshots/home.2025-06-18T120005 | btrfs receive /mnt/target/
|
|
Der aufmerksame Leser hat hier vielleicht gemerkt, das wir unser Subvolumen hier als Datenstrom über eine Pipe gesendet haben. Das bedeutet also auch, dass wir ganze Subvolumes so über ein Netzwerk zu einem anderem Btrfs senden können.
Senden von Inkrementellen Subvolumes
Jetzt wo wir unser erstes Subvolumen übertragen haben, können wir darauf aufbauen und ab diesen Zeitpunkt nur die Veränderungen eines weiteren Snapshotes senden. Angenommen wir haben in unserem @home Subvolumen etwas geändert und erstellen einen weiteren Snapshot am nächsten Tag davon:
Code:
btrfs subvolume snapshot -r /mnt/rootvol/@home /mnt/rootvol/snapshots/home.2025-06-19T131510
|
|
Nun werden wir hiervon aber nur das diff also nur die Veränderungen verschicken. Dafür geben wir mit der Option -p den Parent (Das Elternteil) Subvolumen vom Vortrag an. Damit hiervon die Veränderungen abgeglichen werden können.
Code:
btrfs send --compressed-data -p /mnt/rootvol/snapshots/home.2025-06-18T120005 /mnt/rootvol/snapshots/home.2025-06-19T131510 | btrfs receive /mnt/target/
|
|
Damit würden nun auf unserem Ziel Btrfs der Snapshot home.2025-06-19T131510 im Root Verzeichnis des Ziel Btrfs das wir unter /mnt/target/ gemountet haben angelegt. Dort werden sich alle Dateien und Verzeichnisse des Vorherigen Snapshots auch befinden, aber nur die Veränderten Daten wurden dabei übertragen. Das liegt daran das Btrfs durch dieses vorgehen automatisch Reflinks zu dem vorherigen Snapshot bildet bzw. beibehält und damit die Verweise auf alle vorherigen Daten noch vorhanden sind. Dabei wird auch nur neuer Speicherplatz für die neuen Daten eingenommen, wie ich weiter oben auch schon erwähnt habe. Somit können mit einem Btrfs sehr Platz Effizente Backups erstellt werden.
Es müssen auch nicht wie bei anderen Backups Strategien die Komplette Snapshot Kette beibehalten werden, um weiter Inkrementelle Backups zu erstellen, wichtig ist immer nur das sich der letzte Snapshot (Parent) auf beiden Btrfs befinden. Damit ein diff erstellt werden kann, um die restliche Logik kümmert sich ein Btrfs selbst drum.
Schlusswort
Wie man hoffentlich erkennt, eignet sich ein Btrfs auch sehr gut um seine Backups aufzubewahren. Nicht nur durch die zusätzliche Integritätsprüfung mithilfe von Checksummen und der Möglichkeit seine Daten auch redundant vorzuhalten. Ist man mit Btrfs auch in der Lage Daten effektiv zu übertragen und Platzsparend zu speichern.
LG Sebastian |
Diskussions- und Newsboard der Linux Interessen Gruppe Suletuxe | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.
|