- Startseite
- Skills
- Bereitstellung
- Backup- und Wiederherstellungsplaner
Backup- und Wiederherstellungsplaner
Backup- und Disaster-Recovery-Plaene entwerfen, die tatsaechlich funktionieren — denn ungetestete Backups sind nur Hoffnungen, keine Plaene.
Das Problem
Sie haben Backups laufen, aber haben Sie jemals tatsaechlich aus einem wiederhergestellt? Die meisten Teams entdecken, dass ihre Backup-Strategie defekt ist, wenn sie sie am dringendsten brauchen — nach Datenverlust, Ransomware oder einem versehentlichen DELETE ohne WHERE. Backups ohne getestete Wiederherstellungsprozeduren sind nur teurer Speicher. Ein echter Disaster-Recovery-Plan umfasst RPO-, RTO-Ziele, automatisierte Verifikation und ein Runbook, dem jeder im Team um 3 Uhr nachts folgen kann.
Der Prompt
Du bist ein Disaster-Recovery-Architekt. Entwirf einen umfassenden Backup- und Wiederherstellungsplan fuer meine Anwendung.
ANWENDUNGSDETAILS:
- Zu schuetzende Daten: [z.B. PostgreSQL-Datenbank, User-Uploads in S3, Redis-Cache, Anwendungskonfiguration]
- Datenvolumen: [z.B. 50 GB Datenbank, 200 GB Dateien, waechst 5 GB/Monat]
- Hosting: [z.B. AWS RDS, selbstverwaltetes PostgreSQL, MongoDB Atlas, VPS]
- Aktuelle Backups: [z.B. taegliches pg_dump, verwaltete Snapshots, keine]
- Compliance: [z.B. DSGVO, HIPAA, SOC2, keine spezifischen]
Entwirf die Backup-Strategie:
1. **RPO/RTO-Definition**: Definiere Recovery Point Objective und Recovery Time Objective fuer jeden Datentyp.
2. **Backup-Methoden**: Full, inkrementell und kontinuierlich — was wann verwenden, mit Zeitplanung.
3. **Speicher-Strategie**: Wo Backups gespeichert werden, Verschluesselung, Aufbewahrungsstufen.
4. **Automatisierte Verifikation**: Wie automatisch getestet wird, dass Backups gueltig und wiederherstellbar sind.
5. **Wiederherstellungs-Runbook**: Schritt-fuer-Schritt-Wiederherstellungsprozedur fuer jedes Desaster-Szenario.
6. **Desaster-Szenarien**: Plan fuer jedes — einzelner Table-Drop, Datenbankkorruption, vollstaendiger Region-Ausfall, Ransomware.
7. **Test-Zeitplan**: Wie oft jedes Wiederherstellungsszenario mit dem Team geuebt wird.
Beispielausgabe
RPO/RTO-Ziele:
- Datenbank: RPO=1 Stunde (max 1 Stunde Datenverlust), RTO=30 Min (Wiederherstellung innerhalb 30 Min)
- User-Uploads (S3): RPO=24 Stunden, RTO=2 Stunden
- Anwendungskonfiguration: RPO=0 (versioniert in Git), RTO=5 Min (Redeployment)
Backup-Zeitplan (PostgreSQL):
- Kontinuierlich: WAL-Archivierung nach S3 (Point-in-Time-Recovery, RPO < 1 Min)
- Taeglich: Vollstaendiges pg_dump um 03:00 UTC → verschluesselt → S3 Cross-Region
- Woechentlich: Snapshot → Cold Storage (Glacier)
- Aufbewahrung: 7 taegliche, 4 woechentliche, 12 monatliche
Wann einsetzen
Verwenden Sie diesen Skill beim Launch eines neuen Services mit Nutzerdaten, nach einem Datenverlust-Incident, wenn Compliance dokumentierte Backup-Prozeduren erfordert, oder wenn Sie feststellen, dass Sie nie eine Wiederherstellung getestet haben.
Profi-Tipps
- Testen Sie Ihre Wiederherstellungen regelmaessig — planen Sie monatliche Wiederherstellungsuebungen. Ein ungetestetes Backup ist kein Backup.
- Trennen Sie Backup-Credentials von Anwendungs-Credentials — wenn ein Angreifer Ihre App kompromittiert, sollte er nicht Ihre Backups loeschen koennen.
- Point-in-Time-Recovery rettet Karrieren — WAL-Archivierung (PostgreSQL) ermoeglicht Wiederherstellung auf jede Sekunde, nicht nur den letzten Snapshot.
- 3-2-1-Regel — 3 Kopien der Daten, auf 2 verschiedenen Medientypen, mit 1 Kopie an einem anderen Standort.