Backup-Test: Wiederherstellen üben, statt hoffen

Ein Backup-Test prüft, ob sich aus einer Sicherung tatsächlich ein funktionierendes System wiederherstellen lässt. Ohne Test ist eine Sicherung eine Annahme – und Annahmen scheitern genau dann, wenn man sie braucht.

Warum ungetestete Sicherungen wertlos sind

Die Liste der Gründe, aus denen eine Wiederherstellung scheitert, ist lang und jeder Punkt kommt in der Praxis vor:

  • Die Sicherung ist unvollständig – Dateien wurden von anderer Software gesperrt und stillschweigend übersprungen.
  • Der Sicherungsdatenträger hat Fehler; das Archiv lässt sich öffnen, aber einzelne Blöcke nicht lesen.
  • Das Wiederherstellungswerkzeug ist nicht mehr auffindbar oder passt nicht zur Archivversion.
  • Zugangsdaten, Verschlüsselungsschlüssel oder Passwörter fehlen. Ein verschlüsseltes Archiv ohne Schlüssel ist verlorene Arbeit.
  • Datenbanken sind inkonsistent, weil sie während des Kopierens liefen (statt eines logischen Exports).
  • Die Wiederherstellung dauert viel länger als angenommen – von drei Stunden auf dreißig.
  • Niemand weiß, welche Schritte nach dem Zurückspielen nötig sind (Konfiguration anpassen, Dienste starten, Caches leeren).

Der letzte Punkt ist der häufigste. Nicht die Technik versagt, sondern die Dokumentation.

Stufen der Prüfung

Es gibt mehrere Tiefen, und alle haben ihren Platz:

  1. Existenz und Alter prüfen (automatisch, täglich): Wurde die Sicherung erstellt? Wie alt ist sie? Wie groß? Steht ein Fehler im Protokoll? Das ist die Mindestprüfung und deckt die häufigste Ursache aus: die Sicherung läuft seit Wochen nicht mehr, weil das Kennwort abgelaufen ist.
  2. Integrität der Daten prüfen (automatisch, wöchentlich): Prüfsummen vergleichen, Archiv lesen ohne zu entpacken. Das erkennt beschädigte Datenträger, bevor man sie braucht.
  3. Stichprobe wiederherstellen (monatlich): Einzelne Dateien oder Datenbanktabellen zurückholen und mit dem Original vergleichen. Kostet Minuten, deckt viele Fehler auf.
  4. Vollständige Wiederherstellung in einer Testumgebung (vierteljährlich): Das komplette System aus der Sicherung aufbauen – auf anderer Hardware oder in einer virtuellen Maschine. Das ist der einzig vollständige Test.

Praktische Prüfungen von der Kommandozeile

# Alter und Groesse der Sicherungen pruefen
ls -lht /srv/backup/ | head -20
find /srv/backup -mtime +2 -name '*.tar.gz' -ls      # aelter als 2 Tage

# Archiv lesen, ohne zu entpacken
tar -tzf /srv/backup/archiv.tar.gz > /dev/null && echo "Archiv lesbar"
tar -tzf archiv.tar.gz | wc -l                       # Anzahl Eintraege

# Pruefsummen gegenpruefen
sha256sum -c /srv/backup/archiv.sha256

# Einzelne Datei zurueckholen (Vorsicht: in ein Testverzeichnis!)
mkdir -p /tmp/restore_probe
tar -xzf /srv/backup/archiv.tar.gz -C /tmp/restore_probe ./etc/ssh/sshd_config

# Diff gegen das Original
diff /tmp/restore_probe/etc/ssh/sshd_config /etc/ssh/sshd_config

# Datenbank-Sicherung pruefen: in eine Testdatenbank einspielen
mysql --skip-ssl -h db-test -u probe -p testdb < dump.sql
mysql --skip-ssl -h db-test -u probe -p testdb -N -e "SELECT COUNT(*) FROM kunden;"

# Aufraeumen
rm -rf /tmp/restore_probe

Wichtig: Die Testwiederherstellung niemals auf das Produktivsystem. Immer in ein separates Verzeichnis, eine Testdatenbank oder eine virtuelle Maschine.

Messgrößen, die dokumentiert werden müssen

