Sauvegarde et reprise après sinistre

Quand la redondance à l'intérieur d'une région ne suffisait plus

Les 2 dernières leçons couvraient la redondance à l'intérieur d'une seule région AWS : répartir les instances et les bases de données sur plusieurs zones de disponibilité pour que la panne d'1 centre de données n'emporte pas tout le système. Cela protège contre une panne matérielle ou une coupure de courant. Cela ne fait rien si un déploiement défectueux corrompt une table de base de données, ou si une région géographique entière s'éteint, exactement l'écart signalé plus tôt dans ce cours par la leçon sur les régions et les zones de disponibilité. Cette leçon porte sur le plan pour exactement ce cas : quand la panne dépasse ce que la redondance au niveau des zones a jamais été conçue pour absorber.

2 questions avant tout plan de récupération : combien de données, combien de temps d'arrêt

Tout plan de reprise après sinistre commence par répondre à 2 questions distinctes, et les confondre est l'erreur la plus courante des équipes.

Le Recovery Point Objective (RPO) borne la perte de données acceptable. Il répond à « combien de données pouvons-nous nous permettre de perdre », mesuré comme le délai maximal acceptable entre maintenant et le dernier point à partir duquel une récupération était possible. Un RPO de 15 minutes signifie que vos sauvegardes ou votre réplication doivent tourner au moins aussi souvent, sous peine de perdre plus que ce que l'activité peut tolérer.

Le Recovery Time Objective (RTO) borne le temps d'arrêt acceptable. Il répond à « combien de temps pouvons-nous rester hors ligne », mesuré comme le délai maximal acceptable entre le début d'une panne et le retour du service. Un RTO d'1 heure signifie que tout le processus de récupération, détecter la panne, remonter l'infrastructure, restaurer les données, doit se terminer dans cette heure.

Une base de données de commandes e-commerce avec un RPO de 15 minutes et un RTO d'1 heure promet 2 choses bien différentes : au maximum 15 minutes de commandes perdues, et au maximum 1 heure avant que la boutique ne reprenne les commandes. Tenir ces 2 promesses demande une ingénierie délibérée, et les resserrer coûte toujours plus cher.

Les sauvegardes : le socle sous chaque stratégie

Aucune stratégie de reprise après sinistre ne fonctionne sans des sauvegardes fiables en dessous. AWS Backup centralise ce travail sur plusieurs services, EC2, RDS, DynamoDB, EFS, et d'autres, via des plans de sauvegarde : des politiques qui définissent des planifications et des règles de rétention. Un plan typique associerait une règle quotidienne, sauvegardant chaque nuit et conservant chaque sauvegarde pendant 1 mois, à une règle mensuelle, sauvegardant 1 fois par mois et conservant cette copie pendant 1 année complète. Les ressources s'associent à un plan simplement en les étiquetant, et les sauvegardes peuvent se copier automatiquement vers une autre région AWS selon la même planification, ce qui transforme une sauvegarde de routine en matière première qu'une stratégie de reprise après sinistre peut réellement exploiter.

Les 4 stratégies de reprise après sinistre, de la moins chère à la plus chère

Les sauvegardes servant de socle, la question devient combien d'infrastructure vous faites tourner dans un emplacement secondaire, et être prêt coûte de l'argent, sinistre ou non.

La sauvegarde et restauration reconstruit tout, données et infrastructure, depuis zéro après qu'un sinistre est déclaré, en général via l'Infrastructure as Code, ce qui explique pourquoi elle prend le plus de temps mais coûte le moins au quotidien. Le pilot light garde la couche de données répliquée en continu mais laisse le reste de la pile éteint, devant être allumé et mis à l'échelle avant de pouvoir servir du trafic. Le warm standby va plus loin, en gardant une version plus petite de toute l'application déjà en marche, si bien que la récupération consiste à mettre à l'échelle un déploiement existant plutôt qu'à en déployer un pour la première fois. Le multi-site actif-actif supprime entièrement l'étape d'allumage : plus d'1 région gère déjà le trafic de production, donc une panne au niveau d'une région signifie simplement rediriger les requêtes loin de celle qui ne peut plus les servir.

