Bare Metal Recovery Planung: Server komplett wiederherstellen

1. Was Bare Metal Recovery bedeutet und warum es anders ist

Ein normales Backup sichert Dateien innerhalb eines laufenden Systems: Datenbanken, Konfigurationen, Webverzeichnisse. Bare Metal Recovery geht einen Schritt weiter und beantwortet die Frage, was passiert, wenn gar nichts mehr da ist, kein Bootloader, keine Partitionstabelle, kein installiertes Betriebssystem. Genau dieser Fall tritt bei einem Festplattendefekt, einem zerstoerten RAID-Controller oder einem physisch beschaedigten Server ein. Ohne einen dokumentierten Plan fuer Bare Metal Recovery beginnt die Wiederherstellung dann mit Raten: welche Partitionsgroessen, welcher Bootloader, welche Kernel-Parameter waren konfiguriert.

Der Unterschied zwischen Datei-Restore und Bare Metal Recovery liegt in der Reihenfolge der Abhaengigkeiten. Ein Datei-Restore setzt voraus, dass Betriebssystem, Netzwerk und Storage bereits funktionieren. Bare Metal Recovery muss diese Schicht selbst wiederherstellen, bevor irgendein Datei-Restore ueberhaupt moeglich ist. Teams, die nur Datenbank-Dumps und Anwendungsdaten sichern, aber keine Strategie fuer Bare Metal Recovery haben, stellen genau bei einem Totalausfall fest, dass die eigentliche Huerde nicht die Daten sind, sondern ein lauffaehiges System, auf das die Daten ueberhaupt zurueckgespielt werden koennen.

2. Die Anatomie eines Totalausfalls: was wirklich verloren geht

Bei der Planung von Bare Metal Recovery hilft es, sich die Bestandteile eines Servers einzeln vor Augen zu fuehren. Verloren gehen koennen die Partitionstabelle selbst (MBR oder GPT), der Bootloader (GRUB2 mit seiner Konfiguration in /boot/grub), der Kernel samt Initramfs, saemtliche Systemkonfigurationen unter /etc, installierte Pakete und deren exakte Versionen, sowie natuerlich die eigentlichen Nutzdaten in Datenbanken und Dateisystemen. Jede dieser Schichten braucht in einem Bare Metal Recovery Plan eine eigene Antwort.

Besonders unterschaetzt wird dabei die Partitionstabelle und das Disk-Layout. Ein Server mit LVM-Volumes, einer separaten /boot-Partition und angepassten Mount-Optionen in /etc/fstab laesst sich nicht einfach aus dem Gedaechtnis rekonstruieren. Wer im Rahmen der Bare Metal Recovery Planung nicht vorher dokumentiert hat, wie die Platten partitioniert waren, verliert im Ernstfall wertvolle Zeit mit Rueckschluessen aus Log-Dateien, die im schlimmsten Fall selbst nicht mehr zugaenglich sind.

3. Inventar erstellen: Disk-Layout, Bootloader und Kernel dokumentieren

Der erste konkrete Schritt jeder Bare Metal Recovery Planung ist ein aktuelles, maschinenlesbares Inventar des Systems. Das umfasst die Ausgabe von lsblk, blkid und parted --list fuer das Disk-Layout, die installierte Bootloader-Version samt /boot/grub/grub.cfg, die geladenen Kernel-Module aus lsmod und die Paketliste aus dpkg --get-selections oder rpm -qa. Diese Dateien sollten automatisiert erzeugt und an einen vom Server unabhaengigen Ort geschrieben werden, denn ein Inventar, das nur auf dem betroffenen Server selbst liegt, ist im Ernstfall wertlos.

Ein gutes Bare Metal Recovery Inventar ist versioniert, damit Aenderungen am Disk-Layout nachvollziehbar bleiben. Wird eine neue Partition angelegt oder eine LVM-Volume-Group erweitert, muss das Inventar automatisch aktualisiert werden, sonst driftet die Dokumentation vom echten Zustand ab und der Recovery-Plan wird beim naechsten Ernstfall wertlos. Ein taeglicher Cronjob, der das Inventar erzeugt und per rsync auf einen anderen Host kopiert, ist der pragmatischste Weg, diese Drift zu verhindern.

#!/usr/bin/env bash
# bare-metal-inventory.sh — capture disk layout and boot config for recovery
set -euo pipefail

readonly OUT_DIR="/var/backup/inventory/$(hostname)"
mkdir -p "$OUT_DIR"

