View a markdown version of this page

Sauvegardes continues et restauration instantanée (PITR) - AWS Backup

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.

Sauvegardes continues et restauration instantanée (PITR)

Pour certaines ressources, AWS Backup prend en charge les sauvegardes continues et la restauration instantanée (PITR) en plus des sauvegardes instantanées.

Avec les sauvegardes continues, vous pouvez restaurer votre ressource AWS Backup prise en charge en la remontant à l'heure précise de votre choix, avec une précision d'une seconde (en remontant à 35 jours maximum). La sauvegarde continue fonctionne en créant d'abord une sauvegarde complète de votre ressource, puis en sauvegardant constamment les journaux de transactions de votre ressource. PITR fonctionne en accédant à votre sauvegarde complète et en relisant le journal des transactions jusqu'au moment indiqué AWS Backup pour la restauration.

Il est également possible d'effectuer des sauvegardes d'instantanés toutes les heures. Les sauvegardes d'instantanés peuvent être stockées pendant 100 ans au maximum. Les instantanés peuvent être copiés pour des sauvegardes complètes ou incrémentielles.

Étant donné que les sauvegardes continues et d'instantanés présentent des avantages différents, nous vous recommandons de protéger vos ressources à l'aide de règles de sauvegarde continues et instantanées.

Une sauvegarde à la demande commence immédiatement à sauvegarder votre ressource. Vous pouvez choisir une sauvegarde à la demande si vous souhaitez créer une sauvegarde à un moment autre que celui défini dans un plan de sauvegarde. Une sauvegarde à la demande peut être utilisée, par exemple, pour tester la sauvegarde et les fonctionnalités à tout moment.

Vous ne pouvez pas utiliser les sauvegardes à la demande avec PITR, car une sauvegarde à la demande préserve les ressources dans l'état dans lequel elles se trouvaient au moment de la sauvegarde, tandis que PITR utilise des sauvegardes continues, qui enregistrent les modifications sur une période donnée.

Vous pouvez opter pour des sauvegardes continues pour les ressources prises en charge lorsque vous créez un plan de sauvegarde à AWS Backup l'aide de la AWS Backup console ou de l'API. Le plan de sauvegarde continue crée un point de restauration continu et met à jour ce point de restauration chaque fois que la tâche est exécutée.

Point-in-time considérations relatives au rétablissement

Tenez compte des considérations suivantes pour la récupération ponctuelle :

  • Retour automatique aux instantanés : si AWS Backup n'est pas en mesure d'effectuer une sauvegarde continue, il essaie plutôt d'effectuer une sauvegarde par instantané.

  • Aucune prise en charge des sauvegardes continues à la demande  : AWS Backup ne prend pas en charge la sauvegarde continue à la demande car la sauvegarde à la demande enregistre un moment dans le temps, alors que les enregistrements de sauvegarde continue changent au fil du temps.

  • Aucune prise en charge pour la transition vers le stockage à froid : les sauvegardes continues ne prennent pas en charge la transition vers le stockage à froid, car la transition vers le stockage à froid nécessite une période de transition minimale de 90 jours, tandis que les sauvegardes continues ont une période de rétention maximale de 35 jours.

  • Restauration de l'activité récente  : l'activité Amazon RDS autorise les restaurations jusqu'aux 5 dernières minutes d'activité ; Aurora autorise les restaurations jusqu'à l'activité la plus récente, comme indiqué par LatestRestorableTime (généralement moins de 5 minutes) ; Amazon S3 autorise les restaurations jusqu'aux 15 dernières minutes d'activité.

Important

Une seule ressource ne peut avoir qu'une seule sauvegarde continue. Développez ci-dessous pour plus de détails et les meilleures pratiques.

Chaque ressource (telle qu'un compartiment Amazon S3 ou une base de données Amazon RDS) ne peut avoir qu'une seule sauvegarde continue (point de restauration) ; les sauvegardes continues supplémentaires sont redondantes. Lorsque plusieurs politiques, plans ou règles de sauvegarde demandent de AWS Backup créer plusieurs sauvegardes continues pour la même ressource, le processus suivant s'applique :

  • Si plusieurs règles spécifient que plusieurs sauvegardes continues doivent se trouver dans un seul coffre, suivez la règle dont AWS Backup la période de conservation est la plus longue (cycle de vie) et ignore les règles supplémentaires.

  • Si plusieurs règles spécifient que plusieurs sauvegardes continues doivent se trouver dans plus d'un coffre, AWS Backup crée une sauvegarde continue conformément à la première règle traitée. Chaque règle suivante spécifiant une sauvegarde continue pour une ressource qui dispose déjà d'une sauvegarde continue se traduira par une sauvegarde instantanée (périodique) à la place.

Lorsque des plans de sauvegarde continue dupliqués se produisent, les sauvegardes instantanées créées après le point de restauration continue peuvent afficher un état deCompleted with issues. Les informations détaillées de ce point de restauration afficheront une erreur similaire à“Enabling continuous backup failed, because of the following error: PITR already configured in backup plan: [ARN]”. Cette erreur indique qu'au moins une sauvegarde continue est déjà configurée (pour un point de restauration différent de celui contenant l'erreur). Cette première sauvegarde continue (point de restauration) peut être utilisée pour une restauration ponctuelle (PITR) tant que son état est. COMPLETED

