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 官方文档。

InvalidRestoreTimeException

含义

为什么会发生

如何修复

在 DynoTable 中打开

来源

相关错误

参考资料