Implémenter une stratégie de reprise après sinistre avec Amazon RDS

Amazon RDS (Relational Database Service) est un service géré qui facilite la mise en place, l’exploitation et la mise à l’échelle de bases de données relationnelles. Basé sur les hautes performances de calcul et de stockage d’AWS, Amazon RDS supporte les moteurs de base de données MySQL, SQL Server, PostgreSQL, MariaDB et Oracle. Il propose plusieurs solutions pour provisionner, mettre à jour, superviser et permettre la reprise après sinistre d’une base de données après un sinistre (DR pour Disaster Recovery). Cet article présente trois fonctionnalités d’Amazon RDS que vous pouvez utiliser pour redémarrer votre base de données après un sinistre : les sauvegardes automatiques, les sauvegardes manuelles et les réplicas en lecture.

A quoi sert un plan de reprise après sinistre ?

Pour un environnement de production, il est important de prendre des précautions pour pouvoir survenir à un évènement inattendu. Alors qu’Amazon RDS fournit une configuration de haute disponibilité  en déployant sur plusieurs zones de disponibilité pour assurer la redondance, elle ne protégera pas contre tous les risques tels qu’un sinistre naturel, un acte de malveillance ou une corruption de la base de données. Pour maintenir la continuité des opérations, il est important d’établir et de tester un plan de reprise après sinistre.

Comprendre le RTO et RPO

La durée maximale d’interruption admissible (RTO : Recovery Time Objective) et l’objectif de point de reprise (RPO : Recovery Point Objective) sont deux métriques clés à considérer lors de l’établissement d’un plan de reprise après sinistre. Le RTO représente le temps nécessaire pour retrouver un état fonctionnel après un sinistre. Le RPO, qui est exprimé en heures, désigne le volume de données pouvant être perdu lorsqu’un sinistre survient. Par exemple, un RPO d’1 heure signifie que l’on peut perdre jusqu’à 1 heure de données lors d’un sinistre.
Voici les différentes fonctionnalités d’Amazon RDS qui adressent les différents RTO et RPO et leur impact sur les coûts :

Comme vous le voyez, les sauvegardes automatiques sont limitées à une seule région AWS alors que les snapshots (instantanés) manuels et les réplicas en lecture peuvent s’étendre sur plusieurs régions.

Cas particulier d’Amazon Aurora

Cet article ne couvre pas explicitement Amazon Aurora, car Amazon Aurora a des fonctionnalités de reprise après sinistres légèrement différentes. Cependant, plusieurs techniques présentés sont applicables aux clusters de bases de données Amazon Aurora. Pour plus d’informations, consultez la documentation d’Amazon Aurora.

Sauvegardes Amazon RDS

Les sauvegardes sont des éléments clés du plan de reprise après sinistre de votre base de données. Amazon RDS supporte deux types différents de sauvegardes : sauvegardes automatiques et snapshots manuels.
Les sauvegardes d’Amazon RDS suivent les règles suivantes :

• Votre instance de base de données doit être dans l’état ACTIVE pour que les sauvegardes se déclenchent,
• Les sauvegardes et les snapshots automatiques ne peuvent pas être lancés lorsqu’une copie est réalisée dans la même région que l’instance de base de données,
• Le premier snapshot d’une base de données contient toutes les données de l’instance de base de données,
• Les snapshots effectués après le premier sont des snapshots incrémentaux. Cela signifie que seulement les dernières données modifiées sont capturées et sauvegardées,
• Dans le cas d’une configuration Multi-AZ, les sauvegardes sont effectuées sur l’instance de secours pour réduire l’impact sur l’instance principale.

Note: Les sauvegardes automatiques et les snapshots manuels sont stockés dans un bucket Amazon S3 qui est maintenu et géré par le service Amazon RDS. De ce fait, vous ne pourrez pas les voir dans votre console Amazon S3.

Pour plus d’informations concernant les mécanismes de sauvegarde et de leur stockage, consultez Utilisation des sauvegardes dans le guide de l’utilisateur Amazon RDS.

Sauvegardes automatiques

