Seiten: [1] 
|
 |
|
|
Autor
|
Thema: BTRFS - Inkrementelle Subvolumen Backups (Gelesen 859 mal)
|
|
Sebastian
YaBB God
 Offline
Einträge: 815
|
 |
BTRFS - Inkrementelle Subvolumen Backups
« 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 Eintrag, die als Einstieg neben der offiziellen Dokumentation 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.
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!
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.
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.
Beispiel:
# 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.
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:
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.
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
|
| « Letzte Änderung: 23. Mai 2025, 15:52:51 von Sebastian » |
 Gespeichert
|
Wo die digitale Kultur blüht, nutzen Angreifer Emotionen, Gewohnheiten und Markenbindung aus. Der Schutz beginnt nicht mit Technik, sondern mit Bewusstsein. Wer sich informiert, vorsichtig klickt und sichere Tools nutzt, kann auch unbeschwert an der Digitalkultur teilnehmen.
|
|
|
Sebastian
YaBB God
Offline
Einträge: 815
|
|
Weshalb btrfs send/receive gegenüber rsync bei einem btrfs vorzuziehen ist.
« Antwort #1 am: 27. November 2025, 15:59:42 »
|
|
Einleitung:
Hallo Suletuxe,
heute möchte ich anhand eines einfachen Beispiels den Unterschied zwischen den Optionen -p und -c bei btrfs send erläutern. Beide Parameter greifen tief in das Replikationsverhalten ein, werden aber oftmals missverstanden. Besonders wenn bereits mehrere Snapshots existieren, lohnt sich ein genauer Blick auf das Zusammenspiel.
TLDR;
-p legt fest, welches Delta gesendet wird.
-c erlaubt das Klonen identischer Blöcke aus einem anderen Snapshot.
In Kombination prüft -c nur noch jene Blöcke, die durch -p überhaupt übertragen werden müssten.
Hauptteil:
Die folgende Ausgangslage beschreibt drei Snapshots aus zwei Subvolumes:
- H2: Parent-Snapshot von @home
- H3: Ziel-Snapshot von @home
- R3: Snapshot des Subvolumes @
Im Parent-Snapshot H2 besteht die Datei notes.txt aus Block A („Hallo Welt“) und Block B („Dies ist alt“).
Im Ziel-Snapshot H3 wurde Block B durch Block C („Dies ist neu“) ersetzt.
Snapshot R3 enthält Block A ebenfalls, jedoch in einer anderen Datei und in anderem Kontext.
1. Verhalten von btrfs send -p H2 H3
Mit dem Parent-Parameter wird ein reiner Delta-Stream erstellt. Btrfs vergleicht ausschließlich H2 und H3:
- Block A ist unverändert → keine Übertragung
- Block B wurde zu Block C ersetzt → Block C wird gesendet
- Andere Snapshots (z. B. R3) bleiben unberücksichtigt
Ergebnis: Nur Block C wird übertragen.
2. Verhalten von btrfs send -c R3 H3
Ohne Parent-Snapshot muss H3 vollständig übertragen werden. Zusätzlich versucht Btrfs jedoch, Blöcke aus dem Clone-Source R3 zu übernehmen:
- Metadaten von H3 müssen vollständig gesendet werden
- Block A existiert identisch in R3 → wird per Klon referenziert
- Block C ist neu → muss gesendet werden
Ergebnis: Metadaten + Block C, wobei Block A geklont wird.
3. Verhalten von btrfs send -p H2 -c R3 H3
Die Kombination beider Optionen führt zu einem zweistufigen Ablauf:
- -p bestimmt das Delta → einzig Block C ist relevant
- -c prüft nur diese Delta-Blöcke auf Klonbarkeit
- Block C existiert nicht in R3 → muss übertragen werden
- Block A wird nicht betrachtet, da es durch das Delta ausgeschlossen ist
Ergebnis: Identisch zu -p allein → nur Block C wird übertragen.
Beispiele:
# Delta-Send zwischen Snapshots
btrfs send --compressed-data -p H2 H3 | btrfs receive /mnt/backup
# Full-Send mit Klon-Quelle
btrfs send --compressed-data -c R3 H3 | btrfs receive /mnt/backup
# Kombiniert: Delta + Clone-Source
btrfs send --compressed-data -p H2 -c R3 H3 | btrfs receive /mnt/backup
|
|
Fazit:
btrfs send/receive ist bei Btrfs-Dateisystemen dem klassischen rsync klar überlegen. Das Verfahren arbeitet extentbasiert, nutzt Copy-on-Write intern aus, erhält Hardlinks sowie Snapshot-Strukturen und überträgt ausschließlich geänderte Blöcke. Dadurch entstehen kleinere, präzisere und wiederholbare Backup-Streams. Während rsync Dateien vergleicht und neu schreibt, arbeitet btrfs send dateisystemnah und optimal auf die Architektur abgestimmt.
Quellenangabe:
LG
Sebastian
|
| « Letzte Änderung: 27. November 2025, 16:36:29 von Sebastian » |
Gespeichert
|
Wo die digitale Kultur blüht, nutzen Angreifer Emotionen, Gewohnheiten und Markenbindung aus. Der Schutz beginnt nicht mit Technik, sondern mit Bewusstsein. Wer sich informiert, vorsichtig klickt und sichere Tools nutzt, kann auch unbeschwert an der Digitalkultur teilnehmen.
|
|
|
Seiten: [1] 
|
|
|
|
|
|
|
