PointInTimeRecoveryUnavailableException

TL;DR — Point-in-Time Recovery ist auf dieser Quelltabelle nie aktiviert worden, es gibt also keine Continuous-Backup-Historie zum Wiederherstellen. Aktivier PITR jetzt (UpdateContinuousBackups) — das Recovery-Fenster beginnt ab diesem Moment — und für alles davor stellst du aus einem On-Demand-Backup wieder her, falls du eines hast.

Was es bedeutet

PointInTimeRecoveryUnavailableException: Point in time recovery has not
yet been enabled for this source table.

# what the engine actually returns, reproduced against Amazon DynamoDB (live service, us-east-1):
PointInTimeRecoveryUnavailableException: Point in time recovery is not enabled for table 'seo-repro-scratch'

PITR ist pro Tabelle optional zu aktivieren. Bis es aktiv ist, führt DynamoDB keine kontinuierliche Änderungshistorie, und RestoreTableToPointInTime hat nichts, woraus es wiederaufbauen könnte — unabhängig davon, wie lange die Tabelle bereits existiert. Das ist eine Konfigurationslücke, kein vorübergehender Fehler; ein Wiederholen ändert die Antwort nicht.

Warum es passiert

PITR wurde nie aktiviert — es ist standardmäßig aus, wenn eine Tabelle erstellt wird, ohne es explizit einzuschalten.
Eine neue Tabelle hat die Checkliste verpasst — Infrastrukturcode, der aus einer Vorlage kopiert wurde, die PointInTimeRecoverySpecification nicht setzt.
Der falsche Tabellenname — du stellst orders wieder her, aber PITR war auf orders-prod aktiviert (oder umgekehrt), oder die Tabelle liegt in einer anderen Region.

So behebst du es

Bestätige den Backup-Zustand der Tabelle:

aws dynamodb describe-continuous-backups --table-name orders
# PointInTimeRecoveryStatus: DISABLED

Aktiviere PITR — der Schutz beginnt sich sofort aufzubauen, und das Wiederherstellungsfenster wächst von jetzt an bis zum konfigurierten Wiederherstellungszeitraum:
```
aws dynamodb update-continuous-backups --table-name orders \
  --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
```
Stelle die heutigen Daten anders wieder her — PITR kann die Vergangenheit nicht rückwirkend erreichen. Wenn ein On-Demand-Backup existiert, nutze RestoreTableFromBackup; andernfalls ist der aktuelle Tabelleninhalt das, was du hast.
Backe PITR in die Tabellenerstellung ein — setze es in deinem IaC für jede Produktionstabelle, damit die Lücke nicht erneut auftreten kann, und denke daran, dass eine wiederhergestellte Tabelle PITR ebenfalls nicht erbt — aktiviere es auf der neuen Tabelle erneut.

Bevor du entscheidest, wie wichtig die Wiederherstellung pro Tabelle ist, schau dir an, was in ihnen steckt — die DynoTable-Desktop-App gibt dir diese Ansicht über Konten und Regionen hinweg, und der DynamoDB-Preisrechner beziffert die Speicherkosten kontinuierlicher Backups.

Vor dem Retry in DynoTable

Bevor du decide which tables need PITR, browse their contents in DynoTable — open each table with ⌘K across Regions (⌘P switches proDateien auf) and confirm the data is worth continuous-backup cost. The Pricing-Rechner estimates PITR storage charges per table so you can prioritize production workloads.

Nachdem enabling PITR, verify backup status from the AWS console or CLI, then spot-check restored data in DynoTable once a test restore completes. Konfiguriere Profile unter Einstellungen → Profile with Verbindung testen for each Region. Siehe Mit AWS verbinden und Installation. PITR storage accrues from the enablement moment — there is no retroactive window for data written bevor du turned it on.

Quellen

RestoreTableToPointInTime — Amazon DynamoDB API Reference (verifiziert 2026-07-13)
Point-in-time recovery for DynamoDB (verifiziert 2026-07-13)

Referenzen

Zuletzt verifiziert am 2026-07-13 gegen die oben verlinkte offizielle AWS-Dokumentation.