Backups und Disaster Recovery

Backups und Disaster Recovery

1) Definitionen und Ziele

Backup - eine konsistente Kopie der Daten/Konfigurationen für die spätere Wiederherstellung (von versehentlichen Löschungen, Bugs, Cryptolokern, Katastrophen).
DR (Disaster Recovery) ist der Prozess der Wiederherstellung der Infrastruktur/Dienste zu SLO-Arbeitern nach einem schweren Unfall (Feuer, Verlust einer Region, massive Kompromittierung).
RPO (Recovery Point Objective) ist der maximal zulässige Zeitverlust von Daten (z. B. 15 Minuten).
RTO (Recovery Time Objective) - Die Zielwiederherstellungszeit des Dienstes (z. B. 30 Minuten).

Das Schlüsselprinzip: Replikation ≠ Backup. Die Replikation „verwischt“ schnell Fehler und Verschlüsselung über alle Kopien hinweg. Backup - isolierte, verifizierte, potenziell unveränderliche Kopie.

2) Datenklassifizierung und Kritikalitätsstufen

• Tier-0 (lebenswichtig): Transaktionsdatenbank, Zahlungen, Bilanzbuchhaltung, Geheimnisse/PKI.
• Tier-1 (kritisch): Service Configs, Warteschlangen, CI/CD-Artefakte, Container-Register.
• Tier-2 (wichtig): Analysen, Berichte, Sekundärindizes, Protokollarchive.
• Tier-3 (Hilfsmittel): Caches, Zeitdaten (kann durch Rekonstruktion wiederhergestellt werden).

Definieren Sie für jede Klasse RPO/RTO, Aufbewahrungsdauer, Unveränderlichkeitsanforderungen und Standort.

3) Speicherstrategien: 3-2-1-1-0-Regel

3 Kopien der Daten (Prod + 2 Backup).
2 verschiedene Arten von Medien/Speicher.
1 Kopie offsite (andere Region/Cloud).
1 immutable/air-gap (WORM/Object Lock/Tape).
0 Fehler in den Wiederherstellungsprüfungen (regelmäßige Tests).

4) Arten von Backups

Full ist eine vollständige Kopie. Langsam/teuer, aber die Basis für alle Strategien.
Incremental - der Unterschied zum letzten Backup. Optimal im Volumen.
Differential ist der Unterschied zum letzten voll. Schnellere Erholung, mehr Platz.
Snapshot - Sofortiger Abdruck eines Volumes/Datenträgers (EBS/ZFS/LVM). Wir brauchen app-konsistente Schnappschüsse (quiesce).
PITR (Point-in-Time Recovery) ist ein grundlegendes Backup + Logs (WAL/binlog) für einen Rollback auf die genaue Zeit/LSN.
Objekt/Datei/Bild - für bestimmte Datentypen (VM-Images, S3-Objekte, DB-Dumps).

5) Konsistenz der Backups

Crash-konsistent: wie nach plötzlichem Abschalten - geeignet für stateless/journaling FS.
App-consistent: Die App „friert“ Operationen (fsfreeze/pre-post scripts) → garantierte Integrität ein.
DB-Konsistenz: API des Backup-Tools (pgBackRest, XtraBackup), Hot-Backup-Modi, Einfrieren von Checkpoints.

6) Verschlüsselung, Schlüssel und Zugriff

At-Rest- und In-Transit-Verschlüsselung für alle Kopien.
Schlüssel in KMS/HSM, Rotation durch Politik (90/180 Tage), getrennte Schlüssel durch Umgebungen.
Aufgabenteilung: Wer erstellt/löscht Backups ≠ wer kann sie entschlüsseln/lesen.
Halten Sie die Entschlüsselungsschlüssel nicht in derselben Vertrauensdomäne wie die Zielkopien.

7) Unveränderliche Kopien und Ransomware-Schutz

Objektsperre/WORM (Compliance/Governance) mit Retench und Legal Hold.
Air-gap: isolierte/Offline-Speicherung (Band, Offline-Cloud/Konto).
Löschrichtlinien „mit verzögerter Aktivierung“, MFA-Löschen, separates Konto für Backup-Backets, Verbot des öffentlichen Zugangs.
Verifizierung auf Malware/Kompromittierungsindikatoren vor dem Mounten.

8) Frequenz, Zeitplan und Retention

GFS (Grandfather-Father-Son): tägliche Inkremente, wöchentliche Full/Diff, monatliche Full mit Langzeitlagerung.
RPO diktiert die Häufigkeit von Inkrementen und WAL/Binlog-Archivierung (z.B. alle 5-15 Minuten).
Lagerung: kritisch - ≥ 35-90 Tage + monatlich für 12-36 Monate (gesetzliche Anforderungen).
Saisonale Spitzen - separate Kontrollpunkte (vor Aktionen/Veröffentlichungen).