Pour éviter la création d'instantanés involontaires présentant des problèmes (et un message d'erreur), passez en revue la stratégie de sauvegarde de votre organisation. Si nécessaire, ajustez les plans et les politiques de sauvegarde qui créent plusieurs sauvegardes continues de la même ressource.

Une fois que vous avez effectué des ajustements qui n'entraînent qu'une seule sauvegarde continue pour une ressource, les sauvegardes instantanées sont conservées conformément au cycle de vie spécifié du plan qui les a créées, puis elles sont transférées EXPIRED et supprimées. La sauvegarde continue et sa capacité de restauration instantanée seront maintenues conformément à la règle qui l'a créée.

Services pris en charge pour la sauvegarde continue et le PITR

AWS Backup prend en charge les sauvegardes continues et la restauration instantanée pour les services et applications suivants :

Amazon S3

Pour activer la PITR pour les sauvegardes S3, les sauvegardes continues doivent faire partie du plan de sauvegarde.

Bien que la PITR puisse être active dans cette sauvegarde d'origine du compartiment source, les copies de destination entre régions ou entre comptes ne comporteront pas la PITR, et la restauration à partir de ces copies les rétablira la date à laquelle elles ont été créées (les copies seront des copies instantanées) au lieu d'être restaurées à un moment précis.

AWS Backup pour S3 repose sur la réception d'événements S3 via Amazon EventBridge. Si ce paramètre est désactivé dans les paramètres de notification des compartiments S3, les sauvegardes continues s'arrêteront pour ces compartiments, le paramètre étant désactivé. Pour de plus amples informations, veuillez consulter EventBridge Dépendance à Amazon pour les sauvegardes continues S3.

La désactivation AWS Backup de la EventBridge règle Amazon entraînera également l'arrêt continu de votre sauvegarde. Si vous avez un plan de sauvegarde actif avec une règle de sauvegarde continue, lorsque cette règle est redéclenchée, la EventBridge règle Amazon AWS Backup sera recréée et une nouvelle sauvegarde continue sera créée.

RDS

AWS Backup prend en charge les sauvegardes continues et la restauration instantanée pour toutes les instances Amazon RDS et Aurora qui sont prises en charge par le service Amazon RDS natif. AWS Backup ne prend pas en charge les sauvegardes continues ni la restauration instantanée pour les clusters Amazon RDS Multi-AZ .

