Quatre couches entre vos données et le sinistre

Demandez à n’importe quel dirigeant d’entreprise s’il a des sauvegardes et la réponse sera oui. La question utile est autre : de quoi cette sauvegarde vous protège-t-elle exactement ? Un fichier effacé par erreur, une base de données à ramener à son état d’hier 14 h 30, un serveur qui meurt un mardi matin et un ransomware détecté trois jours trop tard sont quatre sinistres différents. Une seule sauvegarde ne couvre pas les quatre.

C’est pourquoi nos sauvegardes gérées ne sont pas « une sauvegarde » : ce sont quatre couches empilées, et chacune existe parce qu’elle couvre un risque que les autres ne couvrent pas.

Couche 1 : l’application se sauvegarde elle-même. Personne ne sait sauvegarder une base de données mieux que le moteur qui la gère. La première sauvegarde, c’est l’application elle-même qui la génère : SQL Server, par exemple, écrit ses sauvegardes complètes, différentielles et du journal de transactions sur un disque dédié, en suivant des procédures de référence comme celles d’Ola Hallengren. C’est la sauvegarde qui permet de revenir à un point logique exact d’une base de données. Elle récupère une donnée.

Couche 2 : des fichiers avec versions. Avec Backup for Workgroups, nous copions vers un serveur externe les fichiers que les applications ont déjà générés — vidages de bases de données, fichiers web, configurations, exports — et nous conservons les versions antérieures. Quelqu’un a effacé ou écrasé un fichier ? On récupère ce fichier, sans toucher à rien d’autre. Elle récupère un fichier.

Couche 3 : la réplique. Chaque machine virtuelle qui le requiert dispose d’une copie vivante sur un autre serveur physique, maintenue avec Hyper-V Replica. Si le serveur principal tombe, la réplique démarre et le travail continue. Sur les systèmes les plus critiques, la réplique se met à jour toutes les 30 secondes : c’est, au maximum, ce que l’on peut perdre. Ce n’est pas une archive historique — c’est de la continuité. Elle récupère le service.

Couche 4 : la machine complète, avec mémoire. Avec Hornetsecurity VM Backup, nous sauvegardons chaque machine virtuelle entière depuis un serveur externe et nous gardons un historique avec rétention GFS : sauvegardes quotidiennes de la dernière semaine, hebdomadaires du dernier mois et mensuelles remontant à plusieurs mois. Cette couche répond à la question à laquelle la réplique ne peut pas répondre : et si le problème est à l’intérieur depuis des jours ? Un ransomware qui chiffre en silence se copie aussi vers la réplique ; l’historique permet de revenir à un point antérieur propre. Elle récupère l’historique.

Et tout ce qui précède, à une condition : que rien ne vive dans un seul bâtiment. Chaque jour, une copie est externalisée vers un second centre de données, physiquement séparé du principal, où l’on conserve au minimum la dernière semaine de sauvegardes. Si le centre de données principal devenait indisponible — incendie, inondation, panne électrique grave —, l’infrastructure continuerait d’exister ailleurs.

Reste la nuance qui sépare une sauvegarde d’une impression de sauvegarde : une copie ne vaut que si sa restauration a été testée. Qu’un travail se termine « sans erreurs » ne démontre rien. C’est pourquoi des vérifications périodiques sont exécutées, au cours desquelles la machine virtuelle est montée depuis la sauvegarde elle-même pour vérifier qu’elle est utilisable, et chaque matin le rapport de tous les travaux de la nuit est passé en revue.

Cette architecture n’est pas théorique. Une entreprise d’impression et de gestion documentaire disposant de deux centres de données en propre l’utilise en mode croisé : nous avons installé une appliance de sauvegarde — un serveur préparé et géré par nous — sur chaque site, et chacun garde les sauvegardes de l’autre. Un grossiste en matières premières avec son propre centre de données a une appliance à nous dans ses locaux : copie locale pour restaurer vite et externalisation quotidienne vers notre centre de données — si son site tombait entièrement, nous remonterions son infrastructure dans notre cloud. C’est le même principe que nous appliquons dans les environnements de cloud hybride et, bien sûr, sur notre propre infrastructure : nous sommes notre premier client.

Une dernière donnée, démontrable : les dépôts où atterrissent ces sauvegardes atteignent jusqu’à 9 111 MB/s en écriture et 8 706 MB/s en lecture lors de tests séquentiels avec CrystalDiskMark, mesurés avec des volumes occupés à 72 % et à 77 % — pas vides. C’est une mesure du stockage, pas une promesse de vitesse de sauvegarde de bout en bout ; ce que cela garantit, c’est que, le jour où il faudra restaurer, le disque ne sera pas le goulot d’étranglement.

Le diagramme ci-dessous le résume. Si, en le lisant, vous ne savez pas dire lesquelles de ces quatre couches votre entreprise possède — ou si vous soupçonnez qu’elle n’en a qu’une —, c’est exactement la conversation qui mérite d’avoir lieu.