2 Les données de sauvegarde de votre organisation ne valent que par votre capacité à les restaurer depuis un autre site lorsque votre data center principal devient indisponible. Un incendie, une inondation, un ransomware ou une panne régionale peut rendre inaccessible l’infrastructure de sauvegarde sur site. La réplication multisite est devenue une exigence incontournable pour la sauvegarde et la reprise après sinistre en entreprise. La mettre en œuvre efficacement exige de comprendre les choix d’architecture, les stratégies de gestion de la bande passante, les garanties de cohérence et les procédures opérationnelles qui maintiennent plusieurs copies de sauvegarde synchronisées et prêtes pour la restauration. Contrairement à la réplication applicative, qui doit garantir une cohérence parfaite, la réplication des sauvegardes répond à d’autres exigences. Vos données de sauvegarde doivent être cohérentes à terme (toutes les copies convergent vers le même état), mais pas nécessairement en temps réel. Cette souplesse autorise des approches d’architecture impossibles pour des systèmes transactionnels. Elle crée en revanche de nouveaux défis : gérer la consommation de bande passante sur les liaisons géographiques, faire face aux partitions réseau qui déconnectent les sites, garantir la cohérence des points de restauration lorsque des sites ont pris du retard et orchestrer la bascule vers des sites de sauvegarde secondaires. Modèles d’architecture : réplication en étoile ou maillée La décision fondamentale d’une architecture de sauvegarde multisite porte sur la topologie : la manière dont les sites sont reliés et répliquent les données. Deux modèles dominent : la réplication en étoile (hub-and-spoke) et la réplication en maillage complet. Dans une topologie en étoile, un site principal (le hub) reçoit toutes les données de sauvegarde. Les clients de sauvegarde envoient leurs données au site principal, qui les réplique ensuite vers un ou plusieurs sites secondaires (les branches). Le site principal fait référence, et toutes les données transitent par lui. La simplicité opérationnelle est séduisante : un point de configuration unique, une bande passante entre site principal et sites secondaires facile à gérer, et aucun conflit possible (seul le site principal accepte les écritures). Mais la topologie en étoile crée une dépendance critique : si le site principal tombe, les sites secondaires disposent de données périmées. Et si le site principal est aussi le seul à accepter les écritures de sauvegarde, votre organisation ne peut plus sauvegarder de nouvelles données tant qu’il est indisponible. Comprendre les modèles d’architecture multisite (en anglais) aide à éclairer ce choix. La réplication maillée relie plusieurs sites en tant que pairs. Chaque site peut accepter des données de sauvegarde et les réplique vers tous les autres. Si le site A reçoit des données, il les réplique automatiquement vers les sites B et C ; si le site B en reçoit en même temps, il les réplique vers les sites A et C. Cette approche est plus résiliente (n’importe quel site peut devenir la cible de sauvegarde si les autres tombent), mais elle ajoute de la complexité. Plusieurs sites qui acceptent des écritures peuvent créer des conflits : que se passe-t-il si les sites A et B reçoivent tous deux des mises à jour du même jeu de sauvegarde alors qu’ils sont déconnectés ? Les partitions réseau doivent être gérées avec soin, et la consommation de bande passante se multiplie : des données peuvent être répliquées du site A vers B, puis de B vers C. Le choix dépend de vos exigences de restauration. Si votre organisation doit continuer à accepter des sauvegardes même en cas de panne du site principal, la réplication maillée est nécessaire. Si votre site principal est hautement disponible et que votre préoccupation porte surtout sur la reprise après un sinistre géographique, la topologie en étoile est plus simple. De nombreuses grandes organisations adoptent une approche hybride : un site principal qui accepte les écritures et les réplique vers les sites secondaires, avec des procédures de bascule permettant à un site secondaire de devenir temporairement la destination des écritures si le site principal tombe. Gestion de la bande passante et efficacité de la réplication La réplication multisite consomme beaucoup de bande passante, et la bande passante sur de longues distances est chère et limitée. Une grande entreprise qui sauvegarde 500 Go par jour et les réplique vers un site secondaire situé à 1 000 kilomètres consomme chaque jour 500 Go de bande passante intersite, soit 15 To par mois sur la liaison. La déduplication est le principal levier pour maîtriser la bande passante de réplication. Si votre sauvegarde principale reçoit plusieurs copies du même bloc de base de données depuis différents systèmes de production, la déduplication n’en conserve qu’une seule. La réplication n’a alors besoin d’envoyer que cette copie unique aux sites secondaires, et non plusieurs copies redondantes. Pour les organisations dont les charges sont très redondantes, la déduplication peut réduire la bande passante de réplication intersite de 80 à 90 %. La réplication différentielle (ne répliquer que les changements depuis le dernier cycle) réduit encore la bande passante. Au lieu d’envoyer chaque nuit les 500 Go de sauvegarde, elle n’envoie que les deltas, généralement 10 à 20 % du volume total. Elle exige une coordination entre les sites : le site principal doit savoir ce qui a été envoyé lors du dernier cycle, identifier ce qui a changé et n’envoyer que les modifications. La compression à la volée réduit aussi la consommation de bande passante. Compresser les données à la source avant transmission peut réduire les besoins de 40 à 60 % selon les types de données. Mais la compression consomme du CPU et ajoute de la latence. Lorsque la bande passante est la principale contrainte et que du CPU est disponible, le compromis en vaut la peine. Une planification intelligente des fenêtres de réplication permet de lisser la demande sur une bande passante limitée. Au lieu de répliquer en continu toute la journée, vous pouvez planifier la réplication vers les sites secondaires en heures creuses. Vous acceptez alors que les sites secondaires soient temporairement en retard, en échange d’une meilleure efficacité de la bande passante. Les défis de la cohérence et de la bascule La complexité la plus sous-estimée de la réplication multisite est la garantie de cohérence. Lorsqu’une partition réseau déconnecte vos sites principal et secondaire, ils continuent de fonctionner indépendamment. Le site principal peut recevoir de nouvelles sauvegardes qui n’ont pas été répliquées, tandis que le site secondaire ne dispose que des sauvegardes répliquées avant la partition. Si une bascule vers le site secondaire intervient pendant la partition, ses données de sauvegarde ne sont pas synchronisées avec celles du site principal : vous avez perdu des sauvegardes récentes. Une définition claire du RTO et du RPO (en anglais) aide à choisir la stratégie de cohérence à mettre en œuvre. Chaque stratégie de réplication offre des garanties de cohérence différentes. La réplication synchrone, où le site principal attend la confirmation de l’écriture par les sites secondaires avant de valider la sauvegarde, garantit que tous les sites disposent toujours de données cohérentes. Mais elle ajoute de la latence, et une partition réseau bloque totalement les sauvegardes (le site principal ne peut plus obtenir de confirmation). C’est souvent inacceptable pour des systèmes de sauvegarde en production. La réplication asynchrone valide immédiatement les sauvegardes sur le site principal, puis envoie les données aux sites secondaires en arrière-plan. Elle offre une prise en charge des sauvegardes à faible latence et une bonne résistance aux partitions réseau, mais elle introduit le problème de cohérence : pendant une partition, les sites principal et secondaire divergent. De nombreuses organisations adoptent une approche hybride : une réplication asynchrone pour les opérations de sauvegarde courantes, associée à des contrôles de cohérence et à une réconciliation périodiques. Lorsque la partition réseau se résorbe, les sites se réconcilient et les sites secondaires reçoivent les sauvegardes manquées pendant la coupure. Tests de bascule et procédures opérationnelles La valeur de la réplication multisite s’évapore si vous n’avez pas testé vos procédures de bascule. Lorsque votre site de sauvegarde principal devient indisponible, votre organisation peut-elle réellement restaurer depuis les sites secondaires ? Beaucoup d’organisations disposent de sites de sauvegarde secondaires qui reçoivent les données répliquées, sans jamais y avoir testé de restauration. Des exercices de bascule réguliers doivent faire partie de vos opérations de sauvegarde. Chaque trimestre, choisissez une application ou un jeu de données critique et effectuez une restauration complète depuis votre site secondaire. Chronométrez la restauration, vérifiez que toutes les données sont correctement restaurées et documentez les lacunes ou problèmes rencontrés. Ces exercices révèlent les problèmes avant un véritable sinistre. Les procédures de bascule doivent définir clairement les points de décision et les circuits d’escalade. Qui décide que le site de sauvegarde principal est réellement indisponible, et non simplement lent ? Combien de temps attendre son rétablissement avant de lancer la bascule ? Basculer trop tôt peut conduire à restaurer des données alors que le site principal n’est que temporairement indisponible, et à perdre des sauvegardes récentes lorsqu’il revient. Après une bascule, votre organisation doit préparer le rétablissement du site principal. Lorsqu’il revient en ligne, comment se resynchronise-t-il avec le site secondaire devenu principal temporaire ? Les procédures de retour sont souvent plus complexes que la bascule elle-même. Les négliger crée une situation où l’on s’est remis du sinistre sans pouvoir revenir à un fonctionnement normal tant que le système de sauvegarde n’a pas été reconfiguré manuellement. Supervision et alertes pour la réplication multisite La réplication multisite multiplie les points de défaillance possibles : les liaisons réseau peuvent saturer ou tomber, les sites secondaires peuvent manquer de capacité de stockage, les processus de réplication peuvent planter ou cesser de progresser, et les décalages d’horloge entre sites peuvent provoquer des comportements inattendus. Les indicateurs clés à surveiller sont le retard de réplication (de combien les sites secondaires sont en retard sur le site principal), le taux d’erreur de réplication (combien d’opérations échouent), la consommation de bande passante intersite, la capacité de stockage de chaque site et l’état de cohérence. Déclenchez une alerte lorsque le retard de réplication dépasse votre fenêtre de RTO : si votre site secondaire a plus de quatre heures de retard sur le site principal et que votre RTO est de quatre heures, vous êtes en danger. Déclenchez aussi une alerte lorsque la saturation du réseau approche la capacité de la liaison intersite et lorsque les sites secondaires approchent de leur capacité de stockage maximale. Vos procédures d’exploitation doivent documenter la réponse aux défaillances de réplication courantes. Si la réplication vers un site secondaire prend du retard, les opérateurs peuvent-ils lancer une resynchronisation manuelle ? Si un site secondaire est plein, peut-il basculer vers un site tertiaire le temps que le site principal libère de l’espace ? Conclusion : la réplication multisite, une exigence de résilience La réplication multisite transforme la sauvegarde, mécanisme de protection local, en stratégie de résilience géographique. Vos données de sauvegarde survivent aux catastrophes touchant le site principal, aux attaques par ransomware et aux sinistres régionaux, car elles sont répliquées en continu vers des sites géographiquement éloignés. Cette résilience exige toutefois une architecture réfléchie, une gestion de la bande passante, des procédures de cohérence et une discipline opérationnelle. Commencez par définir clairement vos exigences de restauration. Si votre site de sauvegarde principal est détruit, combien de temps votre organisation peut-elle tenir sans restauration ? Ce délai est le RTO de votre infrastructure de sauvegarde, et c’est lui qui détermine si vous avez besoin d’une réplication en étoile ou maillée. Dimensionnez ensuite la bande passante intersite en conséquence. Mettez en place la déduplication et la réplication différentielle pour maîtriser les coûts. Organisez des tests de bascule réguliers pour vous assurer que vos sites secondaires sont réellement prêts à restaurer. Bâtir une stratégie de sauvegarde d’entreprise (en anglais) solide qui intègre les exigences multisites est essentiel à la résilience. Votre prochain investissement dans l’infrastructure de sauvegarde doit faire de la réplication multisite une exigence de premier plan, et non une réflexion après coup. Pour aller plus loin DRaaS : la reprise après sinistre en tant que service (en anglais) La sauvegarde en cloud hybride expliquée (en anglais) Le plan de continuité d’activité (en anglais) Architecture de cible de sauvegarde évolutive (en anglais) Qu’est-ce que la haute disponibilité (HA) ? (en anglais) Protéger ses sauvegardes contre les ransomwares : des sauvegardes immuables et restaurables (en anglais)
