Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Restauration en initiant une restauration de table Avec PITR, vous pouvez restaurer une table à une seconde précise dans la fenêtre de restauration PITR. La fenêtre de restauration PITR commence lorsque PITR est activé et contient jusqu'à 35 jours d'historique. Vous pouvez également le configurer pour une durée plus courte. Lorsque vous lancez une restauration complète de la table PITR, tenez compte des points suivants : + La restauration crée une nouvelle table. Une action de restauration de table ne fonctionne pas sur place au-dessus de la table d'origine. Pour les options sur place, consultez[Restauration en annulant les écritures indésirables sur place](bp-pitr-recovery-inplace-rollback.md). + Vous pouvez revenir à une nouvelle table dans la même région ou dans une autre région. La restauration dans une autre région entraîne des frais de transfert de données. + Vous pouvez restaurer la table avec ou sans index secondaires. La restauration sans index secondaires peut être plus rapide et plus rentable. + La restauration peut prendre plusieurs heures. La durée de restauration varie en fonction de plusieurs facteurs et n'est pas toujours corrélée à la taille de la table. Après la restauration de la table PITR, vous pouvez mettre la nouvelle table en service en remplacement complet de la table d'origine. Vous pouvez également le comparer au tableau d'origine pour trouver des différences. Pour une approche plus simple, voir[Restauration en annulant les écritures indésirables sur place](bp-pitr-recovery-inplace-rollback.md). Lorsque vous mettez en service une table restaurée, tenez compte des points suivants : + Pour les environnements d'infrastructure en tant que code (AWS CloudFormation AWS Cloud Development Kit (AWS CDK), Terraform), adoptez la table restaurée dans votre environnement IaC pour la gérer. + Mettez à jour les connexions client pour faire référence à la nouvelle table par son nouveau nom. + Re-add paramètres de diffusion s'ils se trouvaient sur l'original. Le nom du flux DynamoDB inclut l'heure de création du flux, de sorte que le nouveau flux porte un nom différent de l'ancien flux. Mettez à jour toutes les références à l'ancien nom de flux dans IAM ou dans le code consommateur en aval. + Re-enable PITR sur la nouvelle table s'il se trouvait sur la table d'origine. + Re-enable protection contre la suppression sur la nouvelle table si elle se trouvait sur la table d'origine. + Re-add balises vers la nouvelle table si les balises se trouvaient sur la table d'origine. + Re-add les politiques fondées sur les ressources sur le nouveau tableau si les pratiques commerciales restrictives figuraient sur l'original. + Mettez à jour toutes les politiques IAM d'accès entre comptes qui font référence à la table d'origine. + Réglez les paramètres de mise à l'échelle automatique sur le nouveau tableau. + Définissez l'attribut TTL sur la nouvelle table si le TTL figurait sur l'original. + Ajustez la classe de table sur la nouvelle table si l'original comportait une classe de table personnalisée. + Vérifiez les paramètres de débit chaud sur le nouveau tableau et augmentez les valeurs de lecture et d'écriture si nécessaire. + Ajoutez des répliques pour la nouvelle table afin qu'elle corresponde à la table d'origine s'il s'agit d'une table globale. + Supprimez la table d'origine une fois que la table restaurée a été entièrement configurée et mise en service. Si vous restaurez une table globale MRSC, la table nouvellement restaurée ne peut pas être transformée en table MRSC car seules les tables vides peuvent être transformées en tables MRSC. Une solution consiste à restaurer la table, puis à copier les données de la table restaurée dans une table MRSC vide.