L’option de sauvegarde automatique est activée par défaut sur Amazon RDS. Amazon RDS créée un snapshot du volume de votre instance de base de données, sauvegardant l’instance en entier et pas uniquement les bases de données individuellement. La première sauvegarde consiste à effectuer une sauvegarde complète. Les sauvegardes suivantes sont incrémentales, les snapshots ne contiennent que les blocs qui ont été modifiées depuis la précédente sauvegarde. Chaque snapshot contient des pointeurs vers les autres blocs de données des snapshots qui seront nécessaires à sa reconstruction. Supprimer le snapshot le plus récent n’entraîne pas de perte de données aussi longtemps que la donnée est encore référencée par au moins un snapshot.

Pourquoi avoir besoin de sauvegardes automatiques ?

Il y a plusieurs avantages à avoir des sauvegardes automatiques :

• La donnée est stockée dans un bucket Amazon S3 qui est maintenu et géré par le service Amazon RDS,
• Vous évitez de vous préoccuper de faire une sauvegarde manuelle et de la transférer dans un endroit sûr,
• Vous pouvez choisir une fréquence adaptée pour vous : journalière, hebdomadaire, ou mensuelle,
• A la fois les erreurs humaines et catastrophes naturelles sont mitigés (par exemple, les virus, les défaillances applicatives ou les incidents électriques),
• Le plus important, vous évitez la perte de données.

Fenêtre de sauvegarde automatique

La fenêtre de sauvegarde automatique est une période hebdomadaire utilisée pour effectuer les sauvegardes. La fenêtre s’étale sur une plage horaire de 8h pour chacune des Régions AWS. Cependant, il fortement recommandé de positionner la fenêtre de sauvegarde durant les heures de faibles activité pour éviter la charge induite sur le serveur. Pour voir la liste des plages horaires pour chaque régions, consultez Fenêtre de sauvegarde dans le guide de l’utilisateur Amazon RDS.

Durée de rétention des sauvegardes automatiques

La durée de rétention des sauvegardes est la fenêtre de temps durant laquelle vous pouvez réaliser une restauration à partir d’un point donné dans le temps (PITR : Point-in-time recovery). Vous pouvez définir une durée de rétention différente pour les sauvegardes lorsque vous créez une instance de base de données, ainsi que la modifier à tout moment.

Pour plus d’informations détaillées, consultez Période de rétention des sauvegardes.

Il y a quelques différences entre les snapshots manuels et les sauvegardes automatiques :

• La limite du nombre de snapshots manuels (100 snapshots par Region) ne s’appliquent pas aux sauvegardes automatiques,
• La durée de rétention des sauvegardes ne s’applique pas aux snapshots manuels,
• Les snapshots manuels ne sont pas automatiquement supprimés; ils doivent être explicitement supprimés.

Configurer la sauvegarde automatique lors de la création de l’instance

1. Dans l’onglet Sauvegardes, dans la section Configuration supplémentaire, spécifiez la période de rétention et la fenêtre de sauvegarde.
2. Spécifiez une Heure de début pour la sauvegarde et une Durée en heures qui sont nécessaires pour terminer la sauvegarde de votre base de données. C’est une bonne pratique d’utiliser une fenêtre de sauvegarde en dehors des heures de forte utilisation.

Modifier les paramètres de sauvegarde automatique

Pour changer les paramètres de sauvegarde automatique, suivez ces étapes :

1. Cliquez sur l’instance de base de données sur laquelle vous voulez modifier les paramètres de sauvegarde automatique et cliquez sur le bouton Modifier.
2. Défilez vers le bas jusqu’à Sauvegarde et faites vos changements sur Période de rétention des sauvegardes et sur la Fenêtre de sauvegarde
3. En dessous de Quand appliquer les modifications, sélectionnez l’option que vous souhaitez et cliquez sur Modifier l’instance de base de données.

Restaurer à partir d‘un point donné dans le temps

