DynamoDB Backup und Point-in-Time Recovery: Der vollständige Leitfaden

DynamoDB schützt deine Daten auf zwei Wegen. On-Demand-Backups sind vollständige Snapshots, die du erstellst und unbegrenzt behältst. Point-in-Time Recovery (PITR) ist ein kontinuierliches, automatisches Backup, das dir erlaubt, die Tabelle auf jede Sekunde innerhalb eines rollenden Fensters wiederherzustellen. Beide stellen in eine neue Tabelle wieder her — sie sind Wiederherstellungswerkzeuge, kein Rückgängig-Knopf.

Für das Audit-Log ist das nicht verhandelbar. Es ist ein unveränderlicher Compliance-Datensatz; eine schlechte Migration, die Events umschreibt, oder eine versehentliche Massenlöschung muss auf den Moment vor dem Fehler wiederherstellbar sein.

Wie funktionieren DynamoDB Backup und Point-in-Time Recovery?

DynamoDB bietet zwei Backup-Typen. Point-in-Time Recovery (PITR) erstellt kontinuierliche automatische Backups und lässt dich auf jede Sekunde innerhalb eines konfigurierbaren Fensters von 1 bis 35 Tagen wiederherstellen. On-Demand-Backups sind manuelle vollständige Snapshots, die unbegrenzt aufbewahrt werden. Beide stellen in eine neue Tabelle wieder her, nie über die ursprüngliche, sodass sie Wiederherstellungswerkzeuge sind statt ein In-Place-Rückgängig.

• PITR = kontinuierliches Backup, Wiederherstellung auf jede Sekunde innerhalb eines konfigurierbaren Fensters von 1 bis 35 Tagen (früher waren es feste 35).
• On-Demand-Backups = manuelle vollständige Snapshots, so lange aufbewahrt, wie du willst, unabhängig vom PITR-Fenster.
• Wiederherstellungen erzeugen eine neue Tabelle. Du stellst unter einem neuen Namen wieder her und schaltest dann um — die ursprüngliche bleibt unberührt.
• PITR wird nach Tabellengröße bepreist, nicht nach der Anzahl der Wiederherstellungspunkte — schätze es mit dem DynamoDB-Preisrechner.

Das Problem: ein Fehler, den du nicht an Ort und Stelle rückgängig machen kannst

DynamoDB hat kein Transaktions-Log, das du zurückrollen kannst, und kein „Rückgängig" auf einem Schreibvorgang. Wenn ein Migrationsskript das action-Feld jedes Events umschreibt oder jemand eine Löschung ausführt, die breiter ist als beabsichtigt, ist die Tabelle einfach im falschen Zustand. Ohne Backups sind die Daten weg.

Für ein Audit-Log — dessen gesamter Wert darin besteht, ein vertrauenswürdiger Datensatz zu sein — ist „wir bekommen die Events von letztem Dienstag nicht zurück" ein Compliance-Versagen, nicht nur eine Unannehmlichkeit.

Wie Backup und PITR funktionieren

Point-in-Time Recovery erstellt, einmal aktiviert, kontinuierliche automatische Backups. Laut der AWS-Dokumentation gibt dir PITR vollständig verwaltete kontinuierliche Backups der Tabellendaten mit sekundengenauer Wiederherstellung. Das Fenster ist von 1 bis 35 Tagen über RecoveryPeriodInDays konfigurierbar, und du kannst auf jede Sekunde darin wiederherstellen — bis auf etwa fünf Minuten hinter Echtzeit (LatestRestorableDateTime) — auch in eine andere Region.

Ein wichtiger Grenzfall: Das Verkürzen des Wiederherstellungszeitraums reduziert sofort den frühesten Wiederherstellungspunkt, und das Deaktivieren und anschließende Reaktivieren von PITR setzt die wiederherstellbare Startzeit zurück — du verlierst die vorherige kontinuierliche Historie.

PITR ist außerdem die Voraussetzung für den verwalteten Export nach S3: Der Export liest aus denselben kontinuierlichen Backups, sodass ExportTableToPointInTime bei ausgeschaltetem PITR mit PointInTimeRecoveryUnavailableException fehlschlägt.

On-Demand-Backups sind separat: manuelle, vollständige Tabellen-Snapshots, die du explizit erstellst und unbegrenzt aufbewahrst, nützlich für einen Vor-Migrations-Checkpoint oder ein langfristiges Compliance-Archiv jenseits des 35-Tage-PITR-Fensters. Die Anfrage wird sofort verarbeitet und das Backup ist innerhalb von Minuten wiederherstellbar, verbraucht keinen Durchsatz der Tabelle, und es gibt keine Obergrenze dafür, wie viele du aufbewahrst. Ein ehrlicher Vorbehalt aus den Docs: On-Demand-Backups garantieren keine kausale Konsistenz über Items hinweg — der Versatz zwischen Updates ist „usually much less than a second“, aber ein Backup mitten in einem Schreib-Burst ist kein einzelner eingefrorener Zeitpunkt.

Was eine Wiederherstellung nicht zurückbringt

