Le port de repli qu'on n'a jamais visité

Un terminal sérieux possède un plan de crise. Un classeur, une convention avec un port voisin capable d'accueillir les navires détournés, une liste d'appel, et l'ordre exact dans lequel on redémarre les portiques quand le courant revient.

Le classeur date de six ans. Deux numéros sur trois ne répondent plus. Le quai de repli a été reloué entre-temps à un céréalier. Et personne n'a jamais fait entrer un porte-conteneurs là-bas pour vérifier que le tirant d'eau passait.

Le jour de la crise, l'exploitant découvre trois choses en même temps : la convention est caduque, la procédure suppose des équipements démontés depuis, et le seul homme qui savait la dérouler a changé d'employeur.

Côté Azure, la scène se rejoue avec deux services qu'on active dans le portail en quelques clics et qu'on ne rouvre jamais. Azure Backup produit des points de restauration que personne n'a restaurés. Azure Site Recovery réplique des machines vers une région où personne n'a jamais basculé.

Les deux coûtent tous les mois. Leur valeur réelle est inconnue jusqu'au jour où elle devient la seule qui compte.

Azure Backup répare une donnée. Azure Site Recovery déplace un service. Les empiler sans les distinguer produit une facture double et une reprise incertaine.

Sauvegarder, répliquer, archiver

Le port se prémunit de trois façons différentes, et il ne les confond pas. Le double des manifestes, rangé dans un autre bâtiment, permet de reconstituer une cargaison mal enregistrée. Le terminal jumeau, sous pression permanente, permet de dérouter un navire. Les archives sous douane, elles, ne servent jamais à l'exploitation : elles servent au contrôleur qui viendra dans sept ans.

Trois besoins, trois mécanismes, trois factures. La confusion la plus fréquente consiste à croire qu'un mécanisme couvre le besoin d'un autre.

La sauvegarde conserve des copies datées, indépendantes de la source, dans le but d'y revenir. Elle répond à la suppression accidentelle, à la corruption logique, au chiffrement par rançongiciel, à la mise à jour applicative qui a mangé une table.

La réplication entretient une copie vivante d'un système entier dans un autre endroit, dans le but de le faire tourner ailleurs. Elle répond à la perte d'un site ou d'une région.

L'archivage conserve loin et longtemps, pour une obligation de conservation, pas pour une reprise.

Deux nombres suffisent à les départager, et ce sont les mêmes qu'en haute disponibilité : le RPO dit combien de données on accepte de perdre, le RTO dit combien de temps on accepte d'être arrêté.

Mécanisme Ce qu'il répare RPO RTO Ce qu'il ne fait pas
Sauvegarde donnée supprimée, corrompue ou chiffrée l'intervalle entre deux points, de l'heure à la journée le temps de restaurer le volume, en minutes ou en heures remettre un service complet debout tout seul
Réplication perte d'une région ou d'un site de quelques secondes à quelques minutes le temps de démarrer et d'aiguiller le trafic protéger d'une corruption logique, qu'elle recopie fidèlement
Archivage rien, au sens de l'exploitation sans objet des heures, réhydratation comprise servir de plan de reprise

La cellule qui compte est la dernière colonne de la ligne « Réplication ». Une réplication continue recopie l'erreur aussi vite qu'elle recopie le reste. Une table effacée par erreur à 14h02 est effacée dans la région de repli à 14h02 et quelques secondes.