9) DR-Modelle und Szenarien

Aktiv-Aktiv: Beide Regionen bedienen den Verkehr. Minimaler RTO, Datenkollaps erfordert eine strenge Konfliktpolitik.
Aktiv-Passiv (heiß/warm): heiß - entfaltet und synchronisiert (RTO Minuten), warm - teilweise fertig (RTO Stunden).
Kalt: Wir speichern Kopien und Terraform/Ansible/Bilder, heben auf Anfrage (RTO Tag +).
DRaaS: Provider-Orchestrierung von VM/Netzwerken/Adressen in einer anderen Zone.

10) Fallover-Orchestrierung und Wiederherstellungsprioritäten

Startpriorität: Netzwerk/VPN/DNS → Geheimnisse/KMS → Basen/Cluster → Warteschlangen/Cache → Anwendungen → Perimeter/CDN → Analytics.
Automatisierung: Skripte/Runbook-Aktionen, Terraform/Ansible/Helm/ArgoCD-Profile für die DR-Umgebung.
Daten: DB PITR → reindex/replica → Warm-Cache → Starten von Diensten mit Schema-Kompatibilitätsflags.
DNS/GSLB: TTL-Downgrade im Voraus, Umschaltszenarien mit Validierung.

11) Wiederherstellungstests (Backup-Verifizierung)

Geplante Restore-Tests: Sampling von N% Backups, Bereitstellung in der „Sandbox“, automatische Schema-/Invariantenprüfungen.
Vollständiger DR-Drill (Spieltag): Region/AZ ausschalten, RTO/RPO auf Live-Verkehr (oder Traffic-Shadow) überprüfen.
Integritätstests: Hash-Verzeichnisse, Prüfsummen, Versuch, alle Ebenen zu lesen (full + chain).
Dockingbericht: Zeit, Schritte, Anomalien, Größe der Lücke von den Zielen, Korrekturen.

12) Praxis für Kerntechnologien

Datenbanken

PostgreSQL: base backup + WAL-Archiv (PITR), pgBackRest/Barman-Tools; Replikationssteckplätze, Kontrolle „lsn“.
MySQL/MariaDB: Percona XtraBackup/Enterprise Backup, Binlog-Archivierung.
MongoDB: 'mongodump' für logische Kopie + Snapshot für große Sets; Oplog für PITR.
Redis: RDB/AOF für kritische (wenn Redis nicht nur Cache ist), aber häufiger - logische Rekonstruktion von Quelle + Snapshot für Unfälle.
Kafka/Pulsar: Metadaten-Backup (ZK/Kraft/BookKeeper), Disk-Snapshots, Topic/Log-Spiegelung.

Kubernetes

etcd snapshot + Velero für Ressourcen/Volumes (CSI Snapshots).
Secrets/PKI separat sichern (Vault Snapshot).
Separates Image-Register: Polysi-Speicherung von Artefakten (immutable tags).

VMs und Dateisysteme

ZFS: 'zfs snapshot' +' zfs send | zstd | send-recv 'in Inkrementen, Überprüfung' scrub'.
LVM/EBS-Snapshots mit Pre/Post-Skripten (app-consistent).
Objektspeicher: Versionen + Objektsperre.

13) Katalogisierung und Versionskontrolle von Backups

Verzeichnis (Katalogisierung der Metadaten): was, wo, wann, als gemacht, Hashes, KMS-Schlüssel, Besitzer, Aufbewahrungsfrist.
Метки/теги: `env=prod|stage`, `system=db|k8s|vm`, `tier=0|1|2`, `retention=35d|1y`.
„Goldene“ Kontrollpunkte (Gold): vor Migrationen/DDL/großen Releases.

14) Beobachtbarkeit und Metriken

Erfolg der Aufgaben:% erfolgreich/überfordert, Gründe.
Backup/Recovery-Zeit, Fensterbreite.
RPO-Ist: Lag der Protokollarchive (WAL/binlog) p95.
Integrität: Anteil der überprüften Ketten, Fehler bei der Hash-Abstimmung.
Kosten: Speicherkapazität nach Klassen, Deduplizierungs-/Komprimierungsverhältnis.
DR-Bereitschaft: Häufigkeit und Ergebnis der Übung (Pass/Fail).

15) Zugangsrichtlinien und Compliance

