So konfigurieren Sie Btrfs Send und Receive für inkrementelle Offsite-Backups

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

How to Configure Btrfs Send and Receive for Incremental Off-Site Backups - Zima Store Online

Mit Btrfs send und receive lassen sich schreibgeschützte Subvolume-Snapshots zu einer effizienten Replikationskette an einem externen Standort verbinden. Bei der ersten Übertragung wird ein vollständiger Snapshot gesendet. Spätere Übertragungen verwenden einen zuvor replizierten Snapshot als übergeordneten Snapshot, sodass nur die zur Rekonstruktion des neuen Snapshots erforderlichen Änderungen über das Netzwerk übertragen werden.

Stellen Sie unter ZimaOS zunächst sicher, dass sowohl die Quelle als auch das externe Ziel tatsächlich Btrfs-Dateisysteme sind und dass SSH-Zugriff verfügbar ist. Der aktuelle Leitfaden zu Datenträgerformaten von ZimaSpace führt BTRFS-Unterstützung mit Lese- und Schreibzugriff auf, und der SSH-Leitfaden für ZimaOS zeigt, wie Sie den Terminalzugriff im Entwicklermodus aktivieren.

Backup-Kette vor dem Start verstehen

Btrfs send/receive dient der Replikation von Subvolumes, nicht dem Kopieren beliebiger Verzeichnisse. Die Quelle muss ein Btrfs-Subvolume sein, und jeder verwendete Snapshot btrfs send muss schreibgeschützt sein. Ein schreibgeschütztes Einhängen ist kein Ersatz für einen schreibgeschützten Subvolume-Snapshot.

Die offizielle Dokumentation zu btrfs send beschreibt zwei Modi. Eine vollständige Übertragung enthält den gesamten Snapshot. Eine inkrementelle Übertragung verwendet -p oder -c mit Snapshots, die auf Sender und Empfänger im selben Zustand verfügbar sind.

Für eine einfache Kette zu einem externen Standort verwenden Sie ein explizites übergeordnetes Subvolume mit -p:

snapshot-A  --vollständiges Senden-->  externes snapshot-A
snapshot-B  --send -p A-->  externes snapshot-B
snapshot-C  --send -p B-->  externes snapshot-C

Löschen oder ändern Sie das aktuelle übergeordnete Subvolume nicht, bevor die nächste inkrementelle Übertragung abgeschlossen und überprüft wurde.

Quelle als Btrfs-Subvolume überprüfen

Ersetzen Sie die Beispielpfade durch die tatsächlichen Einhängepunkte auf Ihrem System. Das Snapshot-Verzeichnis sollte sich außerhalb des aktiven Quell-Subvolumes befinden, damit Backup-Snapshots nicht innerhalb der zu schützenden Daten verschachtelt werden.

findmnt -no FSTYPE --target /mnt/pool/data
sudo btrfs subvolume show /mnt/pool/data
sudo btrfs version

Der erste Befehl sollte melden btrfs. Das zweite muss erfolgreich identifizieren /mnt/pool/data als Subvolume. Falls es nur ein normales Verzeichnis ist, halten Sie hier an: btrfs send kann kein beliebiges Verzeichnis senden.

Führen Sie dieselbe Dateisystemprüfung auf dem externen System für den Empfangsort aus. btrfs receive muss sein repliziertes Subvolume auf einem Btrfs-Dateisystem erstellen.

SSH vor der Übertragung von Backup-Daten vorbereiten

Ein Offsite-Send-Stream besteht aus binären Dateisystemdaten. SSH ist ein praktischer Transportweg, da es Authentifizierung und Verschlüsselung während der Übertragung bietet. Wenn Sie ZimaOS auf einem der beiden Endpunkte verwenden, aktivieren Sie zuerst SSH und testen Sie eine normale Anmeldung, bevor Sie einen Btrfs-Stream starten.

ssh backup@backup.example.net

Verwenden Sie für unbeaufsichtigte Jobs eine schlüsselbasierte SSH-Authentifizierung. Das Remote-Konto muss außerdem btrfs receive nicht interaktiv. Lassen Sie keinen Remote- sudo Passwortabfrage, die aus derselben Standardeingabe gelesen wird, die auch den Btrfs-Stream überträgt. Eine eng begrenzte Berechtigungsregel für den erforderlichen Empfangsvorgang ist sicherer als ein umfassender passwortloser Root-Zugriff.

Erstellen Sie das Zielverzeichnis während einer interaktiven Administrationssitzung:

ssh -t backup@backup.example.net \
  'sudo mkdir -p /mnt/backup/btrfs-recv'

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Den ersten schreibgeschützten Snapshot erstellen

