Btrfs Send/Receive: Effiziente inkrementelle Backups auf Blockebene

1. Warum blockbasierte inkrementelle Backups den Unterschied machen

Klassische Backup Werkzeuge wie rsync ermitteln Änderungen, indem sie den kompletten Dateibaum von Quelle und Ziel durchlaufen und Metadaten wie Größe und Änderungszeitpunkt vergleichen. Bei Verzeichnissen mit Millionen kleiner Dateien, wie sie etwa in Magento Media Verzeichnissen oder Log Archiven entstehen, wird allein dieser Vergleichsvorgang zum Flaschenhals, noch bevor überhaupt ein einziges Byte an Nutzdaten übertragen wurde.

Btrfs Send und Receive löst dieses Problem an der Wurzel, weil der Kernel die Unterschiede zwischen zwei Snapshots direkt aus der internen B Baum Struktur des Dateisystems liest, statt Dateien einzeln zu vergleichen. Das Ergebnis ist ein Datenstrom, der ausschließlich die tatsächlich geänderten Blöcke enthält und sich beliebig komprimieren, verschlüsseln oder über eine Pipe direkt an ein Zielsystem weiterreichen lässt.

2. Wie send und receive grundsätzlich funktionieren

btrfs send erzeugt aus einem read only Snapshot einen binären Datenstrom, der alle notwendigen Operationen enthält, um denselben Zustand auf einem anderen Btrfs Dateisystem wiederherzustellen, etwa das Anlegen von Dateien, das Schreiben bestimmter Blöcke oder das Setzen von Metadaten. Dieser Stream wird nicht direkt interpretiert, sondern muss auf der Empfängerseite mit btrfs receive wieder in ein tatsächliches Subvolume umgewandelt werden.

Beide Kommandos lassen sich über eine einfache Pipe verbinden, wenn Quelle und Ziel auf demselben System liegen, oder über SSH koppeln, wenn das Ziel auf einem entfernten Server liegt. Wichtig ist dabei, dass sowohl der Quell Snapshot als auch der eventuell für inkrementelle Übertragung benötigte Eltern Snapshot zum Zeitpunkt des Sendens read only sein müssen, da Btrfs sonst keine konsistente Ausgangslage garantieren kann.

# Vollstaendigen Snapshot lokal auf ein anderes Btrfs Dateisystem uebertragen
btrfs send /.snapshots/mysql-2026-08-08 | btrfs receive /mnt/backup

# Direkt per SSH auf einen entfernten Server uebertragen
btrfs send /.snapshots/mysql-2026-08-08 \
  | ssh backup-host btrfs receive /mnt/backup

3. Vollständige gegenüber inkrementellen Snapshots

Eine vollständige Übertragung mit btrfs send ohne weitere Optionen überträgt jeden einzelnen Block des Snapshots und ist entsprechend nur für die allererste Synchronisation oder sehr kleine Datenmengen sinnvoll. Für den laufenden Betrieb kommt stattdessen die inkrementelle Variante mit der Option -p zum Einsatz, die einen Eltern Snapshot als Referenzpunkt angibt und nur die Blöcke überträgt, die sich seit diesem Referenzpunkt tatsächlich geändert haben.

Voraussetzung für eine inkrementelle Übertragung ist, dass der als Elternteil verwendete Snapshot bereits identisch auf der Zielseite vorhanden ist, weil Btrfs die Änderungen relativ zu genau diesem Zustand berechnet. Fehlt der Eltern Snapshot auf der Zielseite oder wurde er dort gelöscht, schlägt die inkrementelle Übertragung fehl und es bleibt nur eine erneute vollständige Übertragung als Ausweg.

# Inkrementelle Uebertragung relativ zum vorherigen Snapshot
btrfs send -p /.snapshots/mysql-2026-08-07 \
  /.snapshots/mysql-2026-08-08 \
  | ssh backup-host btrfs receive /mnt/backup

4. Praxisworkflow: Offsite Replikation einrichten

Ein typischer Replikations Workflow beginnt mit einem einmaligen vollständigen Send zur Erstinitialisierung des Backup Ziels, gefolgt von regelmäßigen inkrementellen Übertragungen, die jeweils den zuletzt erfolgreich übertragenen Snapshot als Elternteil referenzieren. Ein Skript sollte nach jeder erfolgreichen Übertragung den Namen des zuletzt übertragenen Snapshots persistieren, damit der nächste Lauf den korrekten Referenzpunkt kennt.

Für die Übertragung über ein öffentliches Netzwerk empfiehlt sich zusätzlich Kompression auf SSH Ebene sowie ein dedizierter SSH Key mit eingeschränkten Rechten, der auf der Zielseite ausschließlich btrfs receive Aufrufe erlaubt, etwa über eine command= Einschränkung in der authorized_keys Datei.

#!/usr/bin/env bash
# scripts/btrfs-offsite-sync.sh: inkrementelle Offsite Replikation
set -euo pipefail

TS=$(date +%Y-%m-%d)
LAST=$(cat /var/lib/btrfs-sync/last-snapshot)

btrfs subvolume snapshot -r /mnt/data/mysql /.snapshots/mysql-$TS

btrfs send -p /.snapshots/mysql-$LAST /.snapshots/mysql-$TS \
  | ssh -C backup-host btrfs receive /mnt/backup

echo "mysql-$TS" > /var/lib/btrfs-sync/last-snapshot

5. Vergleich zu rsync basierten Backups

Bei der Geschwindigkeit hat Send/Receive einen strukturellen Vorteil, weil keine Datei Metadaten verglichen werden müssen und ausschließlich die tatsächlich geänderten Blöcke den Datenstrom bilden. Bei rsync wächst die Zeit für den reinen Änderungsabgleich mit der Anzahl der Dateien, während sie bei Btrfs Send praktisch unabhängig von der Dateianzahl ist und stattdessen von der Menge der geänderten Blöcke abhängt.