# Disk layout: partitions, filesystems, UUIDs
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT,UUID > "$OUT_DIR/lsblk.txt"
blkid > "$OUT_DIR/blkid.txt"
parted --list > "$OUT_DIR/parted.txt" 2>/dev/null || true

# LVM layout, if in use
if command -v vgs &>/dev/null; then
  vgs -o+vg_uuid > "$OUT_DIR/lvm-vgs.txt"
  lvs -o+lv_uuid,segtype > "$OUT_DIR/lvm-lvs.txt"
fi

# Bootloader configuration
cp /boot/grub/grub.cfg "$OUT_DIR/grub.cfg" 2>/dev/null || true
grub-install --version > "$OUT_DIR/grub-version.txt" 2>/dev/null || true

# Kernel and modules
uname -a > "$OUT_DIR/kernel.txt"
lsmod > "$OUT_DIR/modules.txt"

# Package inventory (Debian/Ubuntu)
dpkg --get-selections > "$OUT_DIR/packages.txt" 2>/dev/null || \
  rpm -qa > "$OUT_DIR/packages.txt"

# fstab and network config are critical for boot
cp /etc/fstab "$OUT_DIR/fstab"
cp -r /etc/netplan "$OUT_DIR/netplan" 2>/dev/null || true

# Ship to an off-server target — never keep the only copy on the affected host
rsync -az "$OUT_DIR/" backup-host:/inventory/$(hostname)/

4. Image-basierte Vollsicherung mit dd und partclone

Die klassische Methode fuer Bare Metal Recovery ist die blockbasierte Image-Sicherung ganzer Partitionen oder Platten. dd kopiert jeden Block unabhaengig vom Dateisystem, was maximale Kompatibilitaet bietet, aber auch leere Bloecke mitkopiert und entsprechend langsam und speicherintensiv ist. partclone kennt dagegen das jeweilige Dateisystem und ueberspringt unbelegte Bloecke, was Sicherungszeit und Speicherbedarf deutlich reduziert, besonders bei groesstenteils leeren Partitionen. Fuer produktive Bare Metal Recovery Strategien ist partclone in aller Regel die praktischere Wahl.

Wichtig bei jeder image-basierten Sicherung ist, dass die Quellpartition waehrend der Sicherung nicht aktiv beschrieben wird. Das erreicht man entweder durch Sicherung von einem Rescue-System aus, waehrend das Zielsystem heruntergefahren ist, oder durch einen LVM-Snapshot, der einen konsistenten Zustand einfriert, waehrend das System weiterlaeuft. Clonezilla automatisiert genau diesen Ablauf und liefert eine fertige Rescue-Umgebung, aus der heraus komplette Platten oder einzelne Partitionen gesichert und zurueckgespielt werden koennen, inklusive Bootloader.

#!/usr/bin/env bash
# image-backup.sh — block-level backup for bare metal recovery
# Run from a rescue environment while the target disk is unmounted
set -euo pipefail

readonly DEVICE="/dev/sda"
readonly IMAGE_DIR="/mnt/backup-nas/images/$(date +%Y%m%d)"
mkdir -p "$IMAGE_DIR"

# partclone: filesystem-aware, skips unused blocks, much faster than dd
for part in /dev/sda1 /dev/sda2; do
  name=$(basename "$part")
  fstype=$(blkid -o value -s TYPE "$part")

  case "$fstype" in
    ext4) partclone.ext4 -c -s "$part" -o "$IMAGE_DIR/${name}.pc.gz" ;;
    xfs)  partclone.xfs  -c -s "$part" -o "$IMAGE_DIR/${name}.pc.gz" ;;
    *)    partclone.dd   -c -s "$part" -o "$IMAGE_DIR/${name}.pc.gz" ;;
  esac
done

# Bootloader and partition table are not covered by partclone — capture separately
dd if="$DEVICE" of="$IMAGE_DIR/mbr-partition-table.img" bs=512 count=2048
sfdisk -d "$DEVICE" > "$IMAGE_DIR/partition-table.sfdisk"

echo "[OK] Bare metal image saved to $IMAGE_DIR"

5. Automatisierter Wiederaufbau als Alternative zum Image

Nicht jede Bare Metal Recovery Strategie muss auf einem Image basieren. Fuer Server, die ueber Konfigurationsmanagement wie Ansible, Puppet oder Cloud-Init reproduzierbar aufgesetzt werden, ist ein automatisierter Wiederaufbau oft schneller als das Zurueckspielen eines mehrere Gigabyte grossen Images. Die Idee: Statt einen exakten Zustand einzufrieren, wird aus einer Basis-Installation und einem deklarativen Playbook derselbe Endzustand neu erzeugt, waehrend nur die eigentlichen Nutzdaten aus einem separaten Backup zurueckgespielt werden.