Erstellen Sie einen festen schreibgeschützten Snapshot des aktiven Quell-Subvolumes. Das -r Dieses Flag ist wichtig, weil Btrfs-Inkrementalsendvorgänge von Snapshots abhängen, die sich während des Sendevorgangs nicht ändern dürfen.

sudo mkdir -p /mnt/pool/.snapshots

sudo btrfs subvolume snapshot -r \
  /mnt/pool/data \
  /mnt/pool/.snapshots/data-20260831-1000

Bestätigen Sie die Eigenschaft vor dem Senden:

sudo btrfs property get \
  /mnt/pool/.snapshots/data-20260831-1000 ro

Das erwartete Ergebnis ist ro=true.

Den ersten vollständigen Snapshot außerhalb des Standorts senden

Der erste Transfer hat kein übergeordnetes Element und ist daher ein vollständiger Send-Vorgang. Aktivieren Sie in einer Bash-kompatiblen Shell pipefail macht einen Fehler auf einer der beiden Seiten der Pipeline für die aufrufende Shell sichtbar.

set -o pipefail

sudo btrfs send \
  /mnt/pool/.snapshots/data-20260831-1000 \
  | ssh backup@backup.example.net \
  'sudo -n btrfs receive /mnt/backup/btrfs-recv'

Wenn sudo -n auf dem Remote-Host fehlschlägt, beheben Sie die Einrichtung der Remote-Berechtigungen, bevor Sie es erneut versuchen. Ersetzen Sie dies nicht durch eine Passwortabfrage innerhalb der Streaming-Pipeline.

Die offizielle Dokumentation zu btrfs receive weist darauf hin, dass ein erfolgreich empfangenes Subvolume schreibgeschützt wird. Außerdem wird davor gewarnt, den Empfangspfad zu ändern, während ein Stream angewendet wird.

Überprüfen Sie den empfangenen Snapshot, bevor Sie ihn als übergeordnetes Element verwenden

Gehen Sie nicht davon aus, dass eine beendete SSH-Sitzung bedeutet, dass die Backup-Kette intakt ist. Prüfen Sie beide Snapshots:

sudo btrfs subvolume show \
  /mnt/pool/.snapshots/data-20260831-1000

ssh backup@backup.example.net \
  'sudo -n btrfs subvolume show \
  /mnt/backup/btrfs-recv/data-20260831-1000'

Notieren Sie auf dem Sender den Snapshot UUIDAuf dem Empfänger sollte das replizierte Subvolume diese Quellkennung als seine Empfangene UUIDBestätigen Sie außerdem, dass das empfangene Subvolume schreibgeschützt ist.

Erst nach dieser Prüfung sollte data-20260831-1000 das übergeordnete Element für das nächste inkrementelle Backup werden.

Den nächsten inkrementellen Snapshot erstellen und senden

Nachdem sich die Live-Daten geändert haben, erstellen Sie einen neuen schreibgeschützten Snapshot:

sudo btrfs subvolume snapshot -r \
  /mnt/pool/data \
  /mnt/pool/.snapshots/data-20260901-0200

Senden Sie dann nur die Änderungen seit dem vorherigen Snapshot:

set -o pipefail

sudo btrfs send \
  -p /mnt/pool/.snapshots/data-20260831-1000 \
  /mnt/pool/.snapshots/data-20260901-0200 \
  | ssh backup@backup.example.net \
  'sudo -n btrfs receive /mnt/backup/btrfs-recv'

Dies funktioniert, weil der übergeordnete Snapshot der ersten Übertragung auf beiden Systemen in übereinstimmender Form weiterhin vorhanden ist. Nachdem der neue Snapshot erfolgreich empfangen und überprüft wurde, data-20260901-0200 kann zum übergeordneten Snapshot des folgenden Durchlaufs werden.

Die übergeordneten Snapshots identisch halten

Die häufigste Ursache für eine unterbrochene inkrementelle Kette ist, den Schreibschutzstatus oder den Inhalt eines Snapshots zu ändern, der als übergeordneter Snapshot verwendet wird. Btrfs erfasst empfangene Snapshots mit einer empfangenen UUID, damit Sender und Empfänger die zugehörige Historie identifizieren können.

Die offizielle Btrfs-Dokumentation zu Subvolume-Flags und empfangenen UUIDs warnt davor, dass das Ändern eines empfangenen Snapshots von schreibgeschützt auf beschreibbar die Annahmen verletzt, die für inkrementelle Übertragungen verwendet werden.

Machen Sie daher den Offsite-Empfangssnapshot nicht beschreibbar, nur um Dateien zu durchsuchen, wiederherzustellen oder zu bearbeiten. Wenn Sie eine beschreibbare Wiederherstellungskopie benötigen, erstellen Sie einen separaten Snapshot aus dem geschützten Empfangssnapshot:

