Disaster Recovery (Notfallwiederherstellung und Backups)

1. Überblick über das Konzept und das systemische Problem

In der Infrastruktur-Engineering sind Hardware-Ausfälle von SSD-Speichern, Katastrophen in Rechenzentren von Providern, Ransomware-Angriffe und menschliche Fehler (DROP DATABASE production, versehentliches rm -rf) keine Frage des „Ob“, sondern des „Wann“.

Die meisten Teams leben in einer trügerischen Sicherheit: Sie fügen einen Eintrag in die crontab hinzu, um einmal täglich ein Dump zu erstellen, und betrachten die Aufgabe damit als erledigt. Wenn jedoch eine echte Katastrophe eintritt, zeigt sich oft Folgendes:

• Das letzte Backup ist vor drei Monaten fehlgeschlagen, weil der Datenträger voll war.
• Der Dump enthält beschädigte Binärdaten.
• Die Wiederherstellung einer 100-GB-Datenbank dauert 36 Stunden und legt den Betrieb lahm (ein nicht akzeptabler RTO).
• Ein Angreifer, der den Server kompromittiert hat, löschte die Backups zusammen mit der produktiven Datenbank, da der S3-API-Key volle Löschrechte besaß (s3:DeleteObject).

Disaster Recovery (Notfallwiederherstellung) ist eine umfassende Strategie für die Geschäftskontinuität. Sie umfasst nicht nur die Sicherung von Dateien, sondern mathematisch kalkulierte RTO/RPO-Ziele, unveränderliche Speicher (Immutable Storage) sowie automatisierte, regelmäßige Übungen zur Neuinstallation der Infrastruktur von Grund auf.

2. Architektonische Taxonomie und mentales Modell

Die Architektur-Matrix für Disaster Recovery basiert auf dem Kompromiss zwischen Geschwindigkeit und Häufigkeit der Zustandserfassung:

┌─────────────────────────────────────────────────────────────┐
│                 DISASTER RECOVERY TAXONOMY                  │
├─────────────────────────────────────────────────────────────┤
│ 1. Point-In-Time Recovery (PITR) ➔ RPO ~ секунди            │
│    • Стрімінг журналів WAL (Write-Ahead Log) у реальному часі│
│    • Інструменти: Litestream (для SQLite), pgBackRest (PG)  │
├─────────────────────────────────────────────────────────────┤
│ 2. Deduplicated & Encrypted Snapshots ➔ RPO ~ години        │
│    • Атомарні знімки даних через Restic, BorgBackup, Kopia  │
│    • Клієнтське шифрування AES-256 / ChaCha20               │
├─────────────────────────────────────────────────────────────┤
│ 3. Offsite Immutable Storage Tier (Anti-Ransomware)         │
│    • S3 Object Lock (WORM - Write Once, Read Many)          │
│    • Географічно ізольовані сховища (Cloudflare R2, AWS S3) │
├─────────────────────────────────────────────────────────────┤
│ 4. Cold Standby & Automated Recovery Drill (RTO валідація)  │
└─────────────────────────────────────────────────────────────┘

1. Point-In-Time Recovery (PITR):
   • Anstelle eines einzigen schweren Dumps pro Tag streamt die Datenbank kontinuierlich ihr Write-Ahead-Log (WAL) in die Cloud. Dies ermöglicht es, den Zustand der Datenbank bis auf die Sekunde zurückzuverfolgen, die dem Ausfall oder einem fehlerhaften Entwickler-Query vorausging (RPO < 10 Sekunden).
2. Deduplizierte inkrementelle Snapshots (Content-Addressed Snapshots):
   • Tools wie Restic zerlegen Dateien in kryptografische Blöcke. Wenn sich in einer 50-GB-Datenbank nur 1 % geändert hat, werden nur die neuen Blöcke hochgeladen, was bis zu 95 % Speicherplatz und Netzwerkbandbreite einspart.
3. Unveränderlicher Speicher (Immutable WORM Storage):
   • Eine Sicherheitsrichtlinie für S3 Object Lock, bei der niemand – selbst kein Administrator mit Root-Rechten – ein erstelltes Archiv innerhalb eines festgelegten Zeitraums (z. B. 30 Tage) löschen oder überschreiben kann.
4. Recovery Drills (Wiederherstellungsübungen):
   • Ein regelmäßiger, automatisierter Prozess im CI, der das letzte Archiv herunterlädt, es in einem isolierten Container bereitstellt, Prüf-SQL-Abfragen ausführt und die Datenintegrität bestätigt.

3. Technischer Pipeline und interne Mechanik

Der Lebenszyklus einer zuverlässigen Datensicherung mit Deduplizierung und Verschlüsselung:

