ROBO Backup : protection des bureaux distants et des succursales

Pourquoi la protection de 500 succursales est un problème différent de celui de la protection d'une seule, et comment l'architecture de « sauvegarde à partir d'une réplique » permet en réalité de le résoudre.
Senior Product Marketing Manager
Image
Protecting one branch is easy. Protecting 500 is different. Discover how backup-from-replica enables centralized management, WAN-efficient protection, and reliable recovery for large ROBO environments.

Le véritable problème des sauvegardes ROBO

Protéger une seule succursale est un jeu d'enfant. Protéger 500 succursales, voilà le véritable problème. La plupart des conseils en matière de sauvegarde ROBO traitent le premier problème et ignorent le second. Les architectures qui fonctionnent pour une seule succursale tombent en panne dès qu’on en compte 50, et celles qui fonctionnent pour 50 vous obligent à tout reconstruire à partir de zéro dès que vous en avez 500.

J’ai vu des clients déployer des appliances de sauvegarde dans chaque magasin d’une chaîne comptant des centaines de points de vente. Au bout de deux ans, ils comptent 400 boîtiers de sauvegarde sur le terrain, sans version de micrologiciel homogène, sans personnel informatique sur place, et avec un budget de déplacement trimestriel pour la seule personne qui sait comment les réparer. Techniquement, les sauvegardes s’exécutent. Elles n’ont toutefois jamais été testées dans la plupart des sites. Personne n’est certain qu’une véritable restauration fonctionnerait. 

Cet article traite d’une approche évolutive, car elle ne nécessite pratiquement rien au niveau de la succursale. La succursale continue de faire ce que font les succursales. La sauvegarde s’effectue de manière centralisée.

Pourquoi les sites ROBO posent-ils plus de difficultés que le siège social ?

Le siège social dispose d’un centre de données, d’une connexion haut débit et d’une équipe informatique. Les sites ROBO ne disposent d’aucun de ces éléments, mais sont soumis aux mêmes exigences en matière de continuité d’activité. Quatre défis spécifiques reviennent systématiquement.

La bande passante du réseau étendu (WAN) est le premier. Une sauvegarde complète via une liaison de succursale classique peut dépasser la fenêtre de sauvegarde et saturer la connexion pendant les heures de travail. Une bande passante suffisante pour les opérations quotidiennes l’est rarement pour les sauvegardes complètes nocturnes.

L’absence de personnel informatique sur place constitue le deuxième défi. Un magasin de détail ne dispose pas d’administrateur de sauvegarde. Tout ce qui fonctionne en succursale doit fonctionner de manière autonome, se rétablir de manière autonome et ne jamais nécessiter l’intervention d’un technicien sur place.

L’échelle est le troisième défi. Une succursale, c’est facile. 500 succursales, avec une politique et des rapports identiques, voilà le véritable problème.

Et les SLA constituent le quatrième défi. Les clients et les autorités de régulation se moquent bien que votre point de vente dispose d’une liaison de 10 Mbps. Si les données des points de vente sont perdues ou si les systèmes sont hors service, l’activité est paralysée. La sauvegarde ROBO doit garantir une reprise de niveau siège social sans infrastructure de niveau siège social.

Ce que coûtent réellement les temps d’arrêt dans les succursales

Le coût des temps d’arrêt varie, mais le seuil minimal est élevé. Une étude de Statista montre que 24 % des organisations déclarent des coûts d’indisponibilité horaires compris entre 301 000 et 400 000 dollars pour les serveurs critiques, et 14 % font état de coûts supérieurs à 5 millions de dollars par heure. Pour le commerce de détail ou les services financiers disposant de systèmes de point de vente ou de transaction décentralisés, chaque heure d’indisponibilité d’une agence multiplie l’impact.

Le coût s’alourdit au niveau des agences car les pannes sont généralement indépendantes les unes des autres. Une simple panne dans une agence ne déclenche pas la mobilisation de la cellule de crise de l’entreprise. Elle entraîne une perte silencieuse de chiffre d’affaires jusqu’à ce que quelqu’un s’en aperçoive. Lorsque le service informatique central intervient, le compte à rebours de la reprise est souvent déjà en cours depuis des heures.

