ZFS-Backup: Best Practices

ZFS vereint Dateisystem, Volume-Manager und RAID in einem einzigen Speicher-Stack. Da StateWarden auf Block-/Geräteebene arbeitet, bedeutet der Schutz eines ZFS-basierten Systems, das richtige Blockgerät als Backup-Quelle auszuwählen. Dieser Artikel erklärt, was auf ZFS-Hosts zu sichern ist, was ein ZVOL-Backup enthält und welche Auswahlfehler zu vermeiden sind.

1. ZVOLs vs. Datasets

ZFS stellt zwei Arten von Speicherobjekten bereit:

• Datasets sind Objekte auf Dateisystemebene, die in den Verzeichnisbaum eingehängt werden (zum Beispiel /tank/home). Sie enthalten Dateien und Verzeichnisse und besitzen keine Blockgeräte-Repräsentation.
• ZVOLs (ZFS Volumes) sind Blockgeräte, die mit zfs create -V erstellt werden. Ein ZVOL wird typischerweise als Festplatte einer virtuellen Maschine, als Backing Device für eine iSCSI-LUN oder als rohes Volume für eine Datenbank verwendet.

Unter Linux erscheint jedes ZVOL unter zwei Gerätepfaden:

• /dev/zvol/<pool>/<name> - ein stabiler, menschenlesbarer Symlink (zum Beispiel /dev/zvol/tank/vm-100).
• /dev/zd<N> - das zugrunde liegende Kernel-Blockgerät (zum Beispiel /dev/zd0).

Identifizieren Sie ZVOLs bei der Konfiguration von Backup-Quellen anhand ihres /dev/zvol/...-Pfads. Der Pfad kodiert Pool- und Volume-Name und bleibt daher über Neustarts hinweg stabil, während sich die zd-Nummerierung ändern kann, wenn Geräte hinzugefügt oder entfernt werden. Im Dashboard erscheinen ZVOLs in der Volume-Liste des Tabs Speicher & Backups des Geräts neben den anderen Blockgeräten.

StateWarden ist ein Backup-Agent auf Blockebene. Er schützt ZVOLs direkt. Ein gemountetes Dataset (ein Verzeichnisbaum wie /tank/home) kann er nicht erfassen, weil ein Dataset kein Blockgerät ist. Befinden sich schützenswerte Daten in einem Dataset, migrieren Sie sie in ein Dateisystem auf einem ZVOL.

2. Empfohlen: Das ZVOL sichern

Bei jedem Backup-Lauf auf einem ZVOL nutzt StateWarden native ZFS-Snapshots, um eine konsistente Quelle zu erhalten. Copy-on-Write macht die Snapshot-Erstellung bei ZFS praktisch verzögerungsfrei und unterbricht keine Schreibvorgänge auf der Speicherschicht. Das Backup erfasst daher ein exaktes, eingefrorenes Image des Volumes auf Blockebene aus einem einzigen Zeitpunkt.

Was ein ZVOL-Backup liefert:

• Ein Image des Volume-Inhalts zu einem bestimmten Zeitpunkt, dedupliziert und komprimiert auf dem Speicherknoten wie jedes andere Backup auf Blockebene.
• Wiederherstellungsgranularität pro Volume: Sie können ein einzelnes ZVOL wiederherstellen, ohne den Rest des Pools anzufassen.

Was es nicht liefert:

• Dateisemantik auf Dataset-Ebene. Das Backup enthält die rohen Bytes des Blockgeräts - also das Dateisystem, das der Gast oder die Anwendung innerhalb des ZVOL geschrieben hat. Es enthält nicht die Dataset-Hierarchie des Pools oder Metadaten auf ZFS-Ebene.
• ZFS-Snapshot-Historie. Lokale Snapshots des ZVOL werden nicht auf den Speicherknoten übertragen. Das Backup ist ein Image auf Blockebene, kein ZFS-Replikationsstream. Eine Wiederherstellung reproduziert das Volume zum Backup-Zeitpunkt, nicht die lokale Snapshot-Kette, Klone oder ZFS-Eigenschaften wie recordsize oder compression.

3. Keine Pool-Member-Festplatten sichern

