Sebastian
YaBB God
Offline
Einträge: 575
|
|
Btrfs Subvolume Backups mit restic
« am: 03. Januar 2025, 16:52:50 »
|
|
Hallo Suletuxe,
Seid dem ich Btrfs verwende, habe ich mir Gedanken drum gemacht, wie ich ein möglichst Dateisystem unabhängiges Backup meiner Btrfs Subvolumes machen kann. Mein Hauptaugenmerk lag dabei besonders auf das Subvolumen, das mein Root (/) Verzeichnis beinhaltet. Und zwar so, das die Information das ein Subvolumen auch wirklich ein Subvolumen ist erhalten bleibt. Und nicht im Backup daraus ein ordinäres Verzeichnis wird.
Dadurch fallen die üblichen Methoden und Programme schon mal raus, wie z.B. cp, rsync und co. Sie alle kennen keine Subvolumes und kopieren diese wie normale Verzeichnisse. Auch mein favorisiertes Backup Programm restic das ich gerne wegen der Deduplizierung verwende, scheint das erst einmal augenscheinlich nicht zu können. Aber wie sich später herausstellte dann doch
Die einzige Methode, die ich momentan kenne, um einzelne Subvolumes als ganzes zu übertragen. Ist mit der hauseigenen Funktion btrfs send aus dem Paket btrfs-progs. Dies sendet das Subvolume wahlweise als Stream oder in eine Datei. Und kann dann wiederum mit btrfs receive angenommen bzw. wiederhergestellt werden. Die Kombination zwischen btrfs send und receive ermöglicht es sogar inkrementelle Backups zu machen. Indem btrfs send veranlasst wird nur die Veränderungen zum letzten mal zu schicken.
Dabei gibt es nur ein Problem, ich mag keine Inkrementellen Backups. Diese sind mir einfach zu fehleranfällig, denn wenn nur ein Backup in der Backupkette kaputt ist, so sind alle darauffolgenden auch hinüber. Deswegen bin ich schon lange auf Chunkbasierte bzw. Blockbasierte Backuplösungen umgestiegen. Die durch Deduplizierung noch weniger Speicherplatz verbrauchten, als es mit inkrementellen Backups möglich gewesen wäre und zeitgleich eine Wertigkeit von einem Vollbackup haben, und meistens genauso schnell angelegt werden können wie ein inkrementelles Backup.
restic ist dabei solch ein Backup Programm. Aber wie gesagt, auf dem ersten Blick kennt auch restic keine Subvloumes und macht daraus ganz einfache Verzeichnisse. Aber zum Glück kann restic auch Daten von stdin annehmen. Dies macht restic und btrfs send zu einer unschlagbaren Kombi. Somit können wir mit btrfs send ein Subvolumen in restic Pipen, der dieses mit eventuellen anderen Backups de dupliziert (Also nur Veränderungen gespeichert werden), Komprimiert und in das restic Backup Repostitory ablegt. Genau so können wir dann auch später den gewünschten restic snapshot zurück in btrfs receive pipen der dann wiederum uns unser Subvolumen wiederherstellt.
Einziger Harken an der Sache ist, dass man aus diese Art von Backup nicht eine einzelne Datei, aus dem Backup ziehen kann, sondern nur alles oder nichts. Aber das ist genau das, was ich für mein Root Subvolumen haben möchte. Ein Backup, das im schlimmsten Fall mein System wiederherstellen kann. Mein @home Subvolumen sichere ich ganz klassisch auf die normale restic Methode. Damit ich bei Bedarf einzelne Dateien aus dem Backup ziehen kann.
Dadurch habe ich, weiterhin den Vorteil das nur Daten gesichert werden, die noch nicht im Backup sind (indem der Stream de dupliziert wird) und denn Komfort eines Vollbackups, wo ich nicht alle vorherigen inkrementellen Backups vorhalten muss.
Es folgt ein Beispiel wie ein Backup und Wiederstellungsprozess aussehen könnte. Es wird logischerweise das Root Subvolumen (@) von einem Snapshot gesichert.
Backup eines Subvolumes in ein restic Repository:
# restic --no-cache -r ./backup_repo backup --tag root --stdin-from-command -- btrfs send --compressed-data /.snapshots/@root-20250102173034/
|
|
Wiederherstellung:
# restic --no-cache -r ./backup_repo dump $SNAPSHOT_ID /stdin | btrfs receive $PATH
|
|
Wobei für $SNAPSHOT_ID die Snapshot ID in restics Repository angeben werden muss, das wiederhergestellt werden soll. Und für $PATH ist der Pfad anzugeben wo das Subvolumen landen soll. Hierbei kann es auch quasi umbenannt werden, falls gewünscht. Zum Schluss nur nicht vergessen das Read Only Flag vom Snapshot/Subvolumen zu entfernen (da nur solche gesendet werden können) damit dies auch wieder nutzbar ist.
LG Sebastian
|