Eine Wiederherstellung erzeugt die Daten der Tabelle und ihre Indizes neu — nicht ihre operative Verkabelung. Laut den AWS-Docs musst du auf der wiederhergestellten Tabelle manuell neu konfigurieren: Auto-Scaling-Policies, IAM-Policies, CloudWatch-Metriken und -Alarme, Tags, Stream-Einstellungen, TTL, Löschschutz und PITR selbst. Aus einem Backup wiederherzustellen und dabei zu vergessen, PITR wieder zu aktivieren, ist genau der Weg, auf dem der nächste Vorfall nicht mehr behebbar wird.

Bei der Wiederherstellung kannst du einige Einstellungen bewusst ändern — Abrechnungsmodus, provisionierte Kapazität, Verschlüsselungsschlüssel — und du kannst einige oder alle Secondary Indexes weglassen, was die Wiederherstellung schneller und günstiger macht, wenn du sie später neu aufbauen kannst. Wiederherstellungen können außerdem eine andere Region als Ziel haben, und eine Wiederherstellung überschreibt nie eine bestehende Tabelle.

Geplante Backups mit AWS Backup

Die eigenen On-Demand-Backups von DynamoDB haben keinen Scheduler. Für wiederkehrende Backups mit Aufbewahrung ist DynamoDB nativ in AWS Backup integriert (AWS-Docs): Backup-Pläne geben dir geplante Backups mit Lifecycle-Regeln (inklusive Cold-Storage-Tiering), automatische konten- und regionsübergreifende Kopien für DR, einen unabhängigen KMS-Schlüssel über den Backup-Vault und Vault Lock für eine WORM-Compliance-Haltung, die niemand still löschen kann. Zwei operative Fallstricke: AWS Backup ist ein explizites Opt-in pro Konto und pro Region, und die davon erzeugten Backups (Typ AWS_BACKUP) lassen sich nicht aus der DynamoDB-Konsole löschen — verwalte sie in AWS Backup.

Beide stellen in eine neue Tabelle wieder her, nicht über die bestehende:

Ein ausgearbeitetes Beispiel: Erholung von einer schlechten Migration

Eine Migration, die ein expiresAt-Attribut hinzufügen sollte, überschrieb stattdessen action bei jedem Event mit einem leeren String. PITR ist mit einem 35-Tage-Fenster aktiv, also stellst du auf die Sekunde vor dem Lauf der Migration wieder her:

Die korrupte Tabelle bleibt unberührt, während du die Wiederherstellung überprüfst — du vergleichst die wiederhergestellten Events mit den Live-Events, bestätigst, dass die action-Werte zurück sind, und zeigst dann die App neu. Bei der Wiederherstellung selbst wird nichts zerstört.

Wäre der Verlust eine Handvoll Items statt einer Korruption der ganzen Tabelle, könntest du stattdessen die Live-Daten und die wiederhergestellte Kopie inspizieren und nur die betroffenen Zeilen hinüberkopieren — siehe eine DynamoDB-Tabelle kopieren.

In DynoTable umsetzen

Eine Wiederherstellung ist nur so gut wie deine Überprüfung von ihr. Nachdem du auf audit-log-restored wiederhergestellt hast, musst du dir die wiederhergestellten Events tatsächlich ansehen und bestätigen, dass sie dem entsprechen, was sie vor dem Fehler hätten sein sollen.

DynoTable verbindet sich mit der wiederhergestellten Tabelle wie mit jeder anderen, sodass du die Events des betroffenen Tenants abfragen, bestätigen kannst, dass die action-Werte korrekt sind, und gegen die Live-Tabelle vergleichen kannst, bevor du umschaltest — was eine Wiederherstellung von einem Sprung ins Ungewisse in eine verifizierte Erholung verwandelt.

Du kannst die wiederhergestellten Events auch für einen Offline-Compliance-Datensatz exportieren — siehe DynamoDB nach CSV exportieren.

Fallstricke und nächste Schritte

• Aktiviere PITR, bevor du es brauchst. Es schützt nur ab dem Moment, in dem es an ist — es gibt keine rückwirkende Wiederherstellung. Schalte es für jede Tabelle ein, deren Daten du dir nicht leisten kannst zu verlieren.
• Das Deaktivieren von PITR setzt das Fenster zurück. Es aus- und wieder einzuschalten löscht die kontinuierliche Historie; die wiederherstellbare Startzeit beginnt ab der Reaktivierung von neuem.
• Wiederherstellungen sind weder sofort noch kostenlos. Eine Wiederherstellung stellt eine ganz neue Tabelle bereit und dauert proportional zur Größe; kalkuliere die Dauer und die zusätzliche Tabelle ein.
• 35 Tage sind kein Archiv. Für Aufbewahrung jenseits des PITR-Fensters erstelle On-Demand-Backups oder exportiere nach S3 — PITR ist ein Wiederherstellungsfenster, kein Langzeitspeicher.

Damit schließt sich die Betriebsschleife für das Audit-Log: Transaktionen für Konsistenz, Streams für Reaktion, TTL für Ablauf, der richtige Kapazitätsmodus für Kosten, Global Tables für Regionsresilienz und PITR für Datenwiederherstellung. Sieh dir den Überblick über Operationen & Kosten noch einmal an, um zu sehen, wie sie zusammenpassen.

Lade DynoTable herunter, um dich mit einer wiederhergestellten Tabelle zu verbinden und deine Wiederherstellung zu überprüfen, bevor du ihr vertraust.