Fügen Sie die physischen Festplatten, aus denen ein ZFS-Pool besteht (zum Beispiel /dev/sdc), keiner Backup-Richtlinie hinzu. Es gilt dasselbe Prinzip wie bei physischen LVM-Volumes und Software-RAID-Mitgliedern (siehe LVM Backup Best Practices).

Ein Pool verteilt seine Daten in Transaktionsgruppen (TXGs) gestriped über seine Vdevs. Die Sicherung einzelner Member-Festplatten eines aktiven Pools erfasst jede Festplatte in einem anderen Transaktionsgruppen-Zustand. Bei der Wiederherstellung lassen sich die Festplatten nicht zu einem konsistenten Pool zusammensetzen, und das Ergebnis ist Datenkorruption. Beachten Sie außerdem, dass ZFS-Redundanz (Mirror, RAIDZ) ein Verfügbarkeitsmechanismus ist, kein Backup: Wählen Sie die ZVOLs aus und lassen Sie Pool-Member-Festplatten unzugewiesen.

4. VM- und Datenbank-Workloads auf ZVOLs

Ein snapshot-basiertes Backup eines ZVOL ist crash-konsistent: Das erfasste Image entspricht dem Zustand, den Sie nach einem unerwarteten Stromausfall sehen würden. Moderne Dateisysteme und Datenbanken stellen sich aus diesem Zustand automatisch wieder her, aber crash-konsistent ist nicht dasselbe wie anwendungskonsistent. Puffer, die die Anwendung im Arbeitsspeicher hält, sind nicht Teil des Images.

Für Workloads, die anwendungskonsistent sein müssen, legen Sie sie rund um das Backup-Fenster still:

• Virtuelle Maschinen: Nutzen Sie den Guest Agent oder den Filesystem-Freeze-Mechanismus des Hypervisors, damit der Gast seine Dateisysteme zum Backup-Zeitpunkt durchschreibt, und planen Sie Backups in Phasen geringer Gast-I/O.
• Datenbanken: Koordinieren Sie den nativen Flush- oder Hot-Backup-Mechanismus der Datenbank (zum Beispiel ein Flush mit Read-Lock) mit dem Backup-Zeitplan - oder akzeptieren Sie Crash-Konsistenz und verifizieren Sie sie durch regelmäßige Test-Wiederherstellungen.

Die allgemeine Regel: Die Speicherschicht friert die Blöcke ein; für einen sauberen Anwendungszustand in diesem Moment ist der Workload selbst verantwortlich.

5. Zusammenspiel von Kompression und Deduplizierung

ZFS-Kompression (compression=lz4 und ähnliche) ist auf der Blockschicht transparent. Lesezugriffe auf ein ZVOL liefern den logischen, dekomprimierten Inhalt, sodass die Backup-Pipeline dieselben Bytes sieht, die der Gast oder die Anwendung geschrieben hat. Zwei praktische Konsequenzen:

• ZFS-Kompression auf dem ZVOL hilft weder noch schadet sie den Deduplizierungs- und Kompressionsraten auf Backup-Seite. Richten Sie Ihre Speichererwartungen an den Workload-Daten selbst aus, nicht an den compressratio-Werten auf Pool-Ebene.
• Daten, die oberhalb der Blockschicht bereits komprimiert oder verschlüsselt sind - Archive, Mediendateien, Datenbanken mit interner Kompression oder Festplattenverschlüsselung auf Gast-Ebene - verschlechtern die Deduplizierungs- und Kompressionsraten, genau wie auf jedem anderen Volume-Typ.

6. Anwendbarkeit von Smart CBT

Smart CBT basiert unter Linux auf dm-era-Change-Tracking und gilt nicht für ZVOLs. ZVOLs werden für die Konsistenz nativ gesnapshottet und während des Backups vollständig gelesen; die Speichereffizienz kommt von der Deduplizierung auf Blockebene, nicht vom Changed-Block-Tracking. Das Dashboard meldet den CBT-Status jedes Volumes; die Statusindikatoren und das Fallback-Verhalten beschreibt Smart CBT: Incremental Backups.

7. Zusammenfassung: Checkliste