InvalidRestoreTimeException

TL;DR — Le RestoreDateTime que tu as demandé est en dehors de la fenêtre de récupération à un instant dans le passé (PITR) de cette table. Le PITR te permet de restaurer à n'importe quelle seconde dans la période de récupération (configurable entre 1 et 35 jours, au plus les 35 derniers jours) — mais la fenêtre ne peut pas non plus commencer avant l'activation du PITR. Lis la fenêtre réelle de la table via DescribeContinuousBackups et choisis une heure à l'intérieur, ou passe UseLatestRestorableTime pour « le plus récent possible ».

Ce que ça signifie

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

Chaque table avec PITR activé porte une fenêtre glissante bornée par EarliestRestorableDateTime (jusqu'à la période de récupération en arrière, mais jamais avant l'activation du PITR) et LatestRestorableDateTime (généralement environ 5 minutes avant l'heure actuelle). Une requête de restauration en dehors de ces bornes — trop ancienne, ou trop proche de maintenant — échoue avec cette exception.

Pourquoi ça arrive

L'heure est plus ancienne que la période de récupération — l'incident dont tu récupères s'est produit avant la fenêtre (35 jours au maximum, moins si une période plus courte est configurée).
Le PITR a été activé récemment — la fenêtre commence à l'activation ; tu ne peux pas restaurer à un moment antérieur, même dans les 35 jours.
L'heure est trop récente — LatestRestorableDateTime est en retard d'environ 5 minutes sur l'heure réelle ; « restaurer à il y a 30 secondes » n'est pas encore dans la fenêtre.
Décalages de fuseau horaire/de format — un horodatage en heure locale envoyé là où des secondes epoch UTC étaient attendues tombe en dehors de la fenêtre sans que tu t'en aperçoives.

Comment corriger

Lis d'abord la fenêtre réelle :

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

Choisis un RestoreDateTime à l'intérieur (secondes epoch, UTC), ou prends l'état disponible le plus récent sans nommer d'heure :

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

Besoin de données plus anciennes que la fenêtre ? Le PITR ne peut pas les atteindre — replie-toi sur une sauvegarde à la demande ou un export de table pris à cette époque, s'il en existe un.
Souviens-toi de ce qu'une restauration n'emporte pas — la nouvelle table récupère les données, les index, la capacité et les paramètres de chiffrement, mais tu dois recréer les politiques d'auto scaling, les politiques IAM, les alarmes CloudWatch, les tags, les paramètres de flux, le TTL et le PITR lui-même.

Une fois la restauration terminée, vérifie les données récupérées avant de basculer le trafic — l'application de bureau DynoTable fait de la comparaison de la table récupérée avec les attentes une simple tâche de navigation, et le calculateur de tarification DynamoDB dimensionne le coût en capacité de la nouvelle table.

Erreurs liées

PointInTimeRecoveryUnavailableException — le PITR n'est pas du tout activé.
Export requires PITR — le cousin de cette fenêtre au moment de l'export.
Table already exists — le nom cible est déjà pris.
Apprends : Sauvegardes & récupération à un instant dans le passé

Références

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus.