Restore-Tests automatisieren: Backups wirklich verifizieren

1. Warum ungetestete Backups keine Backups sind

Ein Backup ist per Definition nur so gut wie die Wiederherstellung, die es ermoeglicht. Solange dieser Nachweis fehlt, handelt es sich um eine unbewiesene Behauptung, nicht um eine funktionierende Sicherung. In der Praxis scheitern erschreckend viele Restores im echten Ernstfall, weil ein Backup-Job zwar ohne Fehlermeldung durchlief, aber ein leeres Verzeichnis sicherte, ein falsches Passwort verwendete oder eine Datenbank nur teilweise exportierte. Restore-Tests decken genau diese Luecken auf, bevor sie in einer echten Krise sichtbar werden.

Der Grund, warum Restore-Tests trotzdem so selten konsequent durchgefuehrt werden, ist der manuelle Aufwand: ein echter Restore-Test bindet Zeit, braucht eine Testumgebung und wird deshalb in der Praxis oft aufgeschoben, bis er ganz entfaellt. Genau hier setzt die Automatisierung an. Automatisierte Restore-Tests laufen ohne manuelles Zutun, regelmaessig und mit reproduzierbaren Erfolgskriterien, wodurch aus einer laestigen Pflichtuebung ein stiller, verlaesslicher Bestandteil des Betriebs wird.

2. Was ein Restore-Test wirklich pruefen muss

Ein oberflaechlicher Restore-Test, der nur prueft, ob der Wiederherstellungsbefehl mit Exit-Code null zurueckkehrt, ist nicht ausreichend. Ein vollstaendiger Restore-Test muss mindestens drei Ebenen abdecken: Erstens die technische Ausfuehrung, also ob der Restore-Prozess selbst ohne Fehler durchlaeuft. Zweitens die Datenintegritaet, also ob die wiederhergestellten Daten inhaltlich korrekt und vollstaendig sind, geprueft ueber Checksums oder Datenbank-Konsistenzchecks. Drittens die funktionale Nutzbarkeit, also ob eine Anwendung mit den wiederhergestellten Daten tatsaechlich startet und arbeitet.

Restore-Tests, die nur die erste Ebene abdecken, geben ein falsches Sicherheitsgefuehl. Ein Restore kann technisch erfolgreich abschliessen und trotzdem eine Datenbank mit fehlenden Tabellen oder ein Dateisystem mit falschen Berechtigungen erzeugen. Erst die Kombination aller drei Ebenen macht einen Restore-Test aussagekraeftig genug, um sich im Ernstfall tatsaechlich darauf verlassen zu koennen.

3. Isolierte Sandbox-Umgebung automatisch bereitstellen

Restore-Tests duerfen niemals gegen produktive Systeme laufen, denn ein missgluecktes Test-Restore koennte sonst echte Daten ueberschreiben. Die Loesung ist eine isolierte, bei jedem Testlauf frisch erzeugte Sandbox-Umgebung, meist als Docker-Container oder kurzlebige VM, die nach dem Test wieder verworfen wird. Diese Wegwerf-Natur der Sandbox ist entscheidend: Restore-Tests, die immer dieselbe langlebige Testumgebung wiederverwenden, koennen Reste vorheriger Laeufe mitschleppen und so falsch positive Ergebnisse erzeugen.

Container eignen sich fuer Restore-Tests von Datenbanken besonders gut, weil sich ein frischer MariaDB- oder PostgreSQL-Container in Sekunden starten und wieder entfernen laesst. Fuer komplette Dateisystem-Restores, etwa von einem Bare-Metal-Backup, ist eine kurzlebige VM die praktikablere Wahl, weil hier auch Bootloader und Kernel-Interaktionen eine Rolle spielen koennen, die ein Container gar nicht abbildet.

#!/usr/bin/env bash
# provision-restore-sandbox.sh — disposable, isolated environment for restore tests
set -euo pipefail

readonly CONTAINER_NAME="restore-test-$(date +%s)"
readonly BACKUP_FILE="/var/backup/mariadb/latest.sql.gz"

