Backup-Strategie

Zweck

Dieses Dokument definiert eine praxisnahe und auditierbare Backup-Strategie für Produktionsdaten und zugehörige Systeme. Das Ziel ist, die Geschäftskontinuität und eine kontrollierte Wiederherstellung nach Benutzerfehlern, Datenkorruption, Infrastrukturfehlern und Sicherheitsvorfällen sicherzustellen.

Aktueller Stand

• Dateien werden in IONOS S3 gespeichert.
• Datenbank-Backups werden in IONOS S3 gespeichert.

Die providerseitige Redundanz bei IONOS schützt gegen lokale Hardwareausfälle, ist jedoch für sich allein keine vollständige Backup-Strategie. Sie adressiert versehentliches Löschen, böswillige Änderungen, ransomware-ähnliche Verschlüsselung oder kompromittierte Zugangsdaten nicht ausreichend.

Zielprinzip: 3-2-1

Das Zielmodell folgt der 3-2-1-Regel:

• 3 Kopien der Daten (1 primäre + 2 Backup-Kopien)
• 2 unterschiedliche Speichertypen oder Plattformen
• 1 Kopie extern und vom primären Betriebsumfeld isoliert

Geltungsbereich

Die Backup-Strategie gilt für:

• Objekt-/Dateidaten (Anwendungs-Uploads, generierte Dateien, Exporte)
• Datenbanken (Voll- und, falls unterstützt, Point-in-Time-fähige Backups)
• Konfiguration und Metadaten (ohne Klartext-Secret-Werte)

Wiederherstellungsziele

Pro Workload müssen explizite Ziele definiert und gepflegt werden:

• RPO (Recovery Point Objective): maximal akzeptables Datenverlustfenster
• RTO (Recovery Time Objective): maximal akzeptable Wiederherstellungsdauer

Empfohlene Basiswerte, bis systemspezifische Werte finalisiert sind:

• Kritische Systeme: RPO <= 1h, RTO <= 4h
• Wichtige Systeme: RPO <= 24h, RTO <= 24h
• Systeme mit niedriger Kritikalität: RPO <= 24h, RTO <= 72h

Zielarchitektur

1. Primärer Betriebsspeicher

• IONOS S3 (aktive Produktionsdaten)

2. Sekundärer unveränderlicher Backup-Speicher

• Unabhängiger S3-kompatibler Provider mit:
  • Object Lock (WORM / Unveränderlichkeit)
  • Bucket-Versionierung
  • Separaten Zugangsdaten und restriktiven Zugriffspolicys

Mögliche Provider:

• Hetzner Object Storage (unterstützt Versionierung und Object Lock, pro Bucket/Policy verifizieren)
• STACKIT Object Storage (Object Lock und Versionierung vor Einsatz verifizieren)

3. Tertiäre Offline-/Lokalkopie

• Lokaler Speicher (z. B. NAS) mit:
  • Snapshot-Unterstützung
  • Eingeschränktem Netzwerkzugriff
  • Dedizierten Backup-Zugangsdaten
  • Optionalem periodischem Offline-Export auf externe Medien für Ransomware-Resilienz

Aufbewahrungsrichtlinie

Mindest-Basisaufbewahrung (an Compliance- und Kostenvorgaben anpassen):

• Tägliche Backups: 30 Tage
• Wöchentliche Backups: 12 Wochen
• Monatliche Backups: 12 Monate
• Jährliche Archiv-Backups: 3-7 Jahre (gemäß rechtlicher/compliance-relevanter Anforderungen)

Richtlinie zur Unveränderlichkeit:

• Object Lock für kritische Backup-Sätze aktivieren
• Aufbewahrungsfenster so wählen, dass auch spät erkannte Vorfälle abgedeckt sind

Sicherheitskontrollen