Bei der Konsistenz liegt der Vorteil ebenfalls klar bei Send/Receive: Da die Übertragung auf einem eingefrorenen, read only Snapshot basiert, kann sich der Quellzustand während der laufenden Übertragung nicht mehr ändern. rsync dagegen liest Dateien während des laufenden Betriebs direkt vom lebenden Dateisystem, wodurch sich Dateien zwischen Beginn und Ende eines Laufs ändern können und im schlimmsten Fall inkonsistente Zwischenzustände übertragen werden, insbesondere bei Datenbankdateien ohne separates Locking.

6. Automatisierung und Retention Strategie

Für den produktiven Einsatz sollte die Erstellung neuer Snapshots, deren Übertragung und die Bereinigung alter Snapshots auf beiden Seiten in einem einzigen, idempotenten Skript zusammengefasst werden, das sich über Cron oder einen systemd Timer regelmäßig ausführen lässt. Werkzeuge wie btrbk nehmen genau diese Orchestrierung ab und verwalten Retention Regeln, mehrere Zielsysteme sowie Fehlerbehandlung, ohne dass ein eigenes Skript von Grund auf gepflegt werden muss.

Bei der Retention gilt eine wichtige Einschränkung: Der jeweils älteste noch als Elternteil benötigte Snapshot darf auf keiner Seite gelöscht werden, solange nicht mindestens ein neuerer, bereits vollständig übertragener Snapshot als neue Referenz zur Verfügung steht. Eine unbedachte automatische Bereinigung kann sonst dazu führen, dass die nächste inkrementelle Übertragung fehlschlägt und eine erneute vollständige Übertragung notwendig wird.

7. Fehlerbehandlung und Verifikation der Übertragung

Bricht eine Übertragung durch einen Netzwerkfehler ab, bleibt auf der Zielseite häufig ein unvollständiges, temporäres Subvolume zurück, das mit der Option -e bei btrfs receive und einer erneuten Übertragung ab dem letzten intakten Zustand fortgesetzt werden kann, sofern die Verbindung nur kurzzeitig unterbrochen war. Bei dauerhaft fehlgeschlagenen Übertragungen sollte das unvollständige Subvolume vor einem erneuten Versuch bewusst gelöscht werden, um Inkonsistenzen zu vermeiden.

Da Btrfs bereits beim Lesen jedes Blocks dessen Prüfsumme validiert, wird eine während der Übertragung entstandene Korruption in der Regel spätestens beim nächsten Zugriff auf das empfangene Subvolume erkannt. Für besonders kritische Backups empfiehlt sich dennoch ein regelmäßiger Scrub auf der Zielseite, um Korruption proaktiv statt erst beim tatsächlichen Restore Versuch zu entdecken.

8. Praxisfall: Restore aus einem empfangenen Snapshot

Der eigentliche Restore Vorgang ist bei Send/Receive denkbar einfach, weil das empfangene Subvolume auf der Backup Seite bereits ein vollständig fertiges, direkt einsatzbereites Btrfs Subvolume ist und nicht erst aus einem Archivformat entpackt werden muss. Für einen Restore auf dem Produktivserver genügt es, den gewünschten Snapshot von der Backup Seite zurück zu senden, entweder in umgekehrter Richtung per Send/Receive oder, falls nur ein einzelner Ordner benötigt wird, per gezieltem Kopieren aus dem read only Snapshot heraus.

Für einen vollständigen Notfall Restore, etwa nach einem Hardware Defekt des Produktivservers, empfiehlt sich ein dokumentierter, regelmäßig getesteter Ablauf: neuen Pool oder neues Subvolume vorbereiten, gewünschten Snapshot per Send/Receive von der Backup Seite zurückspielen und anschließend über den Bootloader oder die jeweilige Mount Konfiguration aktivieren. Ein Restore Test, der nur in der Theorie funktioniert, aber nie tatsächlich durchgespielt wurde, ist im Ernstfall meist wertlos.

# Snapshot von der Backup Seite zurueck auf den Produktivserver senden
ssh backup-host btrfs send /mnt/backup/mysql-2026-08-08 \
  | btrfs receive /mnt/data/restore

# Zurueckgespieltes Subvolume an die produktive Stelle setzen
mv /mnt/data/mysql /mnt/data/mysql-old
mv /mnt/data/restore/mysql-2026-08-08 /mnt/data/mysql

9. Best Practices für den produktiven Einsatz

Snapshots, die als Elternteil für inkrementelle Übertragungen dienen, sollten grundsätzlich read only bleiben, da eine nachträgliche Änderung die Grundlage für zukünftige inkrementelle Berechnungen zerstört. Zudem sollte auf beiden Seiten dieselbe Btrfs Kernel Version oder zumindest eine kompatible Feature Menge vorliegen, da neuere Send Stream Formate von älteren Receive Implementierungen nicht immer verstanden werden.

Für die 3-2-1 Backup Regel eignet sich Send/Receive hervorragend als eine der beiden unterschiedlichen Speichertechnologien, sollte aber nicht die einzige Sicherungsmethode bleiben, weil ein grundlegender Fehler in der Btrfs Implementierung theoretisch sowohl Quelle als auch alle darüber erstellten Kopien betreffen könnte. Eine zusätzliche, technologisch unabhängige Sicherung bleibt deshalb auch bei konsequentem Einsatz von Send/Receive sinnvoll.

10. Zusammenfassung

11. FAQ: Btrfs Send/Receive