Sauvegarde et restauration

Backup and Restore est la stratégie de reprise après sinistre la plus simple et la plus économique. Vous créez régulièrement des sauvegardes de vos données et de votre infrastructure, vous les stockez dans un emplacement durable (généralement S3 dans une autre région), puis vous les restaurez lorsqu’un sinistre survient. Bien que peu coûteuse à maintenir, cette stratégie entraîne le RTO le plus long (plusieurs heures) et un RPO potentiellement important (correspondant au temps écoulé depuis la dernière sauvegarde). Elle convient aux charges de travail non critiques pour lesquelles plusieurs heures d’indisponibilité sont acceptables.

AWS Backup est un service entièrement géré qui centralise et automatise la protection des données entre les services AWS. Il prend en charge les volumes EBS, les bases de données RDS, les tables DynamoDB, les systèmes de fichiers EFS, FSx, les instances EC2, les clusters Aurora et S3. Vous définissez des plans de sauvegarde avec des programmations, des périodes de conservation et des destinations de coffres. AWS Backup applique les politiques de sauvegarde à plusieurs comptes via AWS Organizations, ce qui en fait le service de référence pour la gestion des sauvegardes d’entreprise.

Amazon RDS crée automatiquement des instantanés quotidiens et capture les journaux de transactions afin d’activer la récupération à un instant précis (PITR). Vous pouvez restaurer votre base de données à n’importe quelle seconde pendant la période de conservation des sauvegardes (1 à 35 jours). Les sauvegardes automatisées sont stockées dans S3 (géré par AWS, elles ne sont pas visibles dans votre console S3). Pour la DR entre régions, utilisez la console ou la CLI afin de copier les instantanés DB vers une autre région : la copie peut servir à lancer une nouvelle instance RDS pendant un sinistre.

S3 Cross-Region Replication (CRR) réplique automatiquement les nouveaux objets d’un compartiment source vers un compartiment de destination situé dans une autre région. Pour les sauvegardes, configurez vos travaux de sauvegarde afin qu’ils écrivent dans un compartiment S3 avec CRR activé : les sauvegardes sont automatiquement copiées vers la région de DR en quelques minutes. Activez le versioning sur les deux compartiments (obligatoire pour CRR) afin de conserver les anciennes versions des sauvegardes. Associez cette fonctionnalité à S3 Object Lock pour rendre les sauvegardes immuables et les protéger contre les rançongiciels.

Pour activer la récupération EC2 dans une région de DR, créez à l’avance des Amazon Machine Images (AMIs) à partir de vos instances EC2 de production et copiez-les dans la région de DR. Les AMI capturent le volume racine, la configuration de l’instance et, éventuellement, les volumes de données. En cas de sinistre, lancez de nouvelles instances EC2 à partir de l’AMI de la région de DR et attachez vos volumes EBS restaurés. Automatisez la création des AMI avec AWS Backup EC2 resource type ou EC2 Image Builder pour les pipelines d’images de référence.

DynamoDB propose deux mécanismes de sauvegarde. Les sauvegardes On-Demand créent immédiatement une sauvegarde complète sans impact sur les performances ; elles peuvent être conservées indéfiniment et restaurées en quelques minutes. La récupération à un instant précis (PITR), lorsqu’elle est activée, sauvegarde en continu votre table pendant les 35 derniers jours, ce qui permet de la restaurer à n’importe quelle seconde de cette période. Les deux types de sauvegarde peuvent être exportés vers S3 pour une sauvegarde interrégionale ou pour être intégrés à AWS Backup. Le PITR est fortement recommandé pour les tables de production.

Amazon EFS s’intègre à AWS Backup pour effectuer des sauvegardes quotidiennes automatisées. Les sauvegardes EFS sont incrémentielles : seules les données modifiées sont copiées après la sauvegarde initiale, ce qui optimise l’utilisation du stockage. Vous pouvez restaurer un système de fichiers entier ou certains fichiers à partir d’une sauvegarde. Pour la DR interrégionale, utilisez AWS Backup Cross-Region Copy afin de copier automatiquement les sauvegardes EFS vers un coffre de la région de DR. Notez qu’EFS est déjà réparti entre plusieurs AZ au sein d’une région ; la sauvegarde interrégionale couvre les scénarios de défaillance d’une région.

Il n’est pas nécessaire de conserver toutes les sauvegardes indéfiniment. Concevez une stratégie de conservation fondée sur vos exigences de RPO et de conformité. Schéma courant : sauvegardes quotidiennes pendant 7 jours, sauvegardes hebdomadaires pendant 4 semaines, sauvegardes mensuelles pendant 12 mois, sauvegardes annuelles pendant 7 ans (le schéma Grandfather-Father-Son). Les règles de cycle de vie AWS Backup automatisent ce processus. Pour les sauvegardes stockées dans S3, utilisez les politiques S3 Lifecycle afin de transférer les sauvegardes plus anciennes vers S3 Glacier ou Deep Archive et de réduire considérablement les coûts de stockage.

AWS Backup Vault Lock applique une politique WORM (Write Once, Read Many) qui empêche quiconque, y compris les utilisateurs root, de supprimer des sauvegardes ou de modifier le verrou avant son expiration. Cela protège les sauvegardes contre les attaques par rançongiciel et les menaces internes. Une fois appliqué, Vault Lock ne peut pas être désactivé. Cette fonctionnalité est essentielle pour respecter les réglementations exigeant des sauvegardes immuables (SOC 2, PCI DSS, HIPAA). Définissez une période de conservation minimale et maximale afin d’éviter toute suppression prématurée des sauvegardes.

Créer des sauvegardes ne représente que la moitié du travail : vous devez tester régulièrement que les restaurations fonctionnent correctement et respectent votre RTO. AWS Backup prend en charge des plans de test de restauration qui restaurent automatiquement les sauvegardes dans un environnement de test selon une programmation et vérifient que la restauration a réussi. Sans tests de restauration réguliers, vous pourriez découvrir lors d’un véritable sinistre que vos sauvegardes sont corrompues, incomplètes ou beaucoup plus longues à restaurer que prévu. Consignez la durée de restauration comme valeur réelle de votre RTO.

Les échecs de sauvegarde doivent être détectés immédiatement : l’échec d’un travail de sauvegarde signifie que votre prochain sinistre ne disposera d’aucun point de récupération récent. Configurez les notifications AWS Backup via SNS pour recevoir une alerte en cas d’échec d’un travail de sauvegarde. Utilisez des métriques CloudWatch telles que NumberOfBackupJobsFailed pour créer des alarmes. Utilisez des règles AWS Config telles que BACKUP_PLAN_MIN_FREQUENCY_AND_MIN_RETENTION_CHECK afin de vérifier en continu que les ressources disposent des plans de sauvegarde appropriés. Considérez toute sauvegarde manquée comme une violation potentielle des exigences de conformité.

Testez votre compréhension des concepts AWS Solutions Architect (SAA-C03) présentés dans cette leçon.

Dans cette leçon, vous avez appris que : AWS Backup centralise la gestion des sauvegardes pour RDS, DynamoDB, EFS, EC2 et bien d’autres services, S3 Cross-Region Replication copie automatiquement les sauvegardes vers votre région de DR, et Backup Vault Lock fournit des sauvegardes immuables pour la conformité et la protection contre les rançongiciels. Testez toujours les restaurations afin de valider votre RTO réel. Nous allons maintenant étudier les stratégies Pilot Light et Warm Standby.