Sauvegarde des données

Que comprend la prestation

Nous configurons une sauvegarde automatique de sorte que la perte d'un serveur, un piratage ou une suppression accidentelle ne se transforment pas en perte de l'activité. La prestation comprend une stratégie selon la règle 3-2-1, des instantanés de données chiffrés automatiques et planifiés, l'envoi des copies vers un stockage cloud, une politique de conservation des versions et — impérativement — la vérification de la restauration, et non seulement de la création des copies. Nous analysons quelles données sont exactement critiques : base, fichiers utilisateurs, configuration du serveur, et incluons dans les copies tout le nécessaire pour un redémarrage complet à partir de zéro. Le chiffrement est configuré de sorte que même le propriétaire du stockage ne puisse lire le contenu sans votre clé. Au final, vous n'obtenez pas la promesse que « les sauvegardes se font », mais une procédure vérifiée par laquelle le service se relève en quelques minutes.

Comment cela fonctionne au fond

La sauvegarde repose sur des instantanés incrémentaux : après la première copie complète, le système ne conserve que les blocs modifiés, de sorte que les sauvegardes quotidiennes occupent peu d'espace et se font vite. La déduplication supprime les fragments de données répétés entre les instantanés, et le chiffrement s'effectue de votre côté avant l'envoi vers le cloud, si bien que ce qui part à l'extérieur est déjà une suite d'octets illisible. Chaque instantané est versionné, et l'on peut restaurer à n'importe quel point sauvegardé, pas seulement au dernier. La règle 3-2-1 définit le schéma de conservation : trois copies des données, sur deux supports différents, dont une hors site, pour qu'un incendie ou une défaillance de l'hébergeur ne détruise pas tout d'un coup. L'étape clé, c'est le désarchivage de test régulier d'une copie, car une sauvegarde à partir de laquelle on n'a jamais restauré ne peut être considérée comme une sauvegarde.

D'où vient la culture de la sauvegarde

Il faut distinguer deux mécanismes différents. La tolérance aux pannes de disque a été décrite par l'équipe de l'université de Californie à Berkeley — David Patterson, Garth Gibson et Randy Katz — dans un article sur le RAID en juin 1988 ; le RAID protège de la panne d'un disque, mais ce n'est pas une sauvegarde et il ne protège ni d'une suppression ni d'un rançongiciel. L'outil de copie proprement dit est devenu pour des décennies rsync : Andrew Tridgell et Paul Mackerras en ont présenté l'algorithme et l'utilitaire le 19 juin 1996, faisant pour la première fois du transfert des seules parties modifiées d'un fichier une pratique de masse. La formule de fiabilité elle-même — la règle 3-2-1 — a été énoncée par le photographe Peter Krogh dans un livre sur le stockage numérique, synthétisant l'expérience de protection d'archives irremplaçables. De ces trois idées — redondance, transfert incrémental et stockage réparti — est née la culture moderne des sauvegardes sur laquelle nous nous appuyons.

Pourquoi la précision de la configuration est critique

La sauvegarde est le domaine où l'erreur se découvre au pire moment : quand les données sont déjà perdues et que la copie se révèle incomplète ou corrompue. Le piège classique, ce sont des sauvegardes créées pendant des années mais dont la restauration n'a jamais été vérifiée, et à l'heure de la panne on découvre que la copie ne contient pas la base ou que la clé de chiffrement est perdue. La valeur d'ingénierie de la prestation n'est donc pas d'« activer une sauvegarde », mais d'établir une procédure vérifiable : ce qui est copié précisément, à quelle fréquence, vers où, combien de versions sont conservées et à quelle vitesse tout se relève. Une protection à part, ce sont les copies immuables qu'un rançongiciel ne pourra pas réécrire, même en accédant au serveur. Nous configurons et documentons tout le cycle et vérifions la restauration en pratique, au lieu de croire qu'elle fonctionnera.

Sur quelle stack nous travaillons

L'outil principal, c'est restic : un système de sauvegarde avec instantanés incrémentaux, déduplication et chiffrement de bout en bout, capable de déposer les copies dans un stockage cloud via le protocole S3. Pour une partie des tâches, nous employons borg — un archiveur dédupliquant au modèle similaire, et pour la simple synchronisation de fichiers nous utilisons rsync, éprouvé par le temps. Les copies partent vers un stockage objet compatible S3 (par exemple un cloud facturé au volume et sans frais de trafic sortant), avec des clés d'accès distinctes selon la tâche. Le chiffrement est configuré côté client, de sorte que le contenu des copies est inaccessible même au fournisseur du stockage. La stack est ouverte et portable : la procédure de restauration ne dépend d'aucun fournisseur particulier et reste chez vous, avec les clés.

Quand sont apparus les outils clés

Les outils de sauvegarde se sont constitués sur plus d'une décennie. L'idée de redondance de disque du RAID a été exposée dans un article de l'université de Berkeley en juin 1988. L'utilitaire rsync, longtemps devenu le standard du transfert incrémental, est sorti le 19 juin 1996. Les systèmes de déduplication modernes sont plus jeunes : restic, notre outil principal, a été publié par son auteur Alexander Neumann en version 0.1.0 en 2015, et borg s'est détaché du projet Attic la même année 2015. Ces dates montrent que la sauvegarde chiffrée fiable avec déduplication est une pratique d'ingénierie mature mais relativement récente, qu'il faut savoir configurer selon l'infrastructure concernée. Nous travaillons sur les versions actuelles et connaissons les limites de chaque outil, au lieu de nous fier à un unique bouton universel.

Pourquoi vous pouvez nous le confier

L'expérience cumulée de notre équipe en informatique dépasse 45 ans, et nous menons la sauvegarde par la pratique : nos données de production partent en instantanés incrémentaux chiffrés restic vers un stockage cloud, et notre procédure de restauration est rodée. Nous abordons la tâche en ingénieurs : nous déterminons les données critiques, construisons le schéma 3-2-1, configurons le chiffrement et la rétention, et exécutons impérativement une restauration de test avant de déclarer la sauvegarde opérationnelle. Les clés de chiffrement et les accès restent chez vous — nous ne gardons pas vos données en otage sous notre compte. Nous vous préviendrons franchement là où l'économie sur les copies crée un vrai risque, et là où la redondance est superflue. Au final, vous n'obtenez pas une ligne « sauvegarde activée », mais la capacité vérifiée de relever le service en quelques minutes après une panne, un piratage ou une erreur.