Ein Test liefert Zahlen, nicht nur ein Ergebnis. Diese gehören in ein Protokoll:

  • RPO (Recovery Point Objective): Wie viel Datenverlust ist akzeptabel? Bestimmt das Sicherungsintervall. Ein RPO von einer Stunde bedeutet, dass stündlich gesichert werden muss.
  • RTO (Recovery Time Objective): Wie lange darf die Wiederherstellung dauern? Bestimmt die Wahl des Verfahrens. Ein RTO von 15 Minuten geht nur mit Replikation oder Snapshot, nicht mit einem Archiv.
  • Tatsächlich gemessene Wiederherstellungszeit: Der Vergleich von Ziel und Messwert zeigt, ob das Konzept trägt.
  • Vollständigkeit: Ist alles zurückgekommen, was nötig ist – Daten, Konfiguration, Zertifikate, Zugangsdaten?

Automatisierung

Die ersten beiden Prüfstufen gehören automatisiert. Ein einfaches Skript, das täglich läuft, deckt den größten Teil des Risikos:

#!/usr/bin/env bash
set -euo pipefail

VERZ="/srv/backup"
MAX_ALTER_H=26                    # Warnung, wenn aelter als 26 Stunden
STATUS=0

# 1. Gibt es eine aktuelle Sicherung?
NEUESTE=$(find "$VERZ" -name '*.tar.gz' -printf '%T@ %p\n' \
          | sort -rn | head -1 | cut -d' ' -f2-)
if [[ -z "$NEUESTE" ]]; then
  echo "FEHLER: keine Sicherung gefunden"; exit 1
fi

ALTER_H=$(( ( $(date +%s) - $(stat -c %Y "$NEUESTE") ) / 3600 ))
if (( ALTER_H > MAX_ALTER_H )); then
  echo "FEHLER: neueste Sicherung ist ${ALTER_H}h alt"; STATUS=1
fi

# 2. Lesbar?
if ! tar -tzf "$NEUESTE" > /dev/null; then
  echo "FEHLER: Archiv nicht lesbar: $NEUESTE"; STATUS=1
fi

# 3. Pruefsumme?
if [[ -f "${NEUESTE}.sha256" ]]; then
  if ! (cd "$(dirname "$NEUESTE")" && sha256sum -c "$(basename "$NEUESTE").sha256" >/dev/null); then
    echo "FEHLER: Pruefsumme stimmt nicht"; STATUS=1
  fi
fi

# 4. Groesse plausibel (nicht ploetzlich ein Zehntel)?
GROESSE_MB=$(( $(stat -c %s "$NEUESTE") / 1048576 ))
echo "OK: $(basename "$NEUESTE") - ${ALTER_H}h alt - ${GROESSE_MB} MB"

exit "$STATUS"

Läuft dieses Skript als geplanter Auftrag und meldet sich bei Fehler per Mail, ist das größte Risiko abgedeckt – nicht durch Technik, sondern durch Aufmerksamkeit.

Dokumentation, die zählt

Eine Wiederherstellungsanleitung muss so geschrieben sein, dass eine andere Person sie umsetzen kann – nachts, unter Druck, ohne den Autor. Sie enthält:

  1. Wo die Sicherungen liegen und wie man sie erreicht (Adresse, Anmeldung, Pfad).
  2. Wo die Verschlüsselungsschlüssel liegen – getrennt von den Sicherungen. Liegen beide am gleichen Ort, sind beide weg, wenn dieser Ort ausfällt.
  3. Die konkreten Befehle, in der richtigen Reihenfolge, mit erwarteten Ausgaben.
  4. Die nötigen Schritte nach der Wiederherstellung: Dienste starten, Konfiguration anpassen, DNS umstellen, Caches leeren.
  5. Eine geschätzte Dauer je Schritt.
  6. Telefonnummern und Kontakte für den Fall, dass es nicht funktioniert.

Der letzte Schritt eines Tests ist deshalb immer derselbe: Die Anleitung korrigieren. Jeder abweichende Schritt, jede fehlende Angabe, jede Unklarheit wird sofort eingearbeitet – sonst wiederholt sich der Fehler beim nächsten Mal.

Verwandte Grundlagen: Backup-Strategien: 3-2-1, restic, BorgBackup, Backup.