Diese Strategie hat einen entscheidenden Vorteil fuer Bare Metal Recovery: Sie funktioniert auch dann, wenn die Zielhardware nicht identisch mit der urspruenglichen ist, etwa weil ein Ersatzserver mit anderer Festplattengroesse beschafft werden musste. Ein Image dagegen erwartet in der Regel eine kompatible oder groessere Zielplatte. In der Praxis kombinieren viele Teams beide Ansaetze: ein Image fuer den schnellsten moeglichen Wiederanlauf auf identischer Hardware, und ein Playbook als Fallback fuer den Fall, dass die Hardware nicht mehr passt.

# rebuild-playbook.yml — reproducible server rebuild for bare metal recovery
# Fallback path when identical replacement hardware is not available
- name: Rebuild server from scratch after total failure
  hosts: recovery_target
  become: true
  vars:
    php_version: "8.4"

  tasks:
    - name: Install base packages matching production inventory
      apt:
        name: "{{ item }}"
        state: present
      loop:
        - nginx
        - "php{{ php_version }}-fpm"
        - mariadb-server
        - fail2ban

    - name: Restore /etc configuration from last known-good backup
      synchronize:
        src: "rsync://backup-host/config/{{ inventory_hostname }}/etc/"
        dest: /etc/
      delegate_to: localhost

    - name: Restore application data volume
      command: >
        restic -r s3:s3.example.com/backups restore latest
        --target /var/www --path /var/www
      environment:
        RESTIC_PASSWORD_FILE: /root/.restic-pass

    - name: Reinstall bootloader on the new disk
      command: grub-install /dev/sda

6. Die Recovery-Umgebung vorbereiten: Rescue-System und Netzwerk-Boot

Ein Image oder ein Playbook nuetzt nichts, wenn im Ernstfall keine Umgebung existiert, aus der heraus die Wiederherstellung ueberhaupt gestartet werden kann. Zur Bare Metal Recovery Planung gehoert deshalb zwingend eine vorbereitete Rescue-Umgebung: ein bootfaehiger USB-Stick mit Clonezilla oder einer minimalen Debian-Live-Umgebung, oder, bei dedizierten Servern in einem Rechenzentrum, ein PXE-Netzwerk-Boot, der ohne physischen Zugang zum Server funktioniert.

Bei Root-Servern ohne physischen Zugriff ist PXE-Boot oder das vom Hoster bereitgestellte Rescue-System oft die einzige Option. Diese Rescue-Systeme sollten vorab getestet werden: Funktioniert der Netzwerkzugriff auf das Backup-Ziel aus dem Rescue-System heraus? Sind die noetigen Tools wie partclone, rsync oder restic darin ueberhaupt installiert, oder muessen sie erst nachinstalliert werden? Diese Fragen im Ernstfall zum ersten Mal zu beantworten, verlaengert eine Bare Metal Recovery erfahrungsgemaess um Stunden.

7. RTO und RPO fuer Bare Metal Recovery realistisch kalkulieren

Recovery Time Objective (RTO) und Recovery Point Objective (RPO) sind die zentralen Kennzahlen jeder Bare Metal Recovery Planung. RTO beschreibt, wie lange der Wiederanlauf maximal dauern darf, RPO, wie viel Datenverlust zwischen letztem Backup und Ausfall akzeptabel ist. Fuer Bare Metal Recovery muss die RTO-Kalkulation realistisch alle Schritte einbeziehen: Ersatzhardware beschaffen oder bereitstellen, Rescue-System booten, Image oder Playbook einspielen, Datenbank-Restore, Funktionstest.

Ein haeufiger Planungsfehler ist, nur die reine Restore-Zeit des Backup-Tools zu messen und die vorgelagerten Schritte zu ignorieren. Ein Image-Restore von einem Terabyte-Volume kann selbst zwei Stunden dauern, aber wenn zusaetzlich erst ein Rescue-Stick gesucht, eine Ersatzplatte eingebaut und ein DNS-Failover manuell ausgeloest werden muss, liegt die tatsaechliche RTO schnell bei einem Tag. Die Bare Metal Recovery Planung sollte deshalb jeden einzelnen Schritt zeitlich erfassen und das Ergebnis mit dem vom Business geforderten RTO abgleichen, nicht umgekehrt.

8. Testen ohne Produktionsausfall: Recovery in der VM simulieren

