DynamoDB-Backup & Point-in-Time Recovery

DynamoDB schützt deine Daten auf zwei Arten. On-Demand-Backups sind vollständige Snapshots, die du erstellst und beliebig lange aufbewahrst. Point-in-Time Recovery (PITR) ist ein kontinuierliches, automatisches Backup, mit dem du die Tabelle auf jede beliebige Sekunde innerhalb eines rollierenden Fensters zurücksetzen kannst. Beide stellen in eine neue Tabelle wieder her — es sind Recovery-Werkzeuge, keine Rückgängig-Taste.

Für das Audit-Log ist das nicht verhandelbar. Es ist ein unveränderlicher Compliance-Nachweis; eine fehlerhafte Migration, die Events umschreibt, oder ein versehentliches Massenlöschen muss bis zum 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, mit denen du auf jede beliebige Sekunde innerhalb eines konfigurierbaren Fensters von 1 bis 35 Tagen wiederherstellen kannst. On-Demand-Backups sind manuelle vollständige Snapshots, die beliebig lange aufbewahrt werden. Beide stellen in eine neue Tabelle wieder her, niemals über das Original — es sind also Recovery-Werkzeuge und keine Rückgängig-Taste am Ort.

• 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, beliebig lange aufbewahrt, unabhängig vom PITR-Fenster.
• Wiederherstellungen erstellen eine neue Tabelle. Du stellst unter einem neuen Namen wieder her und schaltest dann um — das Original bleibt unberührt.
• PITR wird nach Tabellengröße abgerechnet, nicht nach der Anzahl der Wiederherstellungspunkte — schätze es mit dem DynamoDB Pricing Calculator.

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

DynamoDB hat kein Transaktionslog, das du zurückrollen kannst, und kein "Undo" für einen Write. Wenn ein Migrationsskript das action-Feld jedes Events umschreibt oder jemand ein Delete ausführt, das weiter greift 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 Nachweis zu sein — ist "wir bekommen die Events von letztem Dienstag nicht zurück" ein Compliance-Versagen, nicht bloß eine Unannehmlichkeit.

Wie Backup und PITR funktionieren

Point-in-Time Recovery erstellt, einmal aktiviert, kontinuierliche automatische Backups. Laut den AWS-Docs bietet PITR "fully managed, automatic continuous backups of table data with up to 35 days of recovery points at per-second granularity." Das Fenster ist über RecoveryPeriodInDays von 1 bis 35 Tagen konfigurierbar, und du kannst auf jede Sekunde darin wiederherstellen — auch in eine andere Region.

Ein wichtiger Sonderfall: Das Verringern des Recovery-Zeitraums reduziert sofort den frühesten Wiederherstellungspunkt, und das Deaktivieren und erneute Aktivieren von PITR setzt die wiederherstellbare Startzeit zurück — du verlierst die bisherige kontinuierliche Historie.

On-Demand-Backups sind separat: manuelle vollständige Tabellen-Snapshots, die du explizit erstellst und unbegrenzt aufbewahrst, nützlich für einen Checkpoint vor einer Migration oder ein langfristiges Compliance-Archiv jenseits des 35-Tage- PITR-Fensters.

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

Ein durchgespieltes Beispiel: Wiederherstellung nach einer fehlerhaften Migration

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

Die beschädigte Tabelle bleibt unberührt, während du die Wiederherstellung prüfst — du vergleichst die wiederhergestellten Events mit den live laufenden, bestätigst, dass die action-Werte zurück sind, und schaltest dann die App um. Bei der Wiederherstellung selbst wird nichts zerstört.

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

In DynoTable umsetzen

Eine Wiederherstellung ist nur so gut wie deine Überprüfung davon. Nachdem du in 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 vor dem Umschalten mit der Live-Tabelle vergleichen kannst — so wird aus einer Wiederherstellung statt eines Vertrauenssprungs eine verifizierte Recovery.

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

Fallstricke und nächste Schritte

• Aktiviere PITR, bevor du es brauchst. Es schützt erst ab dem Moment, in dem es aktiv 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. Aus- und Wiedereinschalten löscht die kontinuierliche Historie; die wiederherstellbare Startzeit beginnt mit der erneuten Aktivierung von vorn.
• Wiederherstellungen sind weder sofort noch kostenlos. Eine Wiederherstellung provisioniert eine komplett neue Tabelle und dauert proportional zur Größe; plane die Dauer und die zusätzliche Tabelle ein.
• 35 Tage sind keine Archivierung. Für eine Aufbewahrung über das PITR-Fenster hinaus erstelle On-Demand-Backups oder exportiere nach S3 — PITR ist ein Recovery-Fenster, kein Langzeitspeicher.

Damit schließt sich der Audit-Log-Betriebskreis: Transaktionen für Konsistenz, Streams für Reaktion, TTL für Ablauf, der richtige Capacity-Modus für die Kosten, Global Tables für regionale Resilienz und PITR für die Datenwiederherstellung. Wirf nochmal einen Blick auf den Überblick Operations & Cost, um zu sehen, wie sie zusammenpassen.

DynoTable herunterladen, um dich mit einer wiederhergestellten Tabelle zu verbinden und deine Recovery zu verifizieren, bevor du ihr vertraust.