La restauration à partir d’un point donné dans le temps est le fait de restaurer l’état d’une base de données telle qu’elle était à un moment précis.
Lorsque les sauvegardes automatiques sont activées sur votre instance de base de données, Amazon RDS réalise automatiquement un snapshot complet de vos données. Le snapshot est réalisé pendant la fenêtre de sauvegarde que vous désirez. Les logs de transactions sont également enregistrés vers Amazon S3 toutes les 5 minutes (au fur et à mesure des mises à jour sur votre instance de base de données). L’archivage de vos logs de transactions est une partie importante de votre plan de reprise après sinistre et de restauration à partir d’un point donné dans le temps. Lorsque vous initiez une restauration à partir d’un point donné, les logs de transactions sont appliqués à partir de la sauvegarde quotidienne la plus appropriée pour pouvoir restaurer votre instance de base de données à une date précise.
Pour plus d’informations suivez Restauration d’une instance de base de données à une date spécifiée dans le guide de l’utilisateur Amazon RDS.

Conserver les sauvegardes automatiques

Lorsque vous supprimez une instance de base de données, vous pouvez choisir de conserver ses sauvegardes automatiques. Cela est utile si vous décidez de restaurer cette instance plus tard. Ces sauvegardes contiennent les snapshots et les logs de transactions de l’instance de base de données. Elles incluent également les propriétés de votre instance (tels que le stockage alloué et la classe d’instance), qui sont nécessaires pour la restauration d’une instance fonctionnelle. Vous pouvez restaurer ou supprimer une sauvegarde automatique en utilisant la console AWS, l’API d’Amazon RDS et le CLI AWS. Consultez Conservation des sauvegardes automatiques dans le guide de l’utilisateur Amazon RDS pour plus d’informations sur les limitations et recommandations concernant la conservation des sauvegardes automatiques.

Snapshots de base de données

Les snapshots (instantanés) de base de données sont des sauvegardes manuelles (à l’initiative de l’utilisateur) de l’entièreté votre instance de base de données et font office de sauvegardes complètes. Ils sont stockés dans Amazon S3 et conservés jusqu’à ce que vous les supprimiez explicitement. Ces snapshots peuvent être copiés et partagés dans des comptes et régions AWS différentes. Comme les snapshots de base de données incluent l’entièreté de l’instance de base de données, les fichiers de données et les fichiers temporaires, la taille de l’instance conditionne le temps effectué pour créer le snapshot.
Créer un snapshot de base de données sur une instance mono zone de disponibilité engendre une brève interruption des I/O, pouvant induire des baisses de performance. L’interruption des I/O peut durer quelques secondes ou minutes en fonction de la taille d’instance et de la classe de votre instance de base de données. Les instances de base de données Multi-AZ ne sont pas concernées par cette interruption car la sauvegarde est effectuée sur l’instance de secours.
Consultez le guide de l’utilisateur Amazon RDS pour la Création d’un instantané de base de données.

Voir les snapshots (instantanés)

Vous pouvez voir les snapshots dans la console Amazon RDS. Cliquez sur Instantanés, la liste qui s’affiche par défaut contient les Instantanés manuels.

Copier et partager les snapshots

Dans Amazon RDS, vous pouvez copier automatiquement ou manuellement les snapshots de base de données. Lorsque vous créez une copie d’un snapshot, cette copie devient un snapshot manuel. Vous pouvez copier un snapshot de la base de données dans la même région AWS, dans une autre région AWS ou même dans d’autres comptes AWS. Si vous copiez un snapshot de base de données dans une autre région AWS, cela revient à créer un snapshot manuel qui est conservé dans cette région. Copier un snapshot de base de données en dehors la région initiale engendre des coûts de transfert de données d’Amazon RDS.
Vous ne pouvez pas directement copier un snapshot automatique vers un autre compte AWS. Pour partager ce type de snapshot, créez un snapshot manuel en copiant le snapshot automatique et partagez cette copie. Cette méthode s’applique également aux ressources créées par AWS Backup. Une autre méthode consister à d’abord partager le snapshot et ensuite le copier dans l’autre compte.
Pour plus d’informations concernant la copie des snapshots ainsi que les limitations, consultez Copie d’un instantané dans le guide de l’utilisateur Amazon RDS.

Partage de snapshot Amazon RDS entre des comptes AWS

Amazon RDS offre la possibilité de partager des snapshots de base de données ou des snapshots de cluster avec d’autres comptes AWS. Partager des snapshots avec d’autres comptes hautement sécurisés peut vous aider si vous souhaitez vous prémunir d’actes malveillants qui pourraient interrompre vos activités au sein de vos comptes de production. Vous pouvez partager des snapshots manuels avec jusqu’à 20 comptes AWS.

