PointInTimeRecoveryUnavailableException

TL;DR — 這張源表沒有啟用時間點恢復，因此沒有可供恢復的連續備份歷史。現在就啟用 PITR（UpdateContinuousBackups）——恢復視窗從那一刻開始——而對於此前的任何東西，如果你有按需備份就從中恢復。

這是什麼意思

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 是逐表選擇加入的。在它開啟之前，DynamoDB 不保留連續變更歷史，而 RestoreTableToPointInTime 無從重建——無論表已經存在多久。這是一個配置缺口，而非瞬時錯誤；重試不會改變答案。

為什麼會發生

從未啟用 PITR——在建立表時未顯式開啟它，它預設是關閉的。
一張新表漏了清單——從一個不設定 PointInTimeRecoverySpecification 的模板複製來的基礎設施程式碼。
表名錯誤——你在恢復 orders，但 PITR 是在 orders-prod 上啟用的（或反之），或者表位於另一個區域。

如何修正

確認表的備份狀態：

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

啟用 PITR——保護立即開始累積，恢復視窗從現在增長到配置的恢復期：

aws dynamodb update-continuous-backups --table-name orders \
  --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true

用另一種方式恢復今天的資料——PITR 無法追溯地回到過去。如果存在一個按需備份，就 RestoreTableFromBackup 它；否則當前的表內容就是你所擁有的。
把 PITR 烘焙進表建立——在你的 IaC 中為每張生產表設定它，讓這個缺口不會復發，並記住一張_恢復出來的_表也不會繼承 PITR——在新表上重新啟用它。

在決定每張表的恢復有多重要之前，先看看它們裡面有什麼——DynoTable 桌面應用給你一個跨帳戶和區域的檢視，而 DynamoDB 定價計算器會為連續備份的儲存成本給出一個數字。

在 DynoTable 中重試之前

在決定哪些表需要 PITR 之前，請在 DynoTable 中瀏覽其內容 — 使用 ⌘K 跨區域開啟每個表（⌘P 切換設定檔案），並確認資料值得連續備份成本。 pricing calculator 估算每個表的 PITR 儲存費用，以便你可以確定生產工作負載的優先順序。啟用 PITR 後，從 AWS 主控台或 CLI 驗證備份狀態，然後在測試恢復完成後抽查 DynoTable 中恢復的資料。在“設定”→“設定檔案”下為每個區域配置設定檔案“Test Connection”。參見連線 AWS和安裝。 PITR 儲存從啟用時刻開始累積 - 在啟用之前寫入的資料沒有追溯視窗。

來源

RestoreTableToPointInTime — Amazon DynamoDB API Reference（2026-07-13 驗證）
Point-in-time recovery for DynamoDB（2026-07-13 驗證）

參考資料

最後核實於 2026-07-13，依據上方連結的 AWS 官方文件。