LVM-Backup: Best Practices

Die meisten Linux-Server-Distributionen organisieren ihren Speicher über den Logical Volume Manager (LVM). LVM abstrahiert physische Festplatten zu flexiblen virtuellen Partitionen, doch diese Abstraktion verändert, was ein Backup-Agent lesen muss, um ein konsistentes, wiederherstellbares Image zu erzeugen. Die Wahl der falschen Ebene führt zu Backups, die sich nicht wiederherstellen lassen.

Diese Anleitung erklärt, welche LVM-Ebene StateWarden schützt, wie sich konsistente Snapshots und Change Tracking auf LVM-Volumes verhalten und was bei der Wiederherstellung oder dem Neuaufbau eines Systems zu beachten ist.

1. LVM-Ebenen und die Regel für logische Volumes

LVM organisiert Speicher in drei Ebenen:

1. Physical Volumes (PV): Die zugrunde liegenden Festplatten oder Partitionen, die LVM einbindet (zum Beispiel /dev/sda2, von Werkzeugen wie lsblk mit dem Typ LVM2_member angezeigt).
2. Volume Groups (VG): Ein Pool aus Speicherkapazität, aggregiert aus einem oder mehreren PVs.
3. Logical Volumes (LV): Die virtuellen Partitionen, die aus einer VG herausgeschnitten werden und auf denen Dateisysteme und Daten tatsächlich liegen (zum Beispiel /dev/vg0/root oder /dev/mapper/vg0-data).

Wählen Sie als Backup-Quelle immer das logische Volume. Ein LV ist ein reguläres Blockgerät mit einer stabilen Begrenzung: Es hat ein Dateisystem, eine definierte Größe und lässt sich snapshotten. In der Speicheransicht des Geräts im Dashboard erscheinen PVs als abgeschwächte Pool-Mitglieder und werden nicht als einzelne Backup-Ziele angeboten; die darüber liegenden LVs sind die auswählbaren Geräte.

Die Sicherung eines einzelnen LV (etwa data) ermöglicht auch dessen unabhängige Wiederherstellung, ohne andere LVs (etwa root) in derselben VG anzufassen.

2. Warum physische Volumes keine gültigen Backup-Ziele sind

Das direkte Lesen eines PV (etwa das Imagen von /dev/sda2) ergibt kein brauchbares Backup:

• Kein konsistenter Zeitpunkt. Ein roher PV-Lesezugriff erfasst Sektoren, während das System darauf schreibt. LVM-Metadaten-Header und Dateisystemdaten können mitten in einer Aktualisierung erwischt werden, und das Ergebnis ist möglicherweise nicht wiederherstellbar. Ein PV kann für sich allein nicht gesnapshottet werden.
• Unvollständige Daten bei gruppenübergreifenden Festplatten. Wenn eine VG über mehrere PVs gespannt oder gestriped ist, enthält ein einzelnes PV nur Fragmente jedes LV. Die Rekonstruktion der VG würde alle PVs erfordern, erfasst exakt zum selben Zeitpunkt - auf einem laufenden System unmöglich.
• Keine Wiederherstellung pro Volume. Ein PV-Image mischt die Extents aller LVs der VG, sodass einzelne Volumes nicht selektiv wiederhergestellt werden können.

3. Konsistente Backups mit LVM-Snapshots

StateWarden nutzt den nativen LVM-Snapshot-Mechanismus für crash-konsistente Backups logischer Volumes:

1. Bevor der Agent das Volume liest, erstellt er einen temporären LVM-Snapshot des Quell-LV. Ein Snapshot präsentiert eine eingefrorene Sicht des Volumes zu einem bestimmten Zeitpunkt; LVM leitet nachfolgende Schreibvorgänge auf dem Ursprung per Copy-on-Write um, sodass sich der Snapshot-Inhalt während des Backups nicht verändert.
2. Der Agent liest die Backup-Daten vom Snapshot-Gerät statt vom Live-Ursprung. Datenbanken und Dateien werden exakt so erfasst, wie sie zum Snapshot-Zeitpunkt waren, selbst wenn das Backup selbst lange dauert.
3. Nach Abschluss des Auftrags wird der temporäre Snapshot entfernt.

Hinweise für den Betrieb:

• Klassische LVM-Snapshots verbrauchen Platz in der VG, sobald sich der Ursprung während des Backup-Fensters verändert. Halten Sie genügend freie Extents in der VG vor, um das erwartete Schreibvolumen für die Dauer eines Backups abzufangen; ein Snapshot, dem der Platz ausgeht, wird ungültig und das Backup schlägt fehl.
• Konsistenz auf Anwendungsebene ist ein separates Thema. Nutzen Sie für Datenbanken deren native Flush- oder Quiesce-Hooks, wo verfügbar; der LVM-Snapshot garantiert ein crash-konsistentes Image, kein anwendungsseitig stillgelegtes.

4. CBT-Verhalten auf LVM-Volumes

Auf einfachen Partitionen beschleunigt Smart CBT inkrementelle Backups, indem geänderte Blöcke zwischen den Läufen verfolgt werden. Logische LVM-Volumes verhalten sich anders: LVM stellt native Snapshot-Mechanismen bereit, die der Agent zur Identifikation geänderter Daten nutzt, sodass der separate CBT-Wrapper auf einem LV nicht erforderlich ist.