cleanup() {
  echo "[INFO] Tearing down sandbox container"
  docker rm -f "$CONTAINER_NAME" &>/dev/null || true
}
trap cleanup EXIT

# Fresh, isolated database — no leftover state from previous test runs
docker run -d \
  --name "$CONTAINER_NAME" \
  --network none \
  -e MARIADB_ROOT_PASSWORD=test_only_password \
  mariadb:11

# Wait for the database to accept connections
for i in {1..30}; do
  docker exec "$CONTAINER_NAME" mariadb-admin ping -uroot -ptest_only_password &>/dev/null && break
  sleep 1
done

echo "[OK] Sandbox $CONTAINER_NAME ready for restore test"

4. Ein automatisiertes Restore-Skript mit Erfolgskriterien

Das eigentliche Restore-Skript muss klar definierte, maschinenlesbare Erfolgskriterien liefern, nicht nur eine Textausgabe fuer einen Menschen. Jeder Schritt, das Entpacken der Sicherung, das Einspielen in die Sandbox, die anschliessende Pruefung, sollte einen eindeutigen Exit-Code zurueckgeben, damit Restore-Tests in automatisierten Pipelines zuverlaessig zwischen Erfolg und Fehlschlag unterscheiden koennen. Ein Restore-Test, der bei einem Teilfehler trotzdem Exit-Code null zurueckgibt, ist gefaehrlicher als gar kein Test, weil er ein falsches Vertrauen erzeugt.

Wichtig ist zudem, dass das Restore-Skript exakt denselben Pfad nimmt wie ein echter Restore im Ernstfall, also dieselben Tools, dieselben Kommandozeilenoptionen, dieselbe Reihenfolge. Ein Restore-Test, der eine vereinfachte Abkuerzung nutzt, die im echten Ernstfall so nicht zur Verfuegung steht, testet in Wahrheit einen anderen Prozess und liefert keine verlaessliche Aussage ueber den tatsaechlichen Ernstfall-Ablauf.

#!/usr/bin/env bash
# automated-restore-test.sh — restore test with clear machine-readable outcomes
set -euo pipefail

readonly CONTAINER_NAME="restore-test-$(date +%s)"
readonly BACKUP_FILE="/var/backup/mariadb/latest.sql.gz"
readonly EXPECTED_MIN_TABLES=12
readonly RESULT_LOG="/var/log/restore-tests/$(date +%Y%m%d).log"

cleanup() { docker rm -f "$CONTAINER_NAME" &>/dev/null || true; }
trap cleanup EXIT

mkdir -p "$(dirname "$RESULT_LOG")"

docker run -d --name "$CONTAINER_NAME" --network none \
  -e MARIADB_ROOT_PASSWORD=test_pass mariadb:11 >/dev/null

sleep 15

# Step 1: run the exact same restore path used in a real emergency
if ! zcat "$BACKUP_FILE" | docker exec -i "$CONTAINER_NAME" \
  mariadb -uroot -ptest_pass; then
  echo "[FAIL] restore-step: SQL import failed" | tee -a "$RESULT_LOG"
  exit 1
fi

# Step 2: verify table count as a sanity check for completeness
table_count=$(docker exec "$CONTAINER_NAME" mariadb -uroot -ptest_pass \
  -N -e "SELECT COUNT(*) FROM information_schema.tables WHERE table_schema NOT IN ('mysql','information_schema','performance_schema','sys');")

if (( table_count < EXPECTED_MIN_TABLES )); then
  echo "[FAIL] validation-step: only $table_count tables, expected >= $EXPECTED_MIN_TABLES" | tee -a "$RESULT_LOG"
  exit 1
fi

echo "[OK] Restore test passed: $table_count tables restored" | tee -a "$RESULT_LOG"

5. Checksums und Datenbank-Validierung nach dem Restore

