Sauvegarde serveur : restaurer avant de croire

Une stratégie de sauvegarde serveur ne se résume pas à copier des fichiers. Elle fixe ce qui doit revenir, jusqu’à quel point dans le temps, dans quel délai et par qui. Séparez sauvegarde, réplication, instantané et archive, puis prouvez la restauration avant de considérer les données comme protégées.

Le voyant vert d’une tâche planifiée indique au mieux qu’un traitement s’est terminé. Il ne prouve ni la cohérence de l’application, ni la disponibilité des clés, ni la capacité d’une équipe à reconstruire le service. Le résultat attendu est un service restauré, pas une collection de fichiers.

• Périmètre : données, configuration, secrets, dépendances et documentation nécessaires au redémarrage.
• Objectifs : perte de données acceptable et délai de reprise décidés par service.
• Résilience : copies séparées du système de production et de ses privilèges.
• Preuve : restauration chronométrée, contrôles applicatifs et compte rendu exploitable.

Ne confondez pas les quatre outils

Ces mécanismes se complètent, mais ils ne répondent pas au même incident. Les confondre crée une protection séduisante sur le papier et fragile le jour de la panne.

La réplication privilégie la disponibilité. Elle aide après une panne d’hôte, mais reproduit parfois une erreur logique. L’instantané privilégie la vitesse. S’il reste dans le même domaine d’administration et sur la même infrastructure, il partage encore une partie du risque.

L’archive répond à une autre question : que faut-il conserver, retrouver et comprendre longtemps après ? Une politique d’archivage peut garder des documents ou journaux sans contenir les binaires, secrets et dépendances nécessaires à une reprise.

Fixez RPO et RTO avant la fréquence

Le RPO décrit le point dans le temps auquel les données doivent revenir. Il traduit la perte acceptable : transactions récentes, commandes, fichiers déposés ou modifications de configuration. Le RTO décrit le délai dans lequel le service doit être rétabli.

Ne choisissez donc pas une fréquence parce qu’elle semble standard. Partez du coût métier d’une perte et d’une interruption. Un catalogue rarement modifié et une base de commandes n’appellent ni la même cadence, ni la même méthode, ni le même ordre de reprise.

Écrivez un objectif par service. Il doit nommer les données, la dépendance critique, le responsable, le point de reprise attendu et le délai vérifié. Un RTO sans environnement de restauration, capacité réseau et temps humain reste une intention.

La facture suit ces choix. Des copies plus fréquentes consomment stockage, transfert, opérations et surveillance. Des restaurations plus rapides peuvent demander une infrastructure prête à démarrer. Vérifiez la facture complète : conservation, lectures, sorties de données, suppression protégée et temps d’exploitation.

Utilisez 3-2-1 comme aide-mémoire

La règle 3-2-1 propose trois copies, sur deux supports ou systèmes, dont une hors site. Elle réduit certains risques locaux, mais ne garantit ni l’isolement logique, ni une copie hors ligne, ni la cohérence de l’application.

Deux espaces de stockage administrés par le même compte peuvent tomber dans le même rayon d’explosion. Une réplication vers une autre région peut rester accessible au même identifiant compromis. Une copie hors site n’est donc pas automatiquement hors ligne, immuable ou indépendante.

Ajoutez les propriétés qui répondent à votre menace :

• Hors ligne ou déconnectée : aucune session permanente depuis la production.
• Immuable : modification et suppression bloquées pendant une durée maîtrisée.
• Hors site : séparation d’un incident physique ou régional.
• Administration isolée : comptes, authentification forte et chemins réseau distincts.

L’immuabilité limite certaines suppressions, mais une mauvaise durée de conservation, un compte de contrôle compromis ou une configuration erronée restent possibles. Aucune étiquette ne remplace la vérification. CISA recommande d’ailleurs des copies critiques hors ligne et chiffrées, puis des tests réguliers de disponibilité et d’intégrité.

Séparez identifiants, clés et production

Le logiciel malveillant qui atteint l’administrateur de production ne devrait pas obtenir automatiquement le droit d’effacer les sauvegardes. Utilisez des comptes propres à la sauvegarde, des droits minimaux et une interface d’administration non exposée aux postes ordinaires.