sudo btrfs subvolume snapshot \
  /mnt/backup/btrfs-recv/data-20260901-0200 \
  /mnt/restore/data-20260901-0200

Der neue Wiederherstellungssnapshot ist standardmäßig beschreibbar, während der ursprüngliche Empfangssnapshot für zukünftige inkrementelle Übertragungen unverändert bleibt.

Eine sichere Aufbewahrungsregel für Snapshots verwenden

Sie müssen nicht jeden alten Snapshot für immer aufbewahren, aber Sie müssen auf beiden Systemen den übergeordneten Snapshot behalten, den die nächste Übertragung benötigt. Eine einfache Rotationsregel lautet:

Erstellen Sie den neuen schreibgeschützten Quell-Snapshot.
Senden Sie ihn unter Verwendung des letzten erfolgreich übertragenen Snapshots als -p.
Überprüfen Sie den neuen Offsite-Empfangssnapshot.
Setzen Sie den neuen Snapshot als nächsten übergeordneten Snapshot fest.
Erst dann entfernen Sie ältere Wiederherstellungspunkte gemäß Ihrer Aufbewahrungsrichtlinie.

Mehrere historische Snapshots können nützliche Wiederherstellungspunkte bieten. Denken Sie jedoch daran, dass ein Snapshot auf demselben Dateisystem kein unabhängiges Backup ist. Die Offsite-Replik ist wertvoll, weil sie eine weitere Kopie auf einem separaten System und an einem anderen Standort erstellt. Der 3-2-1-Backup-Leitfaden von ZimaSpace erklärt, warum eine Offsite-Kopie vor Ausfällen schützt, die durch lokale Redundanz nicht abgedeckt werden können.

Verschachtelte Btrfs-Subvolumes separat behandeln

Btrfs-Snapshots sind bei verschachtelten Subvolumes nicht rekursiv. Wenn /mnt/pool/data enthält ein weiteres Subvolume, enthält der übergeordnete Snapshot lediglich einen Subvolume-Platzhalter anstelle eines vollständigen Snapshots der verschachtelten Daten.

Listen Sie die Subvolumes auf, bevor Sie den Backup-Plan festlegen:

sudo btrfs subvolume list /mnt/pool

Wenn wichtige Anwendungsdaten in verschachtelten Subvolumes liegen, erstellen und replizieren Sie für jedes davon eine separate Kette schreibgeschützter Snapshots.

Wissen, wann Sie -p und wann Sie -c verwenden sollten

Für eine lineare Backup-Historie -p ist die einfachste und am leichtesten zu prüfende Option. Die Option -c Mit der Option können Sie eine oder mehrere Klonquellen hinzufügen, über die Btrfs passende Extents aus zusätzlichen Snapshots wiederverwenden kann. Diese Klonquellen müssen jedoch ebenfalls auf beiden Seiten exakt im gleichen Zustand vorhanden sein.

Wenn Sie nicht nachweisen können, dass eine Klonquelle unverändert ist und auf beiden Systemen vorhanden ist, verwenden Sie sie nicht. Eine einfache Kette mit einem übergeordneten Snapshot ist für einen Offsite-Backup-Auftrag in der Regel sicherer.

Optional: Protokoll 2 für komprimierte Extents verwenden

Bei ausreichend aktuellen Linux- und btrfs-progs-Versionen kann Btrfs-Sendeprotokoll 2 komprimierte Extents effizienter übertragen mit --compressed-data. In der offiziellen Dokumentation zum Senden steht, dass Protokoll 2 auf Sender und Empfänger btrfs-progs 6.0 oder höher sowie auf dem Sender Linux 6.0 oder höher erfordert.

sudo btrfs send \
  --proto 2 \
  --compressed-data \
  -p /mnt/pool/.snapshots/data-20260831-1000 \
  /mnt/pool/.snapshots/data-20260901-0200 \
  | ssh backup@backup.example.net \
  'sudo -n btrfs receive /mnt/backup/btrfs-recv'

Aktivieren Sie diese Option nicht nur, weil sie vorhanden ist. Überprüfen Sie zuerst die Versionen auf beiden Endpunkten und verwenden Sie das Standardprotokoll, wenn Kompatibilität wichtiger ist als Optimierung.

Häufige Fehler bei inkrementellen Send- und Receive-Vorgängen beheben

Der Send-Befehl meldet, dass der Snapshot nicht schreibgeschützt ist

Erstellen Sie den Snapshot neu mit btrfs subvolume snapshot -r. Das bloße Einhängen eines beschreibbaren Snapshots über einen schreibgeschützten Mount erfüllt die Voraussetzung für das Senden nicht.