Getrennte Konten/Projekte für Backup-Speicher; Zugriff nach dem NaC-Prinzip (wir erlauben keine Löschung/Verschlüsselung von Prod-Accounts).
Zugriffs-/Änderungsprotokolle (Audit Trail), Warnungen für Massenentfernungen/Retench-Änderungen.
Compliance: DSGVO (Recht auf Löschung vs Archive), PCI DSS (Verschlüsselung, Schlüssel, Segmentierung), lokale Regulierungsbehörden.

16) Anti-Muster

„Die Replik ist da - das bedeutet, dass kein Backup benötigt wird“.
Keine immutable/air-gap: ein Fehler/malware löscht alles.
Backups im selben Account/Region wie prod.
Überprüfen Sie niemals die Wiederherstellung (Backup „tot vor der Überprüfung“).
Keine Katalogisierung und Versionskontrolle → Chaos bei einem Unfall.
Gemeinsame Verschlüsselungsschlüssel für alle Umgebungen.
Schnappschüsse ohne App-konsistenten Modus für DB.
Das Backup-Fenster überschneidet sich mit Peaks (betrifft p99 und SLO).

17) Checkliste Umsetzung (0-60 Tage)

0-10 Tage

System-/Dateninventar, Kritikalitätsklassen.
Setzen Sie RPO/RTO-Ziele nach Klassen.
Aktivieren Sie full + incremental für Tier-0/1, Archiv WAL/binlog.
Backups verteilen: separate Region/Konto + KMS-Verschlüsselung aktivieren.

11-30 Tage

Konfigurieren Sie immutable (Object Lock/WORM) für kritische Kopien.
Geben Sie Katalogisierung, Tags, Berichterstattung; Alerts für Dips und Log-Magazine.
Erster DR-Drill: Wiederherstellung eines separaten Dienstes aus einem Backup in einer isolierten Umgebung.

31-60 Tage

Automatisieren Sie das Runbook: Terraform/Ansible/Helm-Profile DR.
Regelmäßige Restore-Tests (Woche/Monat) + vierteljährliches komplettes DR-Szenario.
Den Wert zu optimieren: die deduplikazija/Kompressionen/Lebenszyklen der Aufbewahrung.

18) Reifegradkennzahlen

Restore-Tests: ≥ 1/Woche für Tier-0 (selektiv) ≥ 1/Monat - das vollständige Szenario.
Immutable coverage для Tier-0/1 = 100%.
RPO-ist p95 ≤ Ziel (z.B. ≤ 15 min).
RTO-ist auf DR-übungen ≤ Ziel (z.B. ≤ 30 min).
Katalogkomplementierung = 100% (jedes Backup wird beschrieben und verifiziert).
Incident-to-restore: Zeit von der Entdeckung bis zum Start der Wiederherstellung.

19) Beispiele (Snippets)

bash base backup once a day pgbackrest --stanza = prod --type = full backup archive WAL every 5 minutes pgbackrest --stanza = prod archive-push restore to time pgbackrest --stanza = prod restore --type = time --target =" 2025-11-03 14:00:00 + 02"

bash xtrabackup --backup --target-dir=/backup/full-2025-11-01 xtrabackup --backup --incremental-basedir=/backup/full-2025-11-01 --target-dir=/backup/inc-2025-11-02 xtrabackup --prepare --apply-log-only --target-dir=/backup/full-2025-11-01 xtrabackup --prepare --target-dir=/backup/full-2025-11-01 --incremental-dir=/backup/inc-2025-11-02

yaml apiVersion: velero. io/v1 kind: Backup metadata: { name: prod-daily }
spec:
includedNamespaces: ["prod-"]
ttl: 720h storageLocation: s3-immutable

json
{
"Rules": [{
"ID": "prod-immutable",
"Status": "Enabled",
"NoncurrentVersionExpiration": { "NoncurrentDays": 365 }
}]
}

20) Kommunikation und operative Rollen

Incident Commander, Comms Lead, Ops Lead, DB Lead, Security.
Meldungsvorlagen für Stakeholder/Regulatoren/Nutzer.
Post-mortem mit Aktionen: Wo Minuten verloren, wo Automatisierung verbessert wird.

21) Schlussfolgerung

Die zuverlässige Kontur von Backups und DRs besteht nicht darin, "eine Kopie zu erstellen", sondern eine Schleife: Klassifizierung → RPO/RTO-Ziele → mehrstufige und immutable Kopien → automatisierte Runbooks "und → regelmäßige Wiederherstellungen und Übungen. Halten Sie sich an das 3-2-1-1-0, trennen Sie die Replikation von Backups, verschlüsseln und isolieren Sie Schlüssel, dokumentieren und verifizieren Sie. Dann wird auch der „schwarze Schwan“ zu einem überschaubaren Prozess mit vorhersehbaren Ausfallzeiten und minimalem Datenverlust.