Neben der reinen Tabellenanzahl gehoert eine inhaltliche Pruefung zu jedem gruendlichen Restore-Test. Fuer Dateisicherungen bedeutet das, vor dem Backup Checksums, etwa mit sha256sum, zu erzeugen und nach dem Restore denselben Hash erneut zu berechnen und zu vergleichen. Weicht der Hash ab, hat der Restore-Test einen stillen Datenverlust oder eine Beschaedigung aufgedeckt, die ein reiner Exit-Code-Check niemals bemerkt haette.

Fuer Datenbanken ergaenzen strukturelle Konsistenzchecks wie CHECK TABLE bei MariaDB oder pg_amcheck bei PostgreSQL die reine Zeilenanzahl-Pruefung. Ein Restore-Test, der zusaetzlich stichprobenartig pruft, ob zentrale Fremdschluessel-Beziehungen intakt sind und ob wichtige Referenztabellen die erwartete Mindestanzahl an Eintraegen haben, deckt subtile Restore-Probleme auf, die bei einer reinen Tabellenanzahl-Pruefung unentdeckt blieben.

#!/usr/bin/env bash
# checksum-validation.sh — verify file integrity across backup and restore
set -euo pipefail

readonly SOURCE_DIR="/var/www/html/media"
readonly BACKUP_ARCHIVE="/var/backup/media-$(date +%Y%m%d).tar.gz"
readonly CHECKSUM_FILE="/var/backup/media-$(date +%Y%m%d).sha256"

# Generate checksums before backing up — this is the trusted baseline
find "$SOURCE_DIR" -type f -exec sha256sum {} \; > "$CHECKSUM_FILE"
tar -czf "$BACKUP_ARCHIVE" -C "$SOURCE_DIR" .

# --- restore test, in the disposable sandbox ---
RESTORE_DIR=$(mktemp -d)
tar -xzf "$BACKUP_ARCHIVE" -C "$RESTORE_DIR"

# Recompute checksums on the restored copy and diff against the baseline
cd "$RESTORE_DIR"
if sha256sum --check --quiet <(sed "s|$SOURCE_DIR|$RESTORE_DIR|" "$CHECKSUM_FILE"); then
  echo "[OK] All restored files match their original checksums"
else
  echo "[FAIL] Checksum mismatch — restore produced corrupted data" >&2
  exit 1
fi

rm -rf "$RESTORE_DIR"

6. Restore-Tests in CI/CD und Cron einbinden

Damit Restore-Tests wirklich regelmaessig laufen, gehoeren sie in eine feste Automatisierung statt in eine gute Absicht. Zwei Wege haben sich in der Praxis bewaehrt: ein taeglicher oder woechentlicher Cron-Job beziehungsweise systemd-Timer fuer die laufende Ueberwachung im Betrieb, sowie zusaetzlich ein Restore-Test als Pipeline-Job in GitLab CI oder GitHub Actions, der bei jeder Aenderung an der Backup-Konfiguration selbst automatisch ausgeloest wird. So wird eine Aenderung am Backup-Skript nicht erst beim naechsten planmaessigen Lauf, sondern sofort validiert.

Restore-Tests innerhalb einer CI-Pipeline profitieren zusaetzlich davon, dass die Infrastruktur ohnehin schon fuer isolierte, wegwerfbare Umgebungen ausgelegt ist. Ein GitLab-Runner mit Docker-Executor stellt genau die Sandbox bereit, die in Abschnitt drei beschrieben wurde, ohne zusaetzlichen Infrastrukturaufwand.

# .gitlab-ci.yml — restore test as a scheduled and triggered pipeline job
stages:
  - restore-test

restore-test:
  stage: restore-test
  image: docker:24
  services:
    - docker:24-dind
  rules:
    - if: '$CI_PIPELINE_SOURCE == "schedule"'
    - changes:
        - "backup/**/*"
  script:
    - apk add --no-cache bash mariadb-client
    - bash scripts/automated-restore-test.sh
  artifacts:
    when: always
    paths:
      - /var/log/restore-tests/
    expire_in: 30 days

7. Reporting und Alerting bei fehlgeschlagenen Restore-Tests