flowchart TD I["Incident"] --> Q1{"La donnée est-elle
intacte ?"} Q1 -->|Non| B["Azure Backup
restaurer un point antérieur"] Q1 -->|Oui| Q2{"La région qui l'héberge
répond-elle ?"} Q2 -->|Non| R["Site Recovery
basculer vers la région de repli"] Q2 -->|Oui| H["Ni l'un ni l'autre
incident applicatif à traiter"] B --> L["Rétention longue
conformité et audit"] R --> F["Réprotection
puis retour vers la source"] classDef question fill:#f5f2ec,stroke:#8a4d16,color:#1a1a1a; classDef service fill:#b5651d,stroke:#8a4d16,color:#f5f2ec; classDef suite fill:#d89253,stroke:#8a4d16,color:#2c3338; classDef alerte fill:#a0413e,stroke:#8a4d16,color:#f5f2ec; class Q1,Q2 question; class B,R service; class L,F suite; class I,H alerte;
La question à poser devant un incident n'est pas « quel service de continuité avons-nous ». C'est « la donnée est-elle encore juste ». La réponse décide seule du mécanisme à déclencher.

Azure Backup : deux coffres, une stratégie

Le double des manifestes ne dort pas n'importe où. Il dort dans un local dont la clé n'appartient pas au chef de quai, et son rangement dépend du type de document.

Azure Backup s'organise autour de deux types de coffres, et le premier réflexe utile est de savoir lequel héberge quoi. Le coffre Recovery Services est le plus ancien des deux : machines virtuelles Azure, charges applicatives installées dans ces machines, partages de fichiers Azure, et serveurs restés sur site via un agent. Le coffre de sauvegarde est plus récent et couvre des ressources gérées en tant que données : objets blob, disques managés, bases PostgreSQL en serveur flexible, clusters Kubernetes managés.

Charge à protéger Coffre Mécanisme Granularité de restauration
Machine virtuelle Azure Recovery Services extension de sauvegarde et instantané des disques machine entière, disques, fichiers individuels
SQL Server dans une machine virtuelle Recovery Services agent de charge, complet, différentiel et journaux base, avec un point dans le temps rapproché
SAP HANA dans une machine virtuelle Recovery Services agent de charge base et point dans le temps
Partage de fichiers Azure Recovery Services ou coffre de sauvegarde instantanés, ou copie conservée dans le coffre partage, dossier, fichier
Objets blob Coffre de sauvegarde sauvegarde opérationnelle dans le compte, ou copie en coffre conteneur et point dans le temps
Disques managés Coffre de sauvegarde instantanés incrémentiels disque complet
PostgreSQL serveur flexible Coffre de sauvegarde rétention longue durée base
Cluster Kubernetes managé Coffre de sauvegarde extension de sauvegarde espace de noms et volumes persistants
Serveur sur site Recovery Services agent de sauvegarde pour fichiers et état système, serveur de sauvegarde pour les applications fichier, dossier, application

Deux points méritent d'être connus avant le premier déclenchement. Pour une machine Windows, la cohérence applicative s'appuie sur le service d'instantanés du système. Sur Linux, elle demande des scripts exécutés avant et après l'instantané, faute de quoi on obtient une copie cohérente au niveau du système de fichiers, ce qui n'est pas la même promesse pour une base de données.

Ensuite, la sauvegarde de SQL Server dans une machine virtuelle sait enchaîner des sauvegardes de journaux à cadence rapprochée, jusqu'à toutes les 15 minutes. C'est ce réglage, et lui seul, qui fixe le RPO réel de la base. Pas la fréquence de la sauvegarde complète, que tout le monde regarde en premier.

La stratégie de sauvegarde est le vrai objet de conception. Elle définit la fréquence, la rétention courte, la rétention longue et le comportement des instantanés de restauration rapide.

Décision de stratégie Ce qu'elle fixe réellement Erreur classique
Fréquence des points le RPO du service une sauvegarde quotidienne sur une charge qui ne tolère pas la perte d'une journée
Rétention quotidienne la fenêtre de rattrapage courante trop courte pour couvrir une corruption découverte tardivement
Rétention hebdomadaire, mensuelle, annuelle la conformité et l'audit conserver tout à la cadence la plus fine, la facture suit
Instantanés de restauration rapide la vitesse de restauration récente les prendre pour de la rétention
Redondance du stockage du coffre contre quelle panne le coffre lui-même protège découvrir après le premier travail de sauvegarde que ce réglage ne se change plus

Ce dernier point est un piège coûteux. La redondance du stockage d'un coffre se choisit avant la première sauvegarde. Ensuite, elle est figée, et un coffre local restera local. La logique est la même que pour les comptes de stockage, avec, en plus, une décision qui ne se reprend pas.

az backup vault create \
  --resource-group rg-continuite \
  --name rsv-prod-weu \
  --location westeurope

az backup vault backup-properties set \
  --resource-group rg-continuite \
  --name rsv-prod-weu \
  --backup-storage-redundancy GeoRedundant \
  --cross-region-restore-flag true

az backup protection enable-for-vm \
  --resource-group rg-continuite \
  --vault-name rsv-prod-weu \
  --vm vm-app-01 \
  --policy-name DefaultPolicy

az backup job list \
  --resource-group rg-continuite \
  --vault-name rsv-prod-weu \
  --output table

La dernière commande est celle qu'on oublie d'automatiser. Un travail de sauvegarde en échec depuis onze jours ne fait aucun bruit tant que personne ne regarde la liste des travaux ou ne branche une alerte dessus.

La stratégie de sauvegarde n'est pas un réglage d'exploitation. Sa fréquence fixe le RPO et sa rétention fixe la fenêtre de rattrapage : ce sont deux décisions métier, à faire signer par ceux qui subiront la perte.

Rendre la sauvegarde insubmersible

Au port, personne ne range le double des manifestes dans le même hangar que les originaux, et le chef de quai n'a pas la clé du local d'archives. Le rangement séparé a une seule raison d'être : obtenir une copie qui survive à un incident touchant l'exploitation courante.

C'est exactement la question que pose le scénario B, en fin de billet. Une sauvegarde que les identifiants d'administration de production permettent de supprimer ne protège pas de l'usage malveillant de ces identifiants. Elle protège d'une maladresse, pas d'une intrusion.

Azure empile plusieurs contrôles, et ils ne se remplacent pas.

La suppression réversible conserve les données de sauvegarde supprimées pendant une fenêtre configurable, période durant laquelle l'opération peut être annulée. C'est le premier filet, actif par défaut, et il ne coûte rien à activer.

Le coffre immuable interdit les opérations dont la conséquence serait une perte de points de restauration : réduire une rétention, arrêter une protection en supprimant les données. Le réglage s'active, puis se verrouille. Une fois verrouillé, il n'est plus réversible, y compris pour celui qui l'a posé, ce qui est précisément l'intérêt.

L'autorisation multi-utilisateur ajoute une ressource de garde, la Resource Guard, qu'on place idéalement dans un autre abonnement ou un autre locataire, sous la responsabilité d'une autre équipe. Les opérations critiques du coffre exigent alors une autorisation sur cette ressource, obtenue à la demande et pour une durée limitée.

La restauration inter-région permet de restaurer depuis la région secondaire d'un coffre géo-redondant, sans attendre que la région d'origine soit revenue. Elle se demande explicitement, et elle se teste avant d'en avoir besoin.

Contrôle Ce qu'il empêche Ce qu'il n'empêche pas
Suppression réversible la perte immédiate après une suppression qu'on laisse expirer la fenêtre sans s'en apercevoir
Coffre immuable verrouillé la réduction de rétention et l'effacement des points la fin naturelle d'une rétention mal dimensionnée
Autorisation multi-utilisateur l'action destructrice d'un seul compte compromis une collusion, ou une garde placée dans le même périmètre
Séparation des rôles et des abonnements qu'un administrateur d'application touche au coffre l'attribution du rôle Propriétaire par facilité
Restauration inter-région l'attente du retour de la région primaire l'absence de test, qui la rend théorique
Verrou de ressource la suppression de la ressource coffre elle-même la suppression des éléments protégés à l'intérieur

Une remarque sur la garde : la placer dans le même abonnement que le coffre revient à ranger la clé du local d'archives sur la porte du local d'archives. Le bénéfice tient entièrement à la séparation.

Une sauvegarde supprimable avec les identifiants de production n'est pas une sauvegarde, c'est une copie de confort. Le critère de conception tient en une phrase : quel compte, seul, peut détruire les points de restauration.

Azure Site Recovery : déplacer un service, pas un fichier

Le terminal jumeau ne conserve pas des copies datées. Il maintient un poste d'amarrage utilisable, des grues sous tension et des dockers formés, pour recevoir un navire dérouté dans l'heure.

Site Recovery fait la même chose avec des machines. Un agent installé dans la machine source intercepte les écritures et les transmet en continu vers un stockage de cache dans la région source, d'où elles sont appliquées vers la région cible. Le service couvre la réplication entre régions Azure, et la reprise depuis un site vers Azure. Pour un déménagement définitif, l'outillage de migration est le bon choix, et c'est le sujet du billet suivant.

Deux notions de point de récupération cohabitent, et les confondre fait promettre n'importe quoi. Les points cohérents en cas de plantage sont produits à cadence très courte, de l'ordre de quelques minutes : la machine redémarre comme après une coupure de courant. Les points cohérents applicatifs sont plus espacés, leur fréquence se règle en heures, et ils garantissent que les applications compatibles ont vidé leurs tampons avant l'instantané. Le premier donne un RPO faible, le second donne une base de données qui démarre proprement.

Trois limites, à poser franchement.

La rétention des points de récupération se compte en heures, pas en mois : Site Recovery n'est pas un magasin d'historique, et ne remplace donc pas Azure Backup.

La capacité de calcul dans la région cible n'est pas réservée par le simple fait de répliquer. Si la garantie de trouver les machines au moment du basculement est une exigence, elle s'achète séparément, via une réservation de capacité à la demande.

Enfin, la réplication ne transporte que les machines. Le réseau virtuel cible, les répartiteurs de charge, les zones DNS, le coffre de secrets, les attributions de rôles et les identités doivent exister à l'avance, sans quoi les machines démarrent dans le vide.

Le plan de récupération est l'objet qui rend le basculement exploitable. Il regroupe les machines, ordonne les groupes, et intercale entre eux des scripts, des runbooks d'automatisation ou des actions manuelles avec message d'instruction. C'est là qu'on écrit que l'annuaire démarre avant la base, la base avant l'applicatif, et l'applicatif avant la bascule du trafic.

Le test de basculement déroule ce plan dans un réseau isolé, sans interrompre la réplication en cours ni toucher à la production. C'est la fonction la plus importante du service et la moins utilisée.

sequenceDiagram participant A as Astreinte participant R as Site Recovery participant S as Région source participant C as Région cible participant T as Aiguillage du trafic S->>R: réplication continue des écritures R->>R: point cohérent en cas de plantage toutes les quelques minutes R->>R: point cohérent applicatif à cadence horaire Note over S: la région source cesse de répondre A->>R: déclenche le plan de récupération R->>C: crée les machines au point de récupération retenu C-->>R: groupes démarrés selon la séquence du plan A->>T: bascule le trafic vers la région cible T-->>A: service rendu depuis la cible A->>R: valide le basculement R->>S: réprotection en sens inverse

L'étape de validation du basculement est celle qu'on saute dans le feu de l'action. Tant qu'elle n'est pas faite, le choix du point de récupération reste ouvert, et la réplication inverse ne peut pas commencer. Le retour vers la région d'origine, lui, ne s'improvise jamais : il demande une réprotection, donc une nouvelle synchronisation, donc une fenêtre à planifier au calme.

Site Recovery ne bascule pas une application, il démarre des machines. Ce qui transforme des machines démarrées en service rendu tient dans le plan de récupération et dans l'aiguillage du trafic, deux choses qu'aucun service ne devine à ta place.

Écrire le plan, avant

Le classeur du plan de crise portuaire ne contient pas de schéma d'architecture. Il contient des noms, des ordres, des seuils de déclenchement et des messages types.

Un plan de reprise utile répond à six questions. Sa qualité se juge à une seule aune : un ingénieur d'astreinte qui n'a pas construit le système doit pouvoir l'exécuter à trois heures du matin.

Rubrique Question à laquelle elle répond Ce qui manque le plus souvent
Périmètre quelles charges sont couvertes, lesquelles ne le sont pas la liste des exclusions assumées, écrite noir sur blanc
Objectifs quel RTO et quel RPO par charge, validés par le métier des objectifs propres à chaque charge plutôt qu'un chiffre unique
Dépendances ce qui doit être debout avant de démarrer la charge l'identité, le DNS, le coffre de secrets, le registre d'images
Séquence dans quel ordre on redémarre, et qui vérifie quoi entre deux étapes le point de contrôle explicite entre deux groupes
Décision qui déclenche, sur quel critère, et qui peut refuser le seuil chiffré qui évite un débat de trente minutes
Communication qui prévient les clients, sur quel canal, à quelle fréquence un canal indépendant de l'infrastructure en panne

La ligne « dépendances » est celle qui fait échouer les basculements réussis sur le papier. Un applicatif qui démarre correctement dans la région cible mais ne trouve ni son annuaire, ni son coffre de secrets, ni son registre d'images, ne rend aucun service.

La ligne « décision » est celle qui fait perdre le plus de minutes. Basculer une région coûte cher et se paie au retour. Sans critère écrit, l'équipe attend, espère un rétablissement, et déclenche trop tard.

Le plan de reprise se rédige pour celui qui l'exécutera sans son auteur. S'il faut connaître l'architecture pour comprendre l'étape 4, l'étape 4 est mal écrite.

La restauration qu'on ne teste pas n'existe pas

Le capitaine du port ne signe pas la convention avec le terminal voisin en se disant que ça devrait passer. Il fait entrer un navire, une fois par an, à vide, pour vérifier le tirant d'eau et le rayon de giration.

Un point de restauration jamais restauré a exactement le statut d'un exercice jamais fait : une intention. Le taux de succès affiché par le service prouve que la copie a été écrite. Il ne prouve pas qu'elle se relit, que la base redémarre, ni que la durée de restauration tient dans le RTO annoncé.

Le RTO, justement, ne se déduit d'aucune documentation. Il se mesure, une fois, sur le volume réel, puis on l'écrit.

Sauvegarde quotidienne déclenchée à 23h00, rétention 30 jours.
Corruption fonctionnelle détectée le mardi à 16h00.

Dernier point utilisable  : lundi 23h00
Données perdues           : 17 heures d'activité
RPO annoncé au métier     : 24 heures  -> conforme
RTO annoncé au métier     : 4 heures   -> inconnu tant que la restauration
                                          complète n'a pas été chronométrée

La cadence ci-dessous vaut mieux qu'un exercice annuel unique, celui qui mobilise tout le monde et n'a jamais lieu.

Exercice Cadence réaliste Ce qu'il prouve
Restauration d'un fichier ou d'un dossier mensuelle que la chaîne de restauration fonctionne et que quelqu'un sait la lancer
Restauration d'une machine complète dans un groupe de ressources dédié trimestrielle la durée réelle et l'état de la machine restaurée
Test de basculement Site Recovery sur réseau isolé trimestrielle la validité du plan et l'ordre de démarrage
Restauration inter-région semestrielle que la copie secondaire est exploitable sans la région primaire
Basculement réel d'un service secondaire, retour compris annuelle le coût, la durée et le retour arrière
Exercice de crise sans la personne qui connaît le système annuelle que le plan est écrit pour quelqu'un d'autre que son auteur

Un exercice se termine par une action, pas par un compte rendu. Ce qu'on a découvert de faux dans le plan se corrige dans la semaine, sinon le prochain exercice redécouvrira la même chose.

Ce qui se mesure lors d'un test, c'est le RTO. Ce qui se découvre, c'est la dépendance oubliée. Les deux ont plus de valeur que le rapport de sauvegarde vert de la veille.

Scénario B : Code Spaces, juin 2014

Code Spaces était un hébergeur britannique de dépôts de code et d'outils de gestion de projet, dont l'infrastructure tournait chez un fournisseur de cloud public. En juin 2014, l'entreprise a publié sur son site un message décrivant le déroulé de ce qui venait de lui arriver.

Un attaquant a obtenu l'accès à la console d'administration du compte cloud de l'entreprise. L'intrusion s'est accompagnée d'une attaque par déni de service et de demandes de rançon, laissées directement dans la console.

L'entreprise a tenté de reprendre la main en changeant les identifiants. Selon son propre récit, l'attaquant avait anticipé le geste et créé au préalable des accès supplémentaires. Constatant la reprise de contrôle en cours, il a commencé à supprimer.

Ce qui a été détruit couvre l'essentiel du périmètre technique : instances de calcul, espaces de stockage, images machine, instantanés, et les sauvegardes. Tout se trouvait dans le même compte, sous la même autorité d'administration.

Le message publié conclut que l'ampleur des dégâts et le coût de reconstruction dépassaient ce que l'entreprise pouvait absorber, et qu'elle ne serait pas en mesure de poursuivre son activité au-delà de ce point. La couverture de presse technique de l'époque a repris et documenté l'affaire.

Rien ici ne relève d'une faiblesse du fournisseur. La donnée était répliquée, les instantanés existaient, les sauvegardes existaient. Elles étaient toutes des objets du même compte, supprimables par le même jeu d'identifiants, en quelques minutes, depuis la même interface.

Transposé à Azure, chaque contrôle de la section « Rendre la sauvegarde insubmersible » répond à un morceau précis de cette chaîne. La suppression réversible aurait laissé une fenêtre de récupération. Le coffre immuable verrouillé aurait refusé les suppressions de points. L'autorisation multi-utilisateur, avec une garde placée dans un autre abonnement, aurait exigé une approbation que l'attaquant n'avait pas.

Le critère de conception ne porte pas sur la fréquence des sauvegardes, il porte sur leur périmètre d'administration. Tant que le même jeu d'identifiants peut détruire la production et ses copies, il n'existe qu'un seul exemplaire du système.

Points clés

  • Sauvegarde et réplication répondent à deux incidents différents : la première répare une donnée, la seconde déplace un service, et aucune ne couvre le besoin de l'autre.
  • Le coffre Recovery Services et le coffre de sauvegarde ne protègent pas les mêmes charges ; la redondance du stockage d'un coffre se choisit avant la première sauvegarde et ne se change plus ensuite.
  • Suppression réversible, coffre immuable verrouillé et autorisation multi-utilisateur avec une garde dans un autre abonnement forment le minimum pour qu'une sauvegarde survive à la compromission d'un compte d'administration.
  • Site Recovery démarre des machines ; ce sont le plan de récupération, les dépendances pré-créées dans la région cible et l'aiguillage du trafic qui produisent un service rendu.
  • Le RTO ne se lit dans aucune documentation, il se chronomètre lors d'un test, et un test se termine par une correction du plan, pas par un compte rendu.

Dans la série

Palier 3 : Faire tourner le port. Domaine : Continuité.

Pour aller plus loin