Die inkrementelle Übertragung kann ihren übergeordneten Snapshot nicht finden oder verwenden

Vergewissern Sie sich, dass der exakt passende übergeordnete Snapshot noch auf dem Sender vorhanden ist und der zugehörige empfangene Snapshot noch auf dem Empfänger existiert. Wurde einer der übergeordneten Snapshots gelöscht, geändert oder beschreibbar gemacht, stellen Sie einen passenden übergeordneten Snapshot wieder her, falls Sie einen haben. Andernfalls erstellen Sie einen neuen schreibgeschützten Snapshot und beginnen Sie mit einer neuen vollständigen Ausgangssicherung.

btrfs receive meldet, dass das Ziel-Subvolume bereits existiert

btrfs receive überschreibt kein vorhandenes Subvolume mit demselben eingehenden Namen. Prüfen Sie zuerst das vorhandene Subvolume. Wenn es sich um einen fehlgeschlagenen oder unvollständigen Empfang handelt und Sie bestätigt haben, dass es sicher gelöscht werden kann, löschen Sie dieses unvollständige Subvolume, bevor Sie dieselbe Übertragung erneut versuchen.

Der Empfangs-Parent wurde nach seinem Eintreffen geändert

Verwenden Sie diesen geänderten Snapshot nicht als Grundlage für einen neuen inkrementellen Stream. Wenn kein unveränderter, passender Empfangs-Parent vorhanden ist, starten Sie eine neue vollständige Backup-Kette.

Dateien in einem verschachtelten Verzeichnis fehlen im Snapshot

Prüfen Sie, ob dieses Verzeichnis selbst ein Btrfs-Subvolume ist. Verschachtelte Subvolumes werden nicht rekursiv in den übergeordneten Snapshot aufgenommen und benötigen ihre eigene Send/Receive-Kette.

Die WAN- oder SSH-Verbindung bricht während einer Übertragung ab

Den Empfang als fehlgeschlagen behandeln, sofern er nicht erfolgreich abgeschlossen wurde und das resultierende Subvolume nicht ordnungsgemäß verifiziert wird. Die dokumentierte Btrfs-Schnittstelle für Send/Receive-Befehle bietet keine Option zum Fortsetzen eines Streams. Bei unzuverlässigen Verbindungen über große Entfernungen sollten Sie erwägen, den Send-Stream in eine Staging-Datei zu schreiben, diese Datei mit einem fortsetzbaren Transport zu übertragen und anschließend die vollständige, vertrauenswürdige Datei an btrfs receive.

Die Empfangsseite vor nicht vertrauenswürdigen Streams schützen

Btrfs receive wendet Dateisystemoperationen aus dem eingehenden Stream an. Die offizielle Dokumentation zu receive rät davon ab, Send-Streams aus nicht vertrauenswürdigen Quellen anzunehmen, und empfiehlt, den Empfangspfad während der Verarbeitung eines Streams vor gleichzeitigen Schreibvorgängen zu schützen.

SSH-Host-Verifizierung, schlüsselbasierte Authentifizierung, ein dediziertes Backup-Konto und die geringstmöglichen praktikablen Berechtigungen verwenden. Das Empfangsverzeichnis während eines laufenden Backups aus normalen Schreibpfaden von Benutzern heraushalten.

Diese Checkliste für jeden inkrementellen Lauf verwenden

Bestätigen, dass beide Endpunkte Btrfs verwenden.
Den neuen Quell-Snapshot erstellen mit -r.
Den zuvor erfolgreichen übergeordneten Snapshot auf beiden Systemen unverändert lassen.
Senden mit btrfs send -p OLD NEW.
Über eine authentifizierte und verschlüsselte SSH-Verbindung empfangen.
Erfolg verifizieren und die Quell-UUID mit der empfangenen UUID des Empfängers vergleichen.
Den empfangenen Backup-Snapshot schreibgeschützt lassen.
Erstellen Sie einen separaten beschreibbaren Snapshot, wenn Sie Daten wiederherstellen oder testen müssen.
Alte Snapshots erst rotieren, nachdem der neue übergeordnete Snapshot verifiziert wurde.
Verschachtelte Subvolumes mit separaten Ketten sichern.

Sobald ein vollständiger Seed-Lauf und ein inkrementeller Lauf manuell erfolgreich waren, automatisieren Sie dieselbe Abfolge mit Protokollierung und expliziten Prüfungen des Exit-Status. Entscheidend ist nicht der Scheduler, sondern dass an beiden Enden jedes inkrementellen Schritts ein unveränderter, verifizierter übergeordneter Snapshot erhalten bleibt.