Les régimes de conformité relèvent encore davantage le seuil minimal. Le RGPD exige une gestion rigoureuse des données clients, y compris leur suppression en temps opportun. La loi HIPAA exige des preuves de conformité rétrospectives pour les données de santé. Les données générées par les agences relèvent du champ d’application de ces deux réglementations, qu’elles aient été correctement sauvegardées ou non.

Ce dont la protection moderne des données des agences ROBO a réellement besoin

Cinq exigences, et toute architecture qui en néglige une vous causera du tort dans un délai d’un an.

Fonctionnement optimisé pour le WAN. La sauvegarde ne doit pas saturer la connexion de la succursale pendant les heures de travail. Les sauvegardes complètes sur le WAN ne sont pas acceptables.

Aucune infrastructure locale. Pas de serveur de sauvegarde dédié, d’appareil dédié ni de stockage propriétaire au niveau de la succursale. Moins il y a d’éléments mobiles sur le site, plus le système est fiable.

Gestion centralisée. Une vue d’ensemble unique sur toutes les succursales. Une politique appliquée une seule fois, respectée partout. Des rapports transmis au siège.

Récupération aux deux niveaux. Le personnel de la succursale peut récupérer des fichiers supprimés sans contacter le service informatique central. Le service informatique central peut restaurer l’intégralité d’une succursale depuis le siège si nécessaire.

Granularité et prise en compte des locataires. Récupération au niveau de la machine virtuelle, de l’application ou du fichier. Accès au niveau administrateur et au niveau du locataire, afin que chaque succursale gère ses propres données sans avoir accès à celles des autres.

Comment fonctionne concrètement la « sauvegarde à partir d’une réplique »

Le changement d’architecture qui rend la sauvegarde ROBO moderne pratique est d’une simplicité trompeuse. Au lieu d’effectuer une sauvegarde dans chaque succursale, répliquez les données de la succursale vers le centre de données dans le cadre des opérations normales de reprise après sinistre, puis effectuez la sauvegarde proprement dite au centre de données à partir de la réplique.

Ce qui change : le processus de sauvegarde ne consomme ni ressources de calcul, ni stockage, ni bande passante au niveau de la succursale. La succursale transmet les données modifiées une seule fois, à des fins de réplication. La sauvegarde s’effectue au siège sur les données qui s’y trouvent déjà.

Le processus est simple. La succursale réplique ses données vers le centre de données en continu ou selon une politique définie, à l’aide de la réplication native. HYCU, au centre de données, effectue la sauvegarde à partir de la copie répliquée, et non à partir de la succursale. Des copies de sauvegarde secondaires facultatives sont enregistrées sur un stockage non Nutanix au centre de données afin de respecter la règle 3-2-1. La restauration s’effectue à l’une ou l’autre des extrémités.

Pour les environnements ROBO basés sur Nutanix en particulier, cela s’associe à des clusters à 1 ou 2 nœuds qui sont provisionnés au siège en moins d’une heure et expédiés vers la succursale, prêts à fonctionner. Même plan de gestion Prism. Mêmes politiques HYCU. Il n’existe pas de produit ROBO distinct. Nous prenons également en charge les sites ROBO ESXi, et la restauration permet de déplacer des charges de travail entre AHV et ESXi, ou vers des clusters Nutanix sur AWS ou GCP.

Pourquoi la réplication seule ne constitue pas une reprise après sinistre

Les équipes confondent constamment ces deux concepts. « Nous répliquons depuis chaque succursale vers le centre de données, nous sommes donc couverts. » C’est une grave erreur.

La réplication est une copie de l’état actuel. Si la source est corrompue par un rançongiciel, un bug d’application ou une commande erronée d’un administrateur, la corruption est également répliquée. Le centre de données dispose désormais d’une copie parfaite des données corrompues, l’original ayant disparu. La restauration n’a plus aucun point de référence.

Une véritable protection des données ROBO respecte la règle 3-2-1 : au moins trois copies des données, sur deux types de supports différents, dont au moins une copie hors site. La réplication constitue l’une de ces copies, mais ne représente pas la stratégie dans son ensemble. La sauvegarde apporte des copies récupérables à un instant donné, ce que la réplication ne fournit pas. La réplication permet un basculement rapide. La sauvegarde permet une restauration propre.