Ein Bare Metal Recovery Plan, der nie getestet wurde, ist eine Vermutung, kein Plan. Die gute Nachricht: Der komplette Ablauf laesst sich risikofrei in einer virtuellen Maschine simulieren, ohne den Produktionsserver anzufassen. Das erzeugte Image wird dazu in eine QEMU/KVM-VM mit vergleichbarer virtueller Plattengroesse eingespielt, und anschliessend wird geprueft, ob die VM tatsaechlich bootet, das Netzwerk erreichbar ist und die Anwendung startet.

Diese Tests gehoeren in einen festen Zeitplan, mindestens vierteljaehrlich, und immer nach jeder wesentlichen Aenderung am Disk-Layout oder Bootloader. Ein Bare Metal Recovery Test, der beim ersten Versuch scheitert, etwa weil die VM nicht bootet oder ein Kernel-Modul fehlt, ist wertvoller als jeder ungetestete Plan, denn er deckt genau die Luecke auf, die im echten Ernstfall zur Katastrophe wuerde. Ergebnisse und gemessene Zeiten sollten dokumentiert werden, damit die RTO-Kalkulation aus Abschnitt sieben auf echten Messwerten basiert statt auf Schaetzungen.

#!/usr/bin/env bash
# recovery-drill.sh — validate a bare metal image in an isolated VM
set -euo pipefail

readonly IMAGE="/mnt/backup-nas/images/20260730/sda1.pc.gz"
readonly VM_DISK="/tmp/recovery-test.qcow2"
readonly VM_NAME="recovery-drill-$(date +%s)"

qemu-img create -f qcow2 "$VM_DISK" 40G

# Restore the partclone image onto a loopback-mapped disk
partclone.ext4 -r -s "$IMAGE" -o "$VM_DISK"

# Boot the restored disk in an isolated, host-only network
virt-install \
  --name "$VM_NAME" \
  --memory 2048 \
  --disk "$VM_DISK" \
  --network network=isolated-drill-net \
  --import \
  --noautoconsole

echo "[INFO] Waiting for boot..."
sleep 60

# Confirm the recovered VM answers on SSH — proof the boot chain actually works
if ssh -o StrictHostKeyChecking=no -o ConnectTimeout=5 recovery-vm "systemctl is-system-running" ; then
  echo "[OK] Recovery drill succeeded: $VM_NAME booted and is reachable"
else
  echo "[FAIL] Recovery drill failed — image or bootloader is broken" >&2
  exit 1
fi

9. Recovery-Methoden im Vergleich

Fuer eine belastbare Bare Metal Recovery Planung lohnt sich der direkte Vergleich der verfuegbaren Methoden, denn keine davon ist in jeder Situation die beste Wahl.

In der Praxis ist eine Kombination am robustesten: partclone-Images fuer den schnellen Wiederanlauf auf gleicher Hardware, ein Ansible-Playbook als Fallback, wenn die Zielhardware abweicht, und ein vorbereitetes Rescue-System oder PXE-Boot, damit beide Wege ueberhaupt gestartet werden koennen. Diese Kombination deckt sowohl den haeufigen Fall, gleiche Hardware, als auch den seltenen, aber kritischen Fall, komplett neue Hardware, ab.

10. Zusammenfassung

Bare Metal Recovery ist die Antwort auf den Fall, dass ein Server nicht nur Daten verliert, sondern vollstaendig ausfaellt, inklusive Partitionstabelle, Bootloader und Betriebssystem. Ein tragfaehiger Plan beginnt mit einem versionierten Inventar aus Disk-Layout, Bootloader-Konfiguration und Paketliste, gefolgt von einer regelmaessigen Image-Sicherung mit partclone oder Clonezilla. Ein Ansible-Playbook als Fallback deckt den Fall ab, dass Ersatzhardware nicht identisch ist. Eine vorbereitete Rescue-Umgebung, ob USB-Stick oder PXE-Boot, ist die Voraussetzung, dass Image oder Playbook im Ernstfall ueberhaupt eingespielt werden koennen.

Die realistische Kalkulation von RTO und RPO sowie regelmaessige Recovery-Drills in isolierten VMs machen aus einer theoretischen Bare Metal Recovery Planung einen erprobten, verlaesslichen Ablauf. Wer diesen Prozess einmal jaehrlich oder nach jeder groesseren Aenderung testet, verwandelt den schlimmsten anzunehmenden Ausfall von einer Krise in einen kalkulierbaren, gut dokumentierten Vorgang.

11. FAQ: Bare Metal Recovery Planung