1. Konsistentes Einfrieren des Zustands (Snapshot Lock): Die Datenbank wird in einen Modus zur Kopier-Vorbereitung versetzt oder es wird ein transaktionaler Snapshot über COW-Mechanismen (Copy-on-Write) des Dateisystems ZFS/Btrfs erstellt.
2. Clientseitige Verschlüsselung auf dem Host: Vor der Übertragung ins Netzwerk werden die Daten mit einem robusten Algorithmus (AES-256-GCM) unter Verwendung einer Passphrase verschlüsselt, die nur dem Ingenieur bekannt ist. Der S3-Hosting-Provider erhält ausschließlich verschlüsseltes Binär-Rauschen.
3. Paralleles Hochladen in isolierten Cloud-Speicher: Die Blöcke werden über HTTPS an eine unabhängige geografische Region übertragen (z. B. wird ein Server in Deutschland in einen Cloudflare R2 Bucket in Schweden gesichert).
4. Anwendung der Rotationsrichtlinie (GFS Retention Policy): Der Algorithmus behält: die letzten 24 stündlichen Kopien, 7 tägliche, 4 wöchentliche und 12 monatliche Sicherungen (Grandfather-Father-Son) und löscht automatisch ältere Zwischen-Snapshots.
5. Automatisierte Integritätsprüfung (Automated Integrity Check): Eine separate Hintergrund-Aufgabe führt einmal pro Woche den Befehl restic check --read-data-subset=5% aus, um mögliche Bit-Rot-Degradation im Speicher zu erkennen.

4. Praktische Engineering-Szenarien im Production-Umfeld

01. Kontinuierliche Replikation von SQLite mit Litestream

Für Anwendungen auf Basis von SQLite/Turso:

• Litestream läuft als Hintergrund-Prozess des Systems und erfasst Änderungen im WAL-File.
• Alle 10 Sekunden werden neue Frames verschlüsselt und in den Cloudflare R2 Bucket hochgeladen.
• Im Falle eines vollständigen Server-Ausfalls wird die neue Maschine mit einem einzigen Befehl litestream restore -o /var/data/app.db wiederhergestellt, wobei der Systemzustand praktisch ohne Datenverlust rekonstruiert wird (RPO < 10 s, RTO < 60 s).

02. Schutz vor Angreifern durch S3 Object Lock

Verhinderung der Zerstörung der Infrastruktur durch Hacker:

• Selbst wenn ein Angreifer vollen Root-Zugriff auf den Server erlangt und die Konfiguration mit den AWS_ACCESS_KEY_ID-Schlüsseln findet, wird der Versuch, aws s3 rm --recursive auszuführen, durch die AWS Compliance Lock-Policy auf Ebene des Amazon-Rechenzentrums blockiert.
• Das Unternehmen hat garantiert Zugriff auf die unveränderlichen Datensicherungen.

03. Kaltstandby-Wiederherstellungsplan via Terraform (IaC Standby)

Ein OVH-artiges Desaster (Brand im Rechenzentrum Straßburg):

• Der Hauptserver ist physisch nicht mehr erreichbar.
• Der Ingenieur startet die CI-Pipeline: Terraform mietet innerhalb von 3 Minuten eine neue Instanz bei Hetzner, Ansible rollt die Basiskonfiguration aus, ein Skript lädt das letzte Restic-Backup herunter, und die DNS-Einträge bei Cloudflare werden innerhalb von 60 Sekunden auf die neue IP umgeleitet.

5. Fallstricke, häufige Fehler und Sicherheit

• Speicherung des Entschlüsselungs-Passworts neben dem Backup: Wenn das Passwort für das Restic-Repository in einer offenen Datei /root/.backup_pass gespeichert wird, gewährt die Kompromittierung des Servers Angreifern gleichzeitig Lesezugriff auf die gesamte Kunden-Datenbank in den Backups.
• Versuch, Live-Datenbankdateien ohne Sperren zu kopieren (Dirty Reads): Das einfache Kopieren des PostgreSQL-Datenverzeichnisses (cp -r /var/lib/postgresql) während aktiver Queries erzeugt einen inkonsistenten Binärzustand (Torn Pages), der nach der Wiederherstellung nicht gestartet werden kann.
• Mangelnder Speicherplatz für die Dekompression des Dumps: Wenn auf dem neuen Server eine Festplatte installiert ist, die kleiner ist als die entpackte Datenbank, schlägt der Wiederherstellungsprozess mitten im Vorgang mit einer Fehlermeldung wegen Platzmangels fehl („No space left on device“).
• Ignorieren von Konfigurationsdateien und Umgebungsvariablen: Ein Backup nur der Datenbank ohne Sicherung der Nginx-Konfigurationen, SSL-Zertifikate und .env-Dateien erhöht den RTO von 15 Minuten auf mehrere Tage manuelles Rekonstruieren der Einstellungen.