# Backups, die Sie nie wiederhergestellt haben, sind keine Backups. Eine Restore-Übung, gestoppt.
Jeder AWS-Datenspeicher hat Backups standardmäßig oder per Häkchen aktiviert. Aurora hält automatische Backups. DynamoDB hat Point-in-Time-Recovery. S3 hat Versionierung. Die Konsole zeigt grüne Haken, der Compliance-Fragebogen bekommt ein „ja“, und niemand hat je tatsächlich etwas wiederhergestellt, also weiß niemand, wie lange ein Restore dauert, ob er funktioniert oder was kaputtgeht, wenn die wiederhergestellte Kopie einen anderen Namen hat.
Wir machen jedes Quartal eine Restore-Übung, in ein separates Konto, mit Stoppuhr. Das hier ist die Übung des letzten Quartals: was wir wiederhergestellt haben, wie lange jeder Schritt dauerte, die vier Dinge, die scheiterten, und was die Zahlen über unsere echten Wiederherstellungsziele sagen, im Gegensatz zu denen auf der Folie.
## Was gesichert wird, und wie
Der Zustand der Plattform lebt an drei Orten: ein Aurora-Serverless-v2-Cluster, sechs DynamoDB-Tabellen und zwei S3-Buckets. Die Backups, alle in CDK definiert:
| Speicher | Mechanismus | Aufbewahrung | Wo die Kopie liegt |
|---|---|---|---|
| Aurora | Automatisches kontinuierliches Backup, Point-in-Time | 35 Tage | Gleiches Konto, plus ein täglicher Snapshot per AWS Backup ins Backup-Konto kopiert |
| DynamoDB | Point-in-Time-Recovery, kontinuierlich | 35 Tage | Gleiches Konto, plus tägliches AWS Backup in einen kontoübergreifenden Vault |
| S3 | Versionierung + Lifecycle | Alte Versionen 90 Tage | Gleicher Bucket, plus Replikation ins Backup-Konto |
| Secrets, Parameter | AWS Backup deckt diese nicht ab | n/a | Aus den [CDK-Definitionen und einer Checkliste](/de/blog/secrets-in-cdk-secrets-manager-ssm-or-nothing-in-the-template) neu aufgebaut |
Die kontoübergreifende Kopie ist der Teil, den Leute überspringen. Ein Backup im selben Konto wie Produktion schützt vor einer schlechten Migration oder einem vertippten Löschen. Es schützt nicht davor, dass das Konto selbst kompromittiert wird, oder vor einem `cdk destroy` mit falschem Kontext, [das Dinge mit ausgeschaltetem RETAIN löscht](/de/blog/cloudformation-deleted-our-app-runner-services). AWS Backup mit einem Vault in einem separaten Konto, mit Vault Lock, ist das, was die Kopie den schlimmsten Tag überleben lässt. Es kostet bei unserer Größe etwa $6 im Monat.
## Die Übung, mit Stoppuhr
Das Szenario: Die Produktionsdaten ab 14:00 gestern sind korrupt; alles auf 13:55 wiederherstellen und die Anwendung auf den wiederhergestellten Daten hochfahren. In Staging, aus dem Backup-Konto, mit der Smoke-Test-Suite als Definition von „läuft“. Ein Engineer, ohne Hilfe, nach dem Runbook.
| Schritt | Zeit | Anmerkungen |
|---|---|---|
| Aurora: Cluster aus der Vault-Kopie auf einen Zeitpunkt wiederherstellen | 22 Min | Neuer Cluster, neuer Endpunkt. Serverless v2, 0,5 ACU |
| Aurora: Smoke-Abfrage, Zeilenzahlen gegen das Metrik-Dashboard prüfen | 3 Min | Stimmten überein |
| DynamoDB: sechs Tabellen aus dem Vault wiederherstellen, parallel | 31 Min | Die größte Tabelle, 18 GB, brauchte 28 davon |
| DynamoDB: PITR und TTL auf den wiederhergestellten Tabellen wieder aktivieren | 4 Min | Der Restore übernimmt diese nicht. Auch nicht Auto-Scaling, Tags oder den Stream |
| S3: für dieses Szenario nichts wiederherzustellen; nur Versionierungsprüfung | 2 Min | |
| App umhängen: neuen Cluster-Endpunkt und Tabellennamen nach SSM schreiben | 5 Min | Hätte 1 Minute sein sollen; siehe Fehler 3 |
| App-Runner-Services und Lambdas neu starten, damit sie die neuen Parameter lesen | 6 Min | |
| Smoke-Tests grün | 4 Min | |
| **Gesamt** | **77 Min** | |
Siebenundsiebzig Minuten für einen vollständigen Restore auf einen Zeitpunkt, durch eine Person, die Anweisungen folgt. Das ist das echte Recovery Time Objective, und diese Zahl gehört ins Runbook, nicht das „unter einer Stunde“, das vor der ersten Übung auf der Folie stand.
## Die vier Dinge, die scheiterten
Die erste Übung vor einem Jahr dauerte vier Stunden und wurde nicht fertig. Jedes Quartal seitdem hat etwas gefunden. Die vier vom letzten Quartal:
**1. Die KMS-Schlüsselrichtlinie erlaubte dem Staging-Konto nicht, den Aurora-Snapshot zu entschlüsseln.** Die Vault-Kopie ist mit einem Schlüssel im Backup-Konto verschlüsselt. Ein Restore nach Staging braucht in der Schlüsselrichtlinie `kms:Decrypt` und `kms:CreateGrant` für die Restore-Rolle des Staging-Kontos. Sie gewährte sie der von Produktion. Der Restore scheiterte mit einem Berechtigungsfehler, der zwanzig Minuten brauchte, um richtig gelesen zu werden. In CDK behoben: Die Schlüsselrichtlinie listet jetzt jedes Konto, das wiederherstellen könnte.
**2. Der DynamoDB-Restore verwirft die Tabelleneinstellungen.** Eine wiederhergestellte Tabelle hat die Daten und das Key-Schema und sonst nichts: kein PITR, kein TTL-Attribut, kein Auto-Scaling, keine Tags, keinen Stream. Unsere App verlässt sich auf TTL, um Sessions ablaufen zu lassen, und auf den Stream, um den Suchindex zu speisen. Ohne einen Checklistenschritt zum Reaktivieren „funktionierte“ die wiederhergestellte App und hörte still auf, Sessions ablaufen zu lassen. Jetzt ist es ein Schritt im Runbook und, besser, ein kleines Skript, das die Einstellungen aus der CDK-Definition auf eine benannte Tabelle anwendet.
**3. Eine Lambda hatte den Tabellennamen hartkodiert.** Elf von zwölf Funktionen lesen ihre Tabellennamen aus SSM-Parametern, sodass das Umhängen ein Parameter-Schreiben war. Eine, die älteste, hatte den Produktionstabellennamen als Literal in ihrer Umgebung. Sie schrieb während der Übung munter weiter in die *alte* Tabelle, was bei einer echten Wiederherstellung bedeutet hätte, neue Daten in den korrupten Speicher zu schreiben. Gefunden, weil der Smoke-Test für diese Funktion scheiterte. Behoben, indem der Name wie bei den anderen nach SSM wanderte, und durch eine CI-Prüfung, die Umgebungsblöcke nach allem greppt, was einem Ressourcennamen-Muster entspricht.
**4. Die Restore-Rolle in Staging konnte kein `PassRole` an die Aurora-Servicerolle.** Eine einzeilige IAM-Auslassung, entdeckt bei Minute 30, behoben bei Minute 35, und eine Erinnerung daran, dass der Restore-Pfad seinen eigenen Satz Berechtigungen hat, den nichts außer der Übung ausübt.
Nichts davon wäre durch einen Blick auf die grünen Haken gefunden worden. Alle vier hätten aus einem echten Vorfall statt „schlechter Nachmittag“ eine „schlechte Woche“ gemacht.
## Die Zahlen, die dabei herauskamen
Recovery Point Objective: fünf Minuten für Aurora und DynamoDB, weil Point-in-Time-Recovery kontinuierlich ist; S3 ist per Versionierung sofort. Dieser Teil stimmte schon vor der Übung.
Recovery Time Objective: 77 Minuten für einen vollständigen Restore, etwa 30 für eine einzelne DynamoDB-Tabelle, etwa 25 für Aurora allein. Diese Zahlen waren vor der Übung Fiktion und sind jetzt Messungen. Sie stehen im Runbook und in der Statusseiten-Vorlage, sodass die Nachricht während einer echten Wiederherstellung „Restore läuft, voraussichtlich fertig um 15:20“ lautet statt „bald“.
Kosten der Übung: etwa $4 an wiederhergestellten Ressourcen für den Nachmittag, plus der Nachmittag eines Engineers. Kosten, sie nicht zu machen: unbekannt bis zu dem Tag, an dem es zählt, und das ist der falsche Tag, um es zu lernen.
## Das Runbook, verdichtet
- Den Zielzeitpunkt festlegen. Aufschreiben, bevor irgendetwas angefasst wird.
- In das isolierte Konto wiederherstellen. Nie über Produktion; daneben wiederherstellen und umhängen.
- Aurora: Point-in-Time-Restore aus der Vault-Kopie; Zeilenzahlen gegen eine bekannte Metrik prüfen.
- DynamoDB: alle Tabellen parallel wiederherstellen; dann das Einstellungsskript für PITR, TTL, Streams, Auto-Scaling, Tags ausführen.
- S3: die Objektversionen zum Zielzeitpunkt identifizieren; bei Bedarf vorwärts kopieren.
- Umhängen: Die Anwendung liest jeden Ressourcennamen aus SSM. Die neuen Namen schreiben. Nichts ist hartkodiert, und CI erzwingt das.
- Alles neu starten, was Parameter cacht.
- Smoke-Tests. Nicht „es lädt“: die Suite, die Checkout, Login und den Suchindex ausübt.
- Jeden Schritt stoppen. Das RTO im Runbook aktualisieren, wenn es sich verschoben hat.
- Abbauen und die einseitige Notiz schreiben, was scheiterte.
Vierteljährlich. Im Kalender. Jedes Mal mit einem anderen Engineer, denn der Punkt ist, dass das Runbook für die Person funktioniert, die es nicht geschrieben hat.
Wenn Ihre Backups grüne Haken und keine Restore-Historie haben, [machen wir die erste Übung mit Ihnen](/contact). Planen Sie einen Nachmittag ein und rechnen Sie damit, etwas zu finden.