InvalidRestoreTimeException

TL;DR — 你請求的 RestoreDateTime 在這張表的時間點恢復視窗之外。PITR 讓你恢復到恢復期內（可在 1 到 35 天之間配置，最多為最近 35 天）的任意一秒——但視窗也不能早於 PITR 啟用之前開始。從 DescribeContinuousBackups 讀取表的實際視窗並選擇一個在其內部的時間，或者傳入 UseLatestRestorableTime 表示"儘可能新"。

這是什麼意思

InvalidRestoreTimeException: An invalid restore time was specified.
RestoreDateTime must be between EarliestRestorableDateTime and
LatestRestorableDateTime.

每張啟用 PITR 的表都帶有一個滾動視窗，其下界為 EarliestRestorableDateTime（回溯到恢復期，但絕不早於 PITR 被開啟之前），上界為 LatestRestorableDateTime（通常約為當前時間之前 5 分鐘）。在這些界限之外——太舊，或太接近_現在_——的恢復請求會以這個異常失敗。

為什麼會發生

時間早於恢復期——你要恢復的事故發生在視窗之前（最多 35 天，如果配置了更短的期限則更少）。
PITR 是最近才啟用的——視窗從啟用時開始；即使在 35 天內，你也無法恢復到那一刻之前。
時間太新——LatestRestorableDateTime 落後於真實時間約 5 分鐘；"恢復到 30 秒前"還不在視窗內。
時區/格式失誤——一個本地時間的時間戳被髮送到本應是 UTC 紀元秒的地方，會在你沒注意到的情況下落到視窗之外。

如何修正

先讀取實際視窗：

aws dynamodb describe-continuous-backups --table-name orders
# ...PointInTimeRecoveryDescription:
#    EarliestRestorableDateTime, LatestRestorableDateTime

選一個在其內部的 RestoreDateTime（紀元秒，UTC），或者不指定時間而取最新可用的狀態：

aws dynamodb restore-table-to-point-in-time \
  --source-table-name orders --target-table-name orders-recovered \
  --use-latest-restorable-time

需要比視窗更舊的資料？ PITR 夠不到它——退而使用一個按需備份，或那個時期拍攝的表匯出（如果存在的話）。
記住恢復不會攜帶什麼——新表會得到資料、索引、容量和加密設定，但你必須重新建立自動擴縮策略、IAM 策略、CloudWatch 告警、標籤、stream 設定、TTL，以及 PITR 本身。

恢復落地後，在切換流量之前先核實恢復的資料——DynoTable 桌面應用把恢復後的表與預期對比變成一項瀏覽任務，而 DynamoDB 定價計算器會估算新表的容量成本。

在 DynoTable 中開啟

恢復完成後，瀏覽DynoTable中恢復的表 - 使用⌘K開啟它，並在切斷流量之前根據事件時間線抽查項目。透過使用 ⌘P 切換設定檔案來與源表進行比較。使用 pricing calculator 調整新表的容量。在“設定”→“設定檔案”下為每個區域配置設定檔案“Test Connection”。參見連線 AWS和安裝。

來源

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

參考資料

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