Exemple chiffré : faire correspondre la stratégie à l'exigence

Un tableau de bord de reporting interne peut tolérer plusieurs heures de temps d'arrêt et la perte d'une journée de données sans nuire à l'activité de façon mesurable ; la sauvegarde et restauration n'est pas juste acceptable ici, c'est le bon choix technique, puisque payer pour une stratégie plus chaude reviendrait à dépenser de l'argent que l'exigence n'a jamais réclamé. Un service d'autorisation de paiement est le cas inverse : 1 minute de temps d'arrêt ou la moindre transaction perdue est inacceptable, ce qui justifie le coût et la complexité du multi-site actif-actif. Aucune des 2 équipes n'a tort. Chacune a fait correspondre sa stratégie au RTO et au RPO réellement nécessaires à l'activité, ce qui est tout l'intérêt d'avoir 4 stratégies plutôt que de se rabattre sur la plus chère par défaut.

Frontière : sauvegarde-restauration contre pilot light

Ces 2 stratégies sont les plus souvent confondues, parce que toutes 2 gardent vos données en sécurité dans une seconde région et ressemblent toutes 2, de l'extérieur, à « nous avons des sauvegardes ailleurs ». La différence porte sur le calcul. La sauvegarde et restauration n'a aucune infrastructure prête à l'avance ; tout est provisionné à partir de l'Infrastructure as Code seulement après qu'un sinistre est déclaré. Le pilot light garde un noyau minimal, souvent seulement la couche de données, vivant et se répliquant en continu, pendant que le reste de la pile (les serveurs applicatifs, par exemple) reste entièrement éteint jusqu'à ce que la bascule le déclenche. Cette seule différence, si quelque chose en dehors des données attend déjà, sépare la stratégie la moins chère de la suivante.

L'actif-actif réapparaît, à un rayon plus grand

Le multi-site actif-actif n'est pas une idée nouvelle introduite spécifiquement pour la reprise après sinistre. C'est le schéma de redondance actif-actif de la leçon précédente, où chaque réplique sert le trafic simultanément, étiré de l'échelle des zones de disponibilité à l'intérieur d'1 région à l'échelle de régions entières. Le mécanisme reste le même ; seuls la géographie et les enjeux grandissent.

Idée reçue : des sauvegardes seules ne sont pas un plan de reprise après sinistre

Il est tentant de traiter « nous avons des sauvegardes nocturnes automatisées dans une seconde région » comme équivalent à « nous avons un plan de reprise après sinistre ». Ce n'est pas le cas. Une sauvegarde dont on n'a jamais restauré est une hypothèse sur la façon dont la récupération se déroulerait, pas une preuve qu'elle se déroulera bien. Un vrai plan possède une procédure de restauration documentée et répétée, ainsi qu'un RTO connu que la direction a réellement validé comme acceptable. Les sauvegardes sont nécessaires à chacune des 4 stratégies ci-dessus ; elles ne suffisent à aucune d'entre elles à elles seules.

Repères d'examen : faire correspondre un scénario à une stratégie

Où cela vous mène

Choisir une stratégie de reprise après sinistre, c'est choisir un point sur un curseur entre le coût de fonctionnement et la vitesse de récupération, pas chercher une unique bonne réponse ; le bon point est là où atterrissent le RTO et le RPO réels de l'activité, pas plus cher que nécessaire. Les sauvegardes rendent chaque stratégie possible, mais seule une procédure de restauration testée les transforme en un vrai plan. La prochaine leçon clôt ce sujet en posant une question différente : comment savoir qu'une panne s'est réellement produite, et que promet vraiment le SLA d'un fournisseur cloud quand il n'est pas tenu ?