• Backups bei Übertragung (TLS) und im Ruhezustand verschlüsseln (Provider- oder kundenseitig verwaltete Schlüssel).
• Dedizierte Backup-Service-Accounts verwenden, nie mit Runtime-Workloads teilen.
• Least-Privilege-Prinzip erzwingen: wenn möglich nur Schreibzugriff für Backup-Jobs, Leserechte nur für Restore-Operatoren.
• Identitätsdomänen zwischen primären und sekundären Providern trennen.
• Löschen von Backups durch Mehrpersonenfreigabe absichern, sofern unterstützt.
• Backup-Zugangsdaten regelmäßig und nach Vorfällen rotieren.

Backup-Betrieb

Zeitplanung

• Datenbanken:
  • Tägliches Vollbackup + häufige inkrementelle/Log-Backups (gemäß RPO)
  • Regelmäßige Restore-Konsistenzprüfungen
• Objekt-/Dateidaten:
  • Häufige inkrementelle Synchronisation
  • Täglicher Konsistenz-Snapshot

Verifikation

Backups sind nur valide, wenn sie wiederhergestellt werden können. Umsetzen:

• Automatisches Monitoring des Backup-Job-Status
• Prüfsummen-/Integritätsverifikation
• Geplante Restore-Tests in isolierten Umgebungen

Restore-Tests

Mindest-Testrhythmus für Wiederherstellungen:

• Monatlich: Stichproben-Restore von Dateien und einer nicht-kritischen Datenbank
• Quartalsweise: Vollständiger Restore-Drill eines kritischen Services
• Nach größeren Architekturänderungen: anlassbezogene Restore-Validierung

Pro Test dokumentieren:

• Zeitstempel
• Wiederhergestellter Datensatz
• Gemessenes RTO/RPO
• Probleme und Folgemaßnahmen

Recovery-Prozess bei Vorfällen

Im Recovery-Fall:

1. Vorfallstyp klassifizieren (Löschung, Korruption, Kompromittierung, Infrastrukturausfall).
2. Letzten bekannten konsistenten Backup-Satz identifizieren.
3. Bei Verdacht auf Kompromittierung in isolierter Umgebung wiederherstellen.
4. Integrität und Anwendungsfunktion validieren.
5. Wiederhergestellten Zustand über den freigegebenen Change-Prozess in Produktion überführen.
6. Zeitablauf, Ursache und Korrekturmaßnahmen dokumentieren.

Rollen und Verantwortlichkeiten

• Platform/Operations:
  • Backup-Jobs, Speicherpolicys und Monitoring betreiben
• Security:
  • Zugriffsmodell, Unveränderlichkeitseinstellungen und Credential-Rotation freigeben
• Service Owner:
  • RPO/RTO definieren und funktionale Restore-Ergebnisse validieren
• Management:
  • Trade-offs zwischen Aufbewahrung, Kosten und Risiko freigeben

Umsetzungs-Roadmap

1. RPO/RTO pro System finalisieren und Daten nach Kritikalität klassifizieren.
2. Sekundären S3-Provider mit Object Lock + Versionierung auswählen und bereitstellen.
3. Dedizierte Backup-Identitäten und IAM-Einschränkungen einführen.
4. Backup-Pipelines für Datenbanken und Objektdaten konfigurieren.
5. Tertiären lokalen/offline Kopierprozess ergänzen.
6. Monitoring, Alerting und Reporting für Backup-Jobs implementieren.
7. Ersten vollständigen Restore-Drill durchführen und Runbook-Ergebnisse dokumentieren.

Zusammenfassung aktueller Lücken

• Es besteht aktuell eine Single-Provider-Abhängigkeit.
• Unveränderlichkeit und providerübergreifende Isolation sind noch nicht vollständig erzwungen.
• Restore-Tests und messbare Recovery-KPIs sind noch nicht formal dokumentiert.

Abnahmekriterien

Diese Strategie gilt als umgesetzt, wenn:

• Für alle kritischen Daten im Geltungsbereich mindestens drei unabhängige Kopien existieren.
• Eine Backup-Kopie unveränderlich und extern bei einem separaten Provider liegt.
• Restore-Tests planmäßig laufen und vereinbarte RPO/RTO-Ziele erfüllen.
• Backup-Monitoring und Incident-Runbooks aktiv sind und regelmäßig überprüft werden.