Entsprechend meldet der CBT-Schalter in der Speicheransicht des Geräts im Dashboard für LVM-Volumes den folgenden Tooltip:

LVM verwendet native Snapshots. CBT-Wrapper nicht erforderlich.

Das ist eine Information, kein Fehler. Inkrementelle Backups von LVM-Volumes laufen weiterhin; die Änderungserkennung wird lediglich über die eigenen Snapshot-Mechanismen von LVM bereitgestellt statt über den Wrapper für einfache Partitionen. Hintergrundinformationen zur Funktionsweise von Smart CBT auf anderen Volume-Typen finden Sie in Smart CBT: Incremental Backups und Smart NTFS and Block-Level Backups.

5. Thin-Provisioned Volumes

Bei LVM Thin Provisioning wird Kapazität bei Bedarf aus einem Thin-Pool zugewiesen, statt sie jedem Volume vorab fest zuzuordnen. Thin-LVs werden wie jedes andere logische Volume gesichert, beachten Sie jedoch Folgendes:

• Snapshot-Platz kommt aus dem Thin-Pool. Snapshots von Thin-Volumes verbrauchen Pool-Kapazität, sobald während des Backup-Fensters Daten geschrieben werden. Überwachen Sie die Pool-Auslastung und halten Sie Reserve vor; ein erschöpfter Thin-Pool kann die Ursprungsvolumes beeinträchtigen, nicht nur den Snapshot.
• Virtuelle Größe vs. reale Daten. Ein Thin-LV kann eine virtuelle Größe präsentieren, die weit über der physischen Kapazität des Pools liegt. Wiederherstellungsziele werden anhand der virtuellen Größe des LV bemessen (siehe Abschnitt 6); planen Sie den Zielspeicher entsprechend, wenn Sie ein Thin-Volume auf andere Hardware verschieben.

6. Was auszuschließen ist

Nicht jedes Blockgerät in einem LVM-System ist schützenswert:

• Snapshot-Volumes. Fügen Sie LVM-Snapshot-Geräte (weder die temporären Snapshots von StateWarden noch manuell erstellte) nicht als Backup-Quellen hinzu. Der Copy-on-Write-Inhalt eines Snapshots ist flüchtig und redundant; das Sichern von Snapshots von Snapshots verschwendet Speicher und erzeugt Images ohne eigenen Wiederherstellungswert. Sichern Sie stattdessen den Ursprungs-LV.
• Swap-Volumes. Swap enthält nur flüchtige Speicherseiten ohne Wert nach einem Neustart. Swap-Geräte sind vom Change Tracking ausgeschlossen und sollten keiner Backup-Richtlinie zugewiesen werden. Ein Swap-LV wird beim Neuaufbau ohnehin trivial neu erstellt.

7. Hinweise zur Wiederherstellung

LVM-Volumes werden auf Blockebene wiederhergestellt, was dem Ziel Größenregeln auferlegt:

• Gleiche Größe oder größer. Der Ziel-LV muss mindestens so groß sein wie der Quell-LV zum Backup-Zeitpunkt. Ein Image auf Blockebene kann nicht auf einen kleineren LV wiederhergestellt werden; erstellen Sie den Ziel-LV mit ausreichender Größe, bevor Sie die Wiederherstellung starten.
• Dateisystem anschließend vergrößern. Bei der Wiederherstellung auf einen größeren LV behält das wiederhergestellte Dateisystem seine ursprüngliche Größe. Vergrößern Sie es nach der Wiederherstellung, um den zusätzlichen Platz zu nutzen (zum Beispiel xfs_growfs für XFS oder resize2fs für ext4, je nach Dateisystemtyp).
• LVM vor der Wiederherstellung auf neuen Systemen neu erstellen. Verfügt die Zielmaschine noch nicht über das benötigte VG- und LV-Layout, erstellen Sie es zuerst mit den üblichen LVM-Werkzeugen (pvcreate, vgcreate, lvcreate) und stellen Sie anschließend die Volume-Inhalte in den neuen LVs wieder her.

8. Bare Metal Recovery auf LVM-basierten Systemen

Der Schutz logischer Volumes statt physischer Festplatten verhindert keine vollständige Systemwiederherstellung auf leerer Hardware. Smart BMR zeichnet das Speicher-Layout des geschützten Systems zusammen mit den Volume-Daten auf. Während einer Bare-Metal-Wiederherstellung führt die Recovery-Umgebung Folgendes aus:

1. Booten der Zielmaschine von der StateWarden Recovery ISO.
2. Anzeigen der verfügbaren leeren physischen Festplatten zur Auswahl.
3. Neu erstellen der LVM-Struktur (physische Volumes, Volume Groups und logische Volumes) aus den im Backup gespeicherten Layout-Informationen.
4. Wiederherstellen der gesicherten Daten in die neu erstellten LVs und Anwenden der Bootloader-Anpassungen, die das System bootfähig machen.

Das vollständige Verfahren, einschließlich der Vorbereitung des Recovery-Mediums und der Token-Generierung, beschreibt der Bare Metal Recovery Walkthrough.

Zusammenfassung: Checkliste