Pour les environnements ROBO, cela revêt une importance plus grande qu’au siège social, car les succursales disposent souvent d’une seule cible de réplication et d’aucune autre couche de protection. Une attaque par ransomware sur une succursale peut corrompre la réplique avant même que quiconque au siège ne s’en aperçoive. Une sauvegarde à partir de la réplique avec conservation des données résout ce problème. La succursale peut être restaurée à un instant précis, même après la compromission de la réplique active.

À quoi ressemble concrètement la restauration ROBO ?

Trois scénarios couvrent l’essentiel des besoins opérationnels ROBO. Un seul fichier ou dossier, lorsqu’un collaborateur supprime le mauvais document. Le personnel de la succursale effectue lui-même une restauration au niveau du fichier à partir de la sauvegarde la plus récente. Une seule machine virtuelle (VM) ou application, lorsqu’une VM de point de vente tombe en panne ou qu’une application est corrompue. Une restauration en un clic rétablit la VM au niveau de la succursale, ou temporairement au siège social pendant le remplacement du matériel de la succursale. Panne de l’ensemble de la succursale, due à un incendie, une inondation, un ransomware ou une défaillance matérielle. La succursale entière est restaurée soit sur un site de remplacement, soit sur Nutanix Clusters sur AWS ou GCP pour un fonctionnement temporaire.

Dans les trois cas, la restauration est contrôlée par l’administrateur ou le locataire. Le personnel de la succursale restaure ce qui relève de sa compétence. Il n’a pas de visibilité sur les autres succursales. Cela revêt une importance particulière dans les environnements de vente au détail et de franchise où plusieurs opérateurs partagent une infrastructure commune.

Questions fréquentes sur la protection des données ROBO

Ai-je besoin d’une infrastructure de sauvegarde dans chaque succursale ?

Non, et c’est justement là l’intérêt. Avec la sauvegarde à partir d’une réplique, la succursale réplique ses données vers le centre de données et le processus de sauvegarde proprement dit s’exécute de manière centralisée. Pas de serveurs de sauvegarde dans la succursale, pas d’appareils dédiés, pas de stockage propriétaire. La succursale envoie les données modifiées une seule fois pour la réplication, et le siège social se charge du reste.

La réplication est-elle suffisante pour la reprise après sinistre ROBO ? 

Non. La réplication copie l’état actuel, ce qui est utile pour le basculement, mais inutile si la source est corrompue, car la corruption est également répliquée. Les environnements ROBO nécessitent à la fois une réplication pour un basculement rapide et une sauvegarde avec conservation des données pour une restauration propre à un instant donné. La règle 3-2-1 s’applique autant aux succursales qu’au siège social. 

Comment cela gère-t-il la perte totale d’un site ?

Si une succursale est irrécupérable sur site, à la suite d’un incendie, d’une inondation ou d’une panne matérielle prolongée, les charges de travail sont restaurées sur Nutanix Clusters sur AWS ou GCP. Mêmes politiques, même modèle de reprise. Les opérations se poursuivent à partir de l’infrastructure hébergée dans le cloud jusqu’à ce que la succursale soit de nouveau en ligne. Les charges de travail sont transférées de nouveau ultérieurement sans modification des paramètres.

Qu’en est-il des succursales disposant d’une mauvaise connectivité ?

La réplication est la seule activité consommant de la bande passante WAN. Nous avons des clients fonctionnant sur des liaisons de 5 Mbps. La réplication est configurée pour s’adapter à la bande passante disponible, et le centre de données gère tout le reste. Si la liaison de la succursale est véritablement inutilisable, l’architecture n’est d’aucune aide, mais aucune autre option ne l’est non plus, à moins d’envoyer des bandes par la poste. 

Si vous gérez plus de 10 succursales, cela mérite qu’on en discute

La plupart des architectures ROBO que nous remplaçons gèrent entre 20 et 500 succursales, avec des appliances de sauvegarde sur chaque site. Le calcul de rentabilité du remplacement de ces systèmes par une solution de sauvegarde à partir de répliques s’avère généralement positif dès la première année, ne serait-ce qu’en évitant le renouvellement du matériel. L’amélioration opérationnelle est généralement plus importante que les économies réalisées, mais plus difficile à quantifier à l’avance. Contactez votre équipe de compte si cela correspond à votre environnement.