PointInTimeRecoveryUnavailableException

TL;DR — Point-in-time recovery has not been enabled on this source table, so there's no continuous-backup history to restore from. Enable PITR now (UpdateContinuousBackups) — the recovery window starts from that moment — and for anything before it, restore from an on-demand backup if you have one.

What it means

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 is opt-in per table. Until it's on, DynamoDB keeps no continuous change history, and RestoreTableToPointInTime has nothing to rebuild from — regardless of how long the table has existed. This is a configuration gap, not a transient error; retrying won't change the answer.

Why it happens

PITR was never enabled — it's off by default when a table is created without explicitly turning it on.
A new table missed the checklist — infrastructure code copied from a template that doesn't set PointInTimeRecoverySpecification.
The wrong table name — you're restoring orders but PITR was enabled on orders-prod (or the other way around), or the table lives in another Region.

How to fix it

Confirm the table's backup state:

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

Enable PITR — protection starts accruing immediately, and the restore window grows from now up to the configured recovery period:
```
aws dynamodb update-continuous-backups --table-name orders \
  --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
```
Recover today's data another way — PITR can't reach the past retroactively. If an on-demand backup exists, RestoreTableFromBackup it; otherwise the current table contents are what you have.
Bake PITR into table creation — set it in your IaC for every production table so the gap can't recur, and remember a restored table doesn't inherit PITR either — re-enable it on the new table.
Check the correct Region. PITR is per-table per-Region; a restore call against a replica in another Region still needs PITR enabled on that Region's table copy.

Before you retry in DynoTable

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

After enabling PITR, verify backup status from the AWS console or CLI, then spot-check restored data in DynoTable once a test restore completes. Configure profiles under Settings → Profiles with Test Connection for each Region. See Connect to AWS and Install. PITR storage accrues from the enablement moment — there is no retroactive window for data written before you turned it on.

Sources

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

InvalidRestoreTimeException — PITR is on, but the requested time is outside the window.
Export requires PITR — table exports need PITR too.
BackupNotFoundException
Learn: Backups & point-in-time recovery

References

Last verified 2026-07-13 against the official AWS documentation linked above.