Le chiffrement protège les supports perdus ou consultés sans autorisation. Il crée aussi une dépendance : la clé doit survivre à l’incident. Gardez la procédure, le matériel ou le service de gestion de clés et les accès de secours hors du système qu’ils doivent permettre de reconstruire.

Évitez toutefois de placer clé et copie dans le même coffre logique sous le même compte. Une sauvegarde chiffrée dont personne ne peut récupérer la clé ressemble à une réserve fermée dont la serrure a disparu.

Rendez la copie cohérente avec l’application

Copier un disque actif ne garantit pas que l’application retrouvera un état exploitable. Bases de données, files de messages, index, pièces jointes et fichiers doivent représenter un même instant logique ou disposer d’une procédure de rapprochement.

Utilisez les mécanismes documentés par le moteur : export cohérent, sauvegarde physique coordonnée, journal de transactions ou intégration prévue pour les instantanés. PostgreSQL indique, par exemple, qu’un export logique représente une vue cohérente d’une base, tout en avertissant que plusieurs bases exportées séparément ne partagent pas forcément le même instant.

Testez le parcours métier. Après restauration, ouvrez l’application, authentifiez un compte de test, lisez et écrivez une donnée, vérifiez les pièces jointes, les tâches différées et les intégrations indispensables. Un démarrage sans erreur ne suffit pas.

Une sauvegarde ne se juge pas à son voyant vert, mais au service qu’elle permet réellement de reconstruire.

Adaptez la rétention au risque

Une rotation courte peut effacer le dernier état sain avant que l’incident soit détecté. Une conservation très longue augmente coût, surface de données sensibles et complexité de recherche. La politique doit relier chaque classe de données à sa fréquence, sa durée, son motif et sa méthode de suppression.

Conservez plusieurs générations lorsque la corruption peut rester silencieuse. Protégez séparément les éléments rarement modifiés mais indispensables : configuration, définitions d’infrastructure, certificats, documentation, comptes de service et informations de licence.

Surveillez la chaîne entière : tâche non exécutée, volume anormal, durée inhabituelle, copie non répliquée, expiration d’identifiant, espace insuffisant et échec de contrôle. Une alerte doit nommer un responsable et un délai de traitement.

Le coût utile se lit par restauration possible, pas seulement par gigaoctet stocké. Mesurez le temps de récupération, la quantité réellement récupérable, les frais de transfert et les heures humaines du test.

Testez une restauration isolée

Un contrôle de somme montre qu’un objet n’a pas changé depuis son calcul. Il ne prouve pas que toutes les dépendances existent ni que l’application saura le lire. Planifiez une restauration complète dans un environnement isolé de la production.

Le test doit choisir une génération, récupérer les clés, reconstruire l’infrastructure minimale, restaurer dans le bon ordre et exécuter des contrôles techniques puis métier. Chronométrez chaque étape et comparez le total au RTO. Vérifiez aussi que le point obtenu respecte le RPO.

Consignez les écarts. Une restauration lente mais comprise est plus utile qu’un succès annoncé sans mesure. Réparez le runbook, les droits ou la capacité, puis rejouez le scénario. Le panier ne lit pas les excuses ; le service interrompu non plus.

Écrivez le runbook pour une journée difficile

Le runbook doit rester utilisable quand les outils habituels, l’annuaire ou le serveur documentaire sont indisponibles. Conservez une copie protégée avec les coordonnées, priorités, dépendances, emplacements, accès de secours et critères de validation.

Précisez qui déclare l’incident, qui autorise la restauration, qui décide qu’une source est saine et qui valide le retour du service. Ajoutez un critère d’arrêt : une donnée suspecte ne doit pas être réinjectée seulement pour gagner quelques minutes.

Choisissez une stratégie simple si elle respecte vos objectifs et survit au test. Évitez une architecture sophistiquée que personne ne sait restaurer. Le bon dispositif combine copies séparées, cohérence applicative, droits isolés, rétention explicite et exercice répété.