Planifications de sauvegarde : lorsque vous activez les sauvegardes continues pour une instance Amazon RDS via AWS Backup, AWS Backup prend en charge la fenêtre de sauvegarde automatique Amazon RDS (l'instantané quotidien natif qui ancre la restauration instantanée). AWS Backup positionne cette fenêtre de sauvegarde automatique à proximité de la fenêtre de maintenance Amazon RDS pour éviter les conflits. Vous ne pouvez pas configurer directement la fenêtre de sauvegarde automatique tout en AWS Backup gérant les sauvegardes continues, mais vous pouvez influencer son emplacement en ajustant votre fenêtre de maintenance Amazon RDS. La fenêtre de sauvegarde automatique se repositionne lors du cycle de sauvegarde suivant. RDS prend des instantanés une fois par jour, même si un plan de sauvegarde prévoit une fréquence de sauvegarde des instantanés autre qu'une fois par jour.

Note

AWS Backup ne modifie ni ne gère la fenêtre de maintenance Amazon RDS. La fenêtre de maintenance reste sous votre contrôle et peut être ajustée via les paramètres Amazon RDS. Les tâches de sauvegarde initiées par une règle de capture instantanée de votre plan de sauvegarde s'exécutent selon le calendrier que vous définissez et peuvent toujours échouer si elles chevauchent la fenêtre de maintenance. Si cela se produit, vous recevez une erreur similaire à « La tâche de sauvegarde n'a pas pu démarrer car elle se trouve dans la fenêtre de maintenance hebdomadaire configurée dans l'instance RDS ou trop proche de celle-ci ». Pour éviter cette erreur, planifiez vos règles de sauvegarde des snapshots en dehors de la fenêtre de maintenance Amazon RDS que vous avez configurée.

Paramètres : après avoir appliqué une règle de sauvegarde AWS Backup continue à une instance Amazon RDS, vous ne pouvez ni créer ni modifier les paramètres de sauvegarde continue dans Amazon RDS. Vous devez apporter des modifications via la AWS Backup console ou l' AWS Backup interface de ligne de commande. Lorsque vous activez les sauvegardes automatisées pour la première fois, une panne se produit si vous modifiez la période de rétention des sauvegardes de l'instance de base de données de 0 à une valeur différente de zéro. Planifiez ce changement pendant une période de maintenance afin de minimiser son impact. Pour plus d'informations sur l'activation des sauvegardes automatisées, consultez la section Activation des sauvegardes automatisées dans le guide de l'utilisateur Amazon RDS.

Transférez le contrôle de la sauvegarde continue d'une instance Amazon RDS à Amazon RDS :

Console
  1. Ouvrez la AWS Backup console à l'adresse https://console.aws.amazon.com/backup.

  2. Dans le panneau de navigation, choisissez Backup plans (Plans de sauvegarde).

  3. Supprimez tous les plans de sauvegarde Amazon RDS avec une sauvegarde continue protégeant cette ressource.

  4. Choisissez Coffres-forts de sauvegarde. Supprimez le point de récupération des sauvegardes continues de votre coffre-fort de sauvegarde. Ou attendez que leur période de rétention soit écoulée, ce qui entraînera AWS Backup la suppression automatique du point de restauration.

Une fois ces étapes terminées, le contrôle de sauvegarde continu de votre ressource AWS Backup sera transféré à Amazon RDS.

AWS CLI

Appelez l'opération de l'API DisassociateRecoveryPoint.

Pour en savoir plus, veuillez consulter la section DisassociateRecoveryPoint.

Autorisations IAM requises pour les sauvegardes continues Amazon RDS
  • AWS Backup Pour configurer des sauvegardes continues pour votre base de données Amazon RDS, vérifiez que l'autorisation d'API rds:ModifyDBInstance existe dans le rôle IAM défini par la configuration de votre plan de sauvegarde. Pour restaurer les sauvegardes continues Amazon RDS, vous devez ajouter l'autorisation rds:RestoreDBInstanceToPointInTime au rôle IAM que vous avez soumis pour la tâche de restauration. Vous pouvez utiliser le AWS Backup default service role pour effectuer des sauvegardes et des restaurations.

  • Pour décrire la plage de temps disponible pour une récupération ponctuelle, AWS Backup appelez. rds:DescribeDBInstanceAutomatedBackups Dans la AWS Backup console, vous devez disposer de l'autorisation d'rds:DescribeDBInstanceAutomatedBackupsAPI dans votre politique gérée Gestion des identités et des accès AWS (IAM). Vous pouvez utiliser les politiques gérées par AWSBackupFullAccess ou AWSBackupOperatorAccess. Les deux politiques disposent de toutes les autorisations requises. Pour plus d'informations, consultez Stratégies gérées .

Périodes de conservation : lorsque vous modifiez votre période de conservation PITR, AWS Backup des appels ModifyDBInstance pour appliquer cette modification.

Lorsque vous AWS Backup activez PITR pour la première fois sur une instance Amazon RDS (en changeant la rétention de 0 à une valeur différente de zéro), l'opération est planifiée pour avoir lieu lors de la prochaine fenêtre de maintenance de votre base de données afin d'éviter toute interruption inattendue.

Scénarios :

  • First-time Activation PITR : lorsque PITR est activé sur une instance Amazon RDS pour la première fois (qu'elle soit gérée par AWS Backup ou configurée directement), la modification est mise en file d'attente pour la fenêtre de maintenance suivante. AWS Backup crée automatiquement des sauvegardes instantanées pour maintenir la couverture jusqu'à ce que PITR soit actif.

  • Modifications de la rétention PITR : Non-zero les modifications de rétention non nulles s'appliquent immédiatement sans redémarrage.

  • Désactivation du PITR : le passage d'une rétention non nulle à une rétention nulle est planifié pour la prochaine fenêtre de maintenance.

Couverture des sauvegardes pendant la transition :

  • Les sauvegardes instantanées fournissent une protection en attendant la fenêtre de maintenance

  • Les points de restauration continue deviennent disponibles lorsque la tâche de sauvegarde s'exécute après l'activation de PITR

  • Aucune lacune dans la protection des sauvegardes ne se produit pendant la période de transition

  • La granularité de restauration peut être limitée à des intervalles de capture d'écran jusqu'à ce que PITR soit complètement actif

Remarque : L'arrêt de l'instance RDS supprimera les modifications en attente. Les modifications de configuration PITR seront demandées lors de la prochaine tâche de sauvegarde et appliquées lors d'une fenêtre de maintenance ultérieure.

Copies des sauvegardes continues d'Amazon RDS :

  • Création de copies des sauvegardes continues Amazon RDS — Vous ne pouvez pas créer de copies des sauvegardes continues Amazon RDS car AWS Backup Amazon RDS n'autorise pas la copie des journaux de transactions. Créez plutôt AWS Backup un instantané et copiez-le à la fréquence spécifiée dans le plan de sauvegarde.

Restaurations : vous pouvez effectuer une restauration instantanée à l'aide de l'un AWS Backup ou de l'autre d'Amazon RDS. Pour les instructions relatives à AWS Backup la console, consultez la section Restauration d'une base de données Amazon RDS. Pour obtenir des instructions Amazon RDS, consultez Restauration d'une instance de base de données à une date spécifiée dans le Guide de l'utilisateur Amazon RDS.

Astuce

Une instance de base de données multi-AZ (zone de disponibilité) configurée sur ne Always On doit pas avoir de rétention des sauvegardes définie sur zéro. Si des erreurs se produisent, utilisez la AWS CLI commande disassociate-recovery-point au lieu dedelete-recovery-point, puis modifiez le paramètre de rétention sur 1 dans vos paramètres Amazon RDS.

Pour des informations générales sur le fonctionnement avec Amazon RDS, consultez le Guide de l'utilisateur Amazon RDS.

Exemples de CLI pour la restauration RDS et Aurora PITR

Les exemples suivants montrent comment restaurer les bases de données RDS et Aurora à un moment précis à l'aide de l' AWS Backup interface de ligne de commande avec des paramètres de métadonnées.

Exemple : restauration de la base de données RDS à un moment précis avec des métadonnées

aws backup start-restore-job \ --recovery-point-arn arn:aws:backup:us-east-1:123456789012:recovery-point:1EB3B5E7-9EB0-435A-A80B-108B488B0D45 \ --metadata '{"DBInstanceIdentifier":"restored-db-instance","Engine":"mysql","UseLatestRestorableTime":"false","RestoreTime":"2024-01-15T10:30:00Z"}' \ --iam-role-arn arn:aws:iam::123456789012:role/service-role/AWSBackupDefaultServiceRole \ --resource-type RDS \ --copy-source-tags-to-restored-resource
Exemple : Restaurer le cluster Aurora à un moment donné

aws backup start-restore-job \ --recovery-point-arn arn:aws:backup:us-east-1:123456789012:recovery-point:2FC4C6F8-0FC1-546B-B91C-209C599C1D56 \ --metadata '{"DBClusterIdentifier":"restored-aurora-cluster","Engine":"aurora-mysql","UseLatestRestorableTime":"true"}' \ --iam-role-arn arn:aws:iam::123456789012:role/service-role/AWSBackupDefaultServiceRole \ --resource-type Aurora \ --copy-source-tags-to-restored-resource
Paramètres de métadonnées pour la restauration RDS PITR

Les paramètres de métadonnées suivants sont pris en charge pour les restaurations RDS et Aurora PITR :

  • DBInstanceIdentifier(RDS) ou DBClusterIdentifier (Aurora) - Obligatoire. Nom de la base de données restaurée.

  • Moteur  : obligatoire. Le moteur de base de données (par exemple, mysql, postgres, aurora-mysql, aurora-postgresql).

  • UseLatestRestorableTime- Facultatif. Réglez sur « true » pour rétablir la dernière heure restaurable, ou sur « false » pour spécifier un RestoreTime.

  • RestoreTime- Facultatif. Date et heure de restauration (format ISO 8601). Obligatoire si UseLatestRestorableTime c'est « faux ».

Copier les balises vers la ressource restaurée

Utilisez l'--copy-source-tags-to-restored-resourceindicateur pour copier les balises de la base de données source vers la base de données restaurée. Cela garantit que les contrôles d'accès basés sur les balises et les balises de répartition des coûts sont préservés.

Pour plus de détails sur les paramètres de restauration RDS PITR, consultez :

Aurora

Pour activer la sauvegarde continue de vos ressources Aurora, consultez les étapes décrites dans la première section de cette page.

La procédure de restauration d'un cluster Aurora à un instant dans le passé est une variante des étapes de restauration d'un instantané d'un cluster Aurora.

Lorsque vous effectuez une restauration à un instant dans le passé, la console affiche une section heure de restauration. Consultez Restauration d'une sauvegarde continue plus bas sur cette page dans Utilisation des sauvegardes continues.

Important

Les sauvegardes continues Aurora sont prises en charge dans les coffres-forts protégés par AWS Backup Vault Lock, et les paramètres de conservation minimum et maximum du coffre-fort sont appliqués au point de restauration. Cependant, les sauvegardes continues d'Aurora ne prennent pas en charge la fonction de coffre-fort logiquement espacé. Pour utiliser un coffre-fort logiquement espacé avec Aurora, utilisez plutôt des sauvegardes instantanées périodiques.

L'objectif de point de restauration (RPO) pour les sauvegardes continues d'Aurora est généralement inférieur à 5 minutes, car Aurora copie les données vers Amazon S3 en continu en arrière-plan. Utilisez cette LatestRestorableTime valeur pour déterminer le point le plus récent auquel vous pouvez effectuer une restauration.

Périodes de conservation et fenêtres de sauvegarde : lorsque vous activez ou modifiez les paramètres de sauvegarde continue pour un cluster Aurora, des AWS Backup appels vous ModifyDBCluster demandent d'appliquer ces modifications. Cela peut modifier celui du clusterPreferredBackupWindow. Si d'autres mises à jour de configuration sont en attente de la prochaine fenêtre de maintenance, l'activation des sauvegardes continues peut également appliquer immédiatement ces modifications en attente.

Note

AWS Backup Pour configurer des sauvegardes continues pour votre cluster Aurora, vérifiez que l'autorisation d'API rds:ModifyDBCluster existe dans le rôle IAM défini par la configuration de votre plan de sauvegarde.

SAP HANA sur des instances Amazon EC2

Vous pouvez effectuer des sauvegardes continues, qui peuvent être utilisées avec la restauration à un instant dans le passé (PITR) (notez que les sauvegardes à la demande préservent les ressources dans l'état dans lequel elles sont prises, tandis que la PITR utilise des sauvegardes continues qui enregistrent les modifications au fil du temps).

Avec les sauvegardes continues, vous pouvez restaurer votre base de données SAP HANA sur une instance EC2 en la rétablissant à l'heure précise de votre choix, avec une seconde de précision (en remontant au maximum 35 jours en arrière). La sauvegarde continue fonctionne en créant d'abord une sauvegarde complète de votre ressource, puis en sauvegardant constamment les journaux de transactions de votre ressource. La restauration PITR fonctionne en accédant à votre sauvegarde complète et en relisant le journal des transactions jusqu'au moment indiqué AWS Backup pour la restauration.

Vous pouvez opter pour les sauvegardes continues lorsque vous créez un plan de sauvegarde à AWS Backup l'aide de la AWS Backup console ou de l'API.

Pour activer les sauvegardes continues à l'aide de la console
  1. Connectez-vous au Console de gestion AWS, puis ouvrez la AWS Backup console à l'adresse https://console.aws.amazon.com/backup.

  2. Dans le volet de navigation, choisissez Plans de sauvegarde, puis Créer un plan de sauvegarde.

  3. Sous Règles de sauvegarde, choisissez Ajouter une règle de sauvegarde.

  4. Dans la section Configuration de règle de backup, sélectionnez Activer les sauvegardes continues pour les ressources prises en charge.

Une fois que vous avez désactivé la PITR (restauration à un instant dans le passé) pour les sauvegardes de base de données SAP HANA, les journaux continueront d'être envoyés à AWS Backup jusqu'à ce que le point de récupération expire (statut égal à EXPIRED)). Vous pouvez passer à un autre emplacement de sauvegarde des journaux dans SAP HANA pour arrêter la transmission des journaux à AWS Backup.

Un point de restauration continue dont l'état STOPPED indique qu'un point de restauration continu a été interrompu ; en d'autres termes, les journaux transmis par SAP HANA à celui-ci indiquent AWS Backup que les modifications incrémentielles apportées à une base de données présentent une lacune. Les points de récupération qui se produisent pendant cet intervalle de temps ont un statut STOPPED..

Pour les problèmes que vous pouvez rencontrer lors des tâches de sauvegardes continues (points de récupération), consultez la section Dépannage de la restauration SAP HANA dans ce guide.