• Les snapshots automatiques d’Amazon RDS ne peuvent pas être partagés directement avec d’autres comptes AWS. Pour partager un snapshot automatique, vous devez faire une première copie du snapshot, qui sera créée en temps que snapshot manuel. Vous pourrez ensuite partager la copie avec un autre compte,
• Les snapshots manuels de base de données qui utilisent des groupes d’options personnalisés avec des options persistantes ou permanentes telles que Transparent Data Encryption (TDE) ou le fuseau horaire ne peuvent pas être partagés,
• Les snapshots qui utilisent la clé de chiffrement par défaut d’Amazon RDS (aws/rds) ne peuvent pas être partagés directement. Vous devez d’abord copier le snapshot en choisissant une clé de chiffrement personnalisée et ensuite partager la clé personnalisée et le snapshot copié.

Pour plus de détails concernant le partage des snapshots entre comptes AWS, consultez Partage d’un instantané de base de données dans le guide de l’utilisateur Amazon RDS.

Restauration depuis un snapshot de base de données

Si un sinistre survient, vous pouvez créer une nouvelle instance de base de données en utilisant un snapshot pour la restauration. Lorsque vous restaurez l’instance de base de données, vous choisissez le nom du snapshot à partir duquel vous souhaitez faire la restauration. Ensuite, vous choisissez le nom de la nouvelle instance de base de données qui va être créée. Plusieurs choses sont à prendre en considération à propos de la restauration :

• Vous ne pouvez pas restaurer un snapshot dans une instance de base de données existante. Une nouvelle instance sera créée lors du processus de restauration. Si vous souhaitez utiliser le même nom que l’instance existante, vous devrez d’abord supprimer ou renommer celle-ci,
• Bien qu’il soit possible de restaurer un snapshot sur une instance avec un type de stockage différent, le processus de restauration est plus lent. Des traitements supplémentaires sont effectués pour migrer vers un nouveau type de stockage,
• Vous ne pouvez pas restaurer une instance de base de données depuis un snapshot partagé qui est chiffré. Vous devez faire une copie de ce snapshot et ensuite effectuer la restauration depuis celui-ci,
• Une bonne pratique consiste à conserver le groupe de paramètre de tous les snapshots de base de données que vous créez. Cela permettra de pouvoir restaurer l’instance de base de données avec le bon groupe adéquat,
• Lorsque vous restaurez un snapshot de base de données, le groupe d’options qui est associé avec ce snapshot est également associé à l’instance restaurée par défaut. Vous pouvez associer un groupe d’options différent lors de la restauration. Cependant, le nouveau groupe d’option doit contenir toutes les options permanentes et persistantes qui sont dans le groupe d’option original.

Pour plus de détails, consultez Restauration à partir d’un instantané de base de données dans le guide de l’utilisateur Amazon RDS.

Restauration entre régions

Comme évoqué précédemment, lorsque vous effectuez une restauration d’un snapshot entre régions, vous devez d’abord copier le snapshot dans la région souhaitée. Ensuite, vous pouvez restaurer le snapshot dans une nouvelle instance de base de données.

Intégration avec AWS Backup

Les snapshots Amazon RDS peuvent être intégrés dans AWS Backup. AWS Backup est un service entièrement géré que vous pouvez utiliser pour centraliser et automatiser les sauvegardes de données des différents services AWS dans le cloud et on-premises. En utilisant AWS Backup, vous pouvez centraliser, configurer des politiques et surveiller le bon déroulement des sauvegardes de vos ressources AWS. Pour plus d’informations, consultez la documentation d’AWS Backup.

Réplicas en lecture

