RAID-Backup: Best Practices

Ein Linux-Server mit Software-RAID (mdadm) stellt mehrere Blockgeräte gleichzeitig bereit: die physischen Member-Festplatten (/dev/sda, /dev/sdb), den assemblierten Verbund (/dev/md0) und, falls partitioniert, die Partitionen auf dem Verbund (/dev/md0p1, /dev/md0p2). Die Wahl der richtigen Backup-Quelle entscheidet darüber, ob Ihre Backups konsistent und speichereffizient sind und sich für eine Bare Metal Recovery eignen.

Diese Anleitung erklärt, welches Gerät Sie auswählen, warum das Dashboard die falschen blockiert und wie Sie Dimensionierung und Wiederherstellungen für jedes RAID-Level planen.

1. Sichern Sie den assemblierten Verbund (/dev/mdX)

Regel: Wählen Sie als Backup-Quelle immer das assemblierte RAID-Volume (z. B. /dev/md0).

Im StateWarden Dashboard werden physische Festplatten, die zu einem Verbund gehören, als RAID-Mitglieder gekennzeichnet, und Backup-Aktionen auf ihnen sind deaktiviert. Das assemblierte Volume /dev/mdX ist als gültiges Backup-Ziel gelistet, und seine Detailansicht zeigt die Verbundstruktur einschließlich RAID-Level und Anzahl der Member-Festplatten (zum Beispiel ein RAID-5-Volume mit 3 Mitgliedern).

Die Sicherung des assemblierten Volumes bietet Ihnen:

1. Konsistenz: Das Backup liest ein logisches Gerät, sodass jeder Block aus demselben Zeitpunkt stammt.
2. BMR-Tauglichkeit: Die Sicherung des gesamten Geräts /dev/md0 erfasst die Partitionstabelle (GPT/MBR) und den Bootsektor zusammen mit den Daten. Bei der Wiederherstellung erscheinen die Partitionen (p1, p2, ...) automatisch wieder, und das System ist bootbereit.
3. CBT-Effizienz: Changed Block Tracking arbeitet auf dem einzelnen logischen Gerät (siehe Abschnitt 4).
4. Einfachheit: Eine Backup-Richtlinie pro Verbund statt einer pro Partition.

Die Verbundstruktur (RAID-Level, Anzahl der Mitglieder, Chunk-Größe) wird als Metadaten mit dem Backup gespeichert, sodass die Recovery-Umgebung weiß, wie der Container auf neuer Hardware zu rekonstruieren ist.

2. Warum Member-Festplatten ausgeschlossen sind

Die Sicherung einzelner Member-Festplatten (/dev/sda, /dev/sdb) eines aktiven Verbunds ist blockiert, weil sie sowohl verschwenderisch als auch unsicher ist:

• Doppelte Daten: Auf RAID 1 und RAID 10 hält jede Spiegelhälfte eine identische Kopie der Daten. Das Sichern der Mitglieder würde dieselben Daten einmal pro Spiegel speichern, ohne zusätzlichen Schutz zu bieten. Auf RAID 5 und RAID 6 enthalten die Mitglieder Paritätsfragmente, die außerhalb des Verbunds bedeutungslos sind.
• Inkonsistenter Verbundzustand: Jedes Mitglied würde zu einem anderen Zeitpunkt gelesen. Die Wiederherstellung von Mitgliedern, die Minuten auseinanderliegen, ergibt einen desynchronisierten Verbund und kann das Dateisystem irreparabel beschädigen.
• Kein eigenständiger Wert: Eine einzelne Member-Festplatte kann für sich allein nicht zu einem brauchbaren Dateisystem wiederhergestellt werden. Die Daten ergeben nur als assembliertes logisches Volume einen Sinn.

Deshalb blendet das Dashboard RAID-Member-Festplatten für Backup-Zwecke aus: Das assemblierte Volume ist das einzige Ziel, das ein wiederherstellbares Backup erzeugt.

3. RAID-Level und Backup-Dimensionierung

Planen Sie Speicherkontingente und Backup-Fenster anhand der logischen Volume-Größe, nicht anhand der Summe der physischen Festplatten. Die beiden Werte unterscheiden sich auf jedem Level außer RAID 0:

(N = Anzahl der Member-Festplatten, S = Größe eines Mitglieds.)

Hinweise zu den einzelnen Levels:

• RAID 0: Die logische Größe entspricht der Summe der Member, aber es gibt keine Redundanz. Der Ausfall eines einzelnen Mitglieds zerstört den Verbund; das Backup ist damit der einzige Schutz. Halten Sie die Aufbewahrung strikt ein und testen Sie Wiederherstellungen regelmäßig.
• RAID 1: Das logische Volume hat die Größe einer Festplatte. Würden Sie Ihren Backup-Plan anhand der physischen Festplatten dimensionieren, überschätzten Sie den Bedarf um den Faktor zwei.
• RAID 5 / RAID 6: Die Kapazität eines beziehungsweise zweier Mitglieder entfällt auf Parität. Das Backup deckt nur das logische Volume ab; Parität wird nie gesichert, weil sie bei der Neuerstellung des Verbunds automatisch wieder aufgebaut wird.
• RAID 10: Das logische Volume entspricht der Hälfte der Summe der Member.

Der tatsächlich belegte Speicher wird durch Deduplizierung weiter reduziert. Richten Sie Ihre Erwartungen an den Daten auf dem logischen Volume aus und lassen Sie die Deduplizierung für sich arbeiten.

Was ist mit der Sicherung einzelner Partitionen (/dev/md0p1)?