Ein fehlgeschlagener Restore-Test, den niemand bemerkt, ist genauso wertlos wie gar kein Restore-Test. Jeder Fehlschlag muss automatisch an das verantwortliche Team gemeldet werden, idealerweise ueber denselben Alerting-Kanal, der auch fuer Produktionsvorfaelle genutzt wird, damit ein fehlgeschlagener Restore-Test dieselbe Dringlichkeit erhaelt wie ein echter Ausfall. Ein E-Mail-Report, der in einem ungelesenen Postfach verstaubt, erfuellt diesen Zweck nicht.

Zusaetzlich zu akuten Fehlermeldungen lohnt sich ein regelmaessiger Zusammenfassungsbericht, der die Erfolgsquote der Restore-Tests ueber Zeit zeigt. Ein einzelner erfolgreicher Restore-Test ist eine Momentaufnahme, ein Trend ueber Wochen und Monate zeigt dagegen, ob die Backup-Infrastruktur insgesamt stabil bleibt oder ob sich schleichend Probleme einschleichen, etwa durch wachsende Datenmengen, die die Testumgebung an ihre Grenzen bringen.

8. Restore Time Objective messen und dokumentieren

Neben der reinen Erfolgsfrage liefern automatisierte Restore-Tests einen weiteren wertvollen Datenpunkt: die tatsaechlich gemessene Restore-Zeit. Diese Messung ist der einzige verlaessliche Weg, die im Disaster-Recovery-Plan angenommene Recovery Time Objective mit der Realitaet abzugleichen. Ein Restore-Test, der die Dauer jedes Einzelschritts protokolliert, Entpacken, Einspielen, Validierung, macht sichtbar, welcher Schritt bei wachsenden Datenmengen zum Flaschenhals wird, lange bevor das im echten Ernstfall zum Problem wird.

Diese Zeitreihe aus wiederholten Restore-Tests ist zugleich die Grundlage fuer realistische Kapazitaetsplanung. Wenn die gemessene Restore-Zeit ueber mehrere Monate kontinuierlich steigt, weil die Datenbank waechst, signalisiert das rechtzeitig, dass entweder die Restore-Strategie angepasst werden muss, etwa durch parallele Wiederherstellung mehrerer Tabellen, oder dass die im Disaster-Recovery-Plan festgelegte RTO nicht mehr realistisch ist und neu verhandelt werden muss.

9. Manuelle versus automatisierte Restore-Tests

Der direkte Vergleich zeigt, warum Automatisierung bei Restore-Tests kein Komfortmerkmal ist, sondern eine Grundvoraussetzung fuer verlaessliche Ergebnisse.

Ein manueller Restore-Test bleibt sinnvoll fuer jaehrliche, umfassendere Disaster-Recovery-Uebungen, die auch organisatorische Ablaeufe pruefen, etwa Kommunikationsketten und Verantwortlichkeiten. Fuer die technische Verifikation der Backups selbst sind automatisierte Restore-Tests jedoch die einzige Methode, die haeufig genug und konsistent genug laeuft, um wirklich Vertrauen zu rechtfertigen.

10. Zusammenfassung

Restore-Tests sind der einzige Nachweis, dass ein Backup im Ernstfall tatsaechlich funktioniert, statt nur ohne Fehler durchgelaufen zu sein. Ein vollstaendiger Restore-Test prueft technische Ausfuehrung, Datenintegritaet ueber Checksums oder Konsistenzchecks und die funktionale Nutzbarkeit der wiederhergestellten Daten, in einer isolierten, wegwerfbaren Sandbox, die niemals produktive Systeme gefaehrdet.

Automatisierung ueber Cron, systemd-Timer oder CI-Pipelines verwandelt Restore-Tests von einer selten durchgefuehrten Pflichtuebung in eine kontinuierliche, verlaessliche Routine, inklusive Alerting bei Fehlschlaegen und dokumentierter RTO-Messung. Wer diesen Prozess einmal aufsetzt, muss im echten Ernstfall nicht mehr hoffen, dass das Backup funktioniert, sondern kann sich auf gemessene, wiederholt bestaetigte Daten verlassen.

11. FAQ: Restore-Tests automatisieren