Amazon RDS pour MariaDB, MySQL, PostgreSQL et Oracle permettent de créer des replicas en lecture d’une base de données source. Lorsque vous créez un réplica en lecture, Amazon RDS commence par créer un snapshot de l’instance de base de données source et créé ensuite une instance en lecture-seule. Amazon RDS utilise la méthode de réplication asynchrone du moteur de base de données pour mettre à jour les réplicas en lecture dès lors qu’il y a des modifications effectués sur l’instance source. Un réplica en lecture fonctionne comme une instance de base de données qui n’autorise que des requêtes en lecture. Les applications peuvent se connecter à un réplica en lecture de la même manière que les autres instances de base de données. Amazon RDS réplique tous les objets de l’instance de base de données source. Par défaut, un réplica en lecture est créé avec le même type d’instance et de stockage que l’instance source. Vous pouvez cependant créer un réplica en lecture qui a un type de stockage différent. Vous pouvez créer jusqu’à cinq réplica en lecture par instance de base de données source.
En plus d’utiliser des réplicas en lecture pour réduire la charge sur la base de données source, vous pouvez aussi les utiliser pour implémenter une stratégie de reprise après sinistre pour votre environnement de production. Si l’instance source subit une interruption, vous pouvez transformer votre réplica en lecture en instance autonome. Les réplicas en lecture peuvent être créés dans une région différente de celle de la base de données source. Utiliser un réplica en lecture entre régions peut vous aider à basculer rapidement si vous rencontrez des problèmes sur la disponibilité sur une région.
Une métrique importante à surveiller avec un réplica en lecture est le retard de réplication qui est la durée de décalage entre le réplica et la base de données source. Un retard de réplication peut impacter votre reprise. Le retard de réplica peut varier avec latence réseau entre les régions source et destination. Il peut aussi être affecté par la quantité de données qui est répliqué. Comme les réplicas en lecture sont démarrés sur une instance de base de données, le temps nécessaire pour reprendre après un sinistre est bas. Cependant, utiliser des réplicas en lecture de cette manière est généralement une option plus chère que d’utiliser les sauvegardes automatiques ou des snapshots de base de données.
Pour plus d’informations concernant la création d’un réplica en lecture ou les réplicas en lecture entre régions, consultez Utilisation des réplicas en lecture dans le guide de l’utilisateur Amazon RDS.

Transformer un réplica en lecture en instance autonome

Contrairement à une configuration Amazon RDS en Multi-AZ, basculer en utilisant un réplica en lecture n’est pas automatique. Si vous utilisez des réplicas en lecture entre régions, vous devez être certain que vous pouvez changer vos autres ressources AWS entre ces régions. Le trafic entre régions peut engendrer des latences et la reconfiguration des applications peut être compliquée.
Pour en savoir plus, consultez Promotion d’un réplica en lecture en instance de bases de données autonome dans le guide de l’utilisateur Amazon RDS.
Après avoir transformé votre réplica en lecture d’une autre région en instance autonome, si vous voulez revenir à la région d’origine, vous devez créer un nouveau réplica en lecture. Contrairement à une configuration Amazon RDS en Multi-AZ, ce n’est pas fait pour vous automatiquement.

Tester votre plan de reprise après sinistre

Un plan de reprise après sinistre est utile si il est testé et validé régulièrement. Tester votre plan de reprise vous aide à identifier les problèmes potentiels ou les oublis afin de mettre en place les actions nécessaire. Un plan complet n’inclus pas seulement les bases de données, mais toute l’infrastructure autour des applications. Malgré le fait qu’un plan complet consomme beaucoup de temps et de ressources, il vous aide à être confiant lorsqu’il sera nécessaire de l’activer.

Résumé

Dans cet article, nous avons partagé quelques bonnes pratiques pour implémenter une stratégie de reprise après sinistre en utilisant Amazon RDS. Cet article fournit les bases pour que vous puissiez implémenter une reprise après sinistre avec des réplicas en lecture, des sauvegardes manuelles et automatiques en utilisant Amazon RDS. Nous avons également souligné quelques concepts clés comme l’objectif de point de reprise, le partage de snapshots Amazon RDS entre différents comptes et la création de réplica en lecture entre régions.
Si vous avez des questions ou des commentaires à propos de cet article de blog, vous pouvez utiliser la section commentaires pour publier vos idées.

Article original rédigé en anglais par Anuraag Deekonda, consultant associé AWS Professional Services et adapté en français par Guillaume Delacour, Solutions Architect dans l’équipe AWS France.