Sie können eine einzelne Partition des Verbunds statt des gesamten Geräts sichern, aber das ist eine Option für Fortgeschrittene. Ein Partitions-Backup enthält nur die Daten innerhalb dieser Partition - es zeichnet nicht auf, wo die Partition auf der Festplatte beginnt oder endet. Nach einem Festplattenwechsel müssen Sie das exakte Partitionslayout manuell neu erstellen (fdisk/gdisk), bevor Sie wiederherstellen. Für den vollständigen Systemschutz sichern Sie das gesamte Gerät /dev/md0.

4. Smart CBT auf RAID-Volumes

Smart CBT (Changed Block Tracking) funktioniert auf assemblierten md-Volumes genauso wie auf einfachen Festplatten: Sie aktivieren es pro Volume über den CBT-Schalter im Tab Speicher & Backups des Geräts, das erste Backup nach der Aktivierung läuft als Vollscan zum Aufbau der Baseline, und nachfolgende Backups verarbeiten nur geänderte Blöcke.

Die Verfolgung eines einzelnen logischen /dev/mdX-Geräts ist deutlich effizienter als die getrennte Verfolgung mehrerer Partitionen oder Member-Festplatten, sodass ein aktiviertes Verbund-Volume selbst auf Arrays mit mehreren Terabyte kurze inkrementelle Backup-Fenster ermöglicht.

Beachten Sie, dass das Deaktivieren von CBT die Tracking-Metadaten zerstört und das nächste Backup zum Neuaufbau der Baseline auf einen Vollscan zurückfällt. Aktivierungsschritte, Fallback-Verhalten und Fehlerbehebung behandelt Smart CBT: Incremental Backups.

5. Verschlüsselte Volumes auf RAID (LUKS auf md)

Ein verbreitetes Härtungslayout platziert LUKS oberhalb von RAID: Die crypto_LUKS-Partition liegt auf dem assemblierten Gerät /dev/mdX. Das Dashboard kennzeichnet solche Volumes mit einem Verschlüsselungs-Badge.

StateWarden sichert verschlüsselte Volumes als rohe verschlüsselte Container auf Blockebene, was auf RAID zwei praktische Konsequenzen hat:

• Keine Deduplizierung und kein effektives CBT: Verschlüsselte Blöcke weisen hohe Entropie auf, sodass jedes Backup des verschlüsselten Volumes als Synthetisch Voll läuft. Planen Sie Backup-Fenster und Kontingente bei jedem Lauf für die volle logische Größe.
• Wiederherstellungen liefern das Volume weiterhin verschlüsselt zurück: LUKS-Header und Daten kommen exakt so zurück, wie sie zum Backup-Zeitpunkt waren. Entsperren Sie das wiederhergestellte Volume mit der ursprünglichen Passphrase.

Das vollständige Verfahren, einschließlich der Überlegungen bei Hardware-Wechseln, dokumentiert Restore Guide: Encrypted Drives (BitLocker & LUKS).

6. Wiederherstellung auf RAID-Ziele

Standard-Wiederherstellung: Zuerst den Verbund assemblieren

Der Zielverbund muss existieren und assembliert sein, bevor Sie die Wiederherstellung starten. Wenn Sie ein RAID-Volume-Backup im Dashboard auswählen, erinnert Sie eine Warnung daran, dass das Wiederherstellungsziel ein vorkonfigurierter RAID-Verbund gleicher oder größerer Kapazität sein muss. In der Praxis:

1. Erstellen und assemblieren Sie den Zielverbund mit mdadm, sodass er als /dev/mdX erscheint.
2. Stellen Sie sicher, dass das assemblierte Volume mindestens die Kapazität des ursprünglichen logischen Volumes bereitstellt.
3. Wählen Sie als Wiederherstellungsziel das assemblierte Volume - niemals eine einzelne Member-Festplatte.

Bare Metal Recovery auf RAID

Für eine vollständige Systemwiederherstellung auf neuer Hardware booten Sie die Maschine von der Recovery ISO, wie im Bare Metal Recovery Walkthrough beschrieben. Bei RAID-Backups liest die Recovery-Umgebung die mit dem Backup gespeicherte Verbundstruktur und übernimmt den Container für Sie:

1. Sie ordnen die ursprünglichen Member-Festplatten den neuen physischen Festplatten der Maschine zu.
2. Der Verbund wird auf den neuen Festplatten mit dem ursprünglichen RAID-Level, der Mitgliederzahl und der Chunk-Größe neu erstellt.
3. Die Backup-Daten werden in den assemblierten Verbund gestreamt; nicht zugewiesener Platz wird übersprungen.
4. Bootloader- und EFI-Anpassungen werden angewendet, damit das wiederhergestellte System auf der neuen Hardware bootet.

Warnungen:

• BMR ist destruktiv: Alle vorhandenen Daten und Partitionstabellen auf den ausgewählten Zielfestplatten werden unwiderruflich überschrieben.
• Stellen Sie mindestens so viele physische Festplatten ausreichender Größe bereit, wie der ursprüngliche Verbund Mitglieder hatte.
• Unterbrechen Sie den Prozess nicht zwischen der Verbund-Erstellung und dem Abschluss des Datenstroms; ein teilweise geschriebener Verbund kann nicht gebootet werden.

7. Zusammenfassung: Checkliste

Wenn Ihr Speicher-Stack zusätzlich LVM verwendet - oberhalb von RAID oder auf einfachen Festplatten - gilt dasselbe Prinzip „das Logische zuerst". Die LVM-spezifischen Regeln beschreibt LVM Backup Best Practices.

StateWarden: Resilience Engineered.