Quand nous reprenons un parc informatique, la question « faites-vous des sauvegardes ? » reçoit presque toujours la même réponse : oui, un logiciel tourne la nuit et la pastille est verte. Puis nous ouvrons la console. La dernière copie complète date de plusieurs semaines, la destination est un dossier partagé du serveur qui se sauvegarde lui-même, et personne dans l'entreprise n'a jamais remis un fichier en place depuis cette copie.
Ce n'est pas de la négligence. C'est la conséquence d'une confusion répandue : le dirigeant croit avoir acheté une garantie de reprise, alors qu'il a installé un outil de copie. Les deux ne se recouvrent pas. Une copie que personne n'a rejouée reste une hypothèse : vous supposez qu'elle est lisible, complète, et exploitable sur une machine que vous ne possédez pas encore. Le jour de l'incident, ces trois suppositions se vérifient en même temps, sous pression, avec les salariés qui attendent devant des écrans vides.
Une sauvegarde répond à une question, une reprise en résout dix
Une sauvegarde répond à une seule question : pouvez-vous récupérer tel fichier, telle base de données ou tel serveur, à telle date ? C'est nécessaire, et cela ne suffit pas.
Le plan de reprise d'activité, que l'on abrège en PRA, répond aux questions qui arrivent juste après. Sur quelle machine restaurez-vous, si le serveur d'origine est chiffré ou hors service ? Dans quel ordre remontez-vous les services, sachant que l'application de gestion ne démarre pas avant sa base de données, et que rien ne fonctionne avant l'annuaire et la résolution de noms ? Avec quels comptes travaillez-vous, si l'administrateur du domaine est justement celui qui a été compromis ? Qui décide d'arrêter la production, qui prévient les salariés, qui appelle l'assurance et le prestataire ?
Tant que ces réponses ne sont pas écrites quelque part, vous détenez une archive et non un plan. Nous traitons ce volet dans notre offre de sauvegarde et de reprise d'activité, parce qu'il demande un travail d'organisation autant qu'un travail technique.
Les deux chiffres que nous demandons avant de parler de stockage
Avant de choisir un logiciel ou un volume de disque, nous demandons deux chiffres au dirigeant, et nous les traduisons systématiquement en français courant.
Le premier est la perte de données acceptable, appelée RPO dans les documentations : quelle quantité de travail acceptez-vous de refaire à la main si un incident survient ? Si vos copies partent une fois par nuit, vous acceptez implicitement de perdre une journée de saisie. Certaines entreprises s'en accommodent. Un cabinet qui encaisse des paiements ou saisit des écritures toute la journée ne s'en accommode pas, et il faut alors des copies plus fréquentes de la base concernée, pas de tout le parc.
Le second est le temps de reprise visé, appelé RTO : au bout de combien de temps l'activité doit-elle avoir repris ? Une demi-journée d'arrêt et trois jours d'arrêt ne demandent pas la même infrastructure. Descendre à quelques heures implique une machine de secours déjà disponible, des copies déjà présentes sur place, et une procédure répétée. Accepter deux jours autorise une reprise plus artisanale, donc moins coûteuse.
Ces deux chiffres ne sont pas des concepts d'ingénieur : ce sont des décisions de dirigeant, et elles déterminent le budget. C'est pour cette raison que nous les posons au début de l'audit, et non après avoir vendu une capacité de stockage. Dans un contrat d'infogérance, qui démarre à 120 HT / mois, ils figurent noir sur blanc et se relisent chaque année, parce que l'activité évolue.
Pourquoi une sauvegarde « réussie » peut rester inexploitable
Le rapport quotidien qui affiche un succès mesure une chose très précise : le travail de copie s'est terminé sans erreur bloquante. Il ne mesure pas la valeur de ce qui a été copié. Voici les défauts que nous rencontrons le plus souvent en reprenant un existant.
- Le travail sauvegarde un partage vide ou un volume monté trop tard, et il réussit donc parfaitement en écrivant très peu de données. Personne ne compare la taille d'une nuit à l'autre, alors la dérive passe inaperçue pendant des mois.
- La base de données est copiée à chaud, sans mécanisme de mise en cohérence, si bien que le fichier récupéré est techniquement présent mais refuse de s'ouvrir. Le problème n'apparaît qu'au moment de la restauration.
- La rétention est trop courte pour être utile. Une semaine de copies ne vous sauve pas si un attaquant est resté discrètement deux mois dans le réseau : toutes vos versions disponibles sont postérieures à la compromission.
- La destination reste accessible en écriture avec les comptes utilisés au quotidien. Un logiciel malveillant qui obtient ces identifiants efface les copies avant de chiffrer la production, et il le fait sans difficulté particulière.
- Aucune alerte ne remonte quand un travail échoue plusieurs soirs de suite, et l'échec ne se découvre donc qu'au moment où quelqu'un cherche à restaurer quelque chose.
L'exercice de restauration que nous inscrivons au calendrier
Restaurer n'est pas un bouton, c'est un exercice. Nous planifions donc des tests dans l'année, sans prétendre tout rejouer à chaque fois : un scénario suffit, à condition qu'il soit réel et chronométré. Un mois nous remontons un dossier utilisateur supprimé, un autre une machine virtuelle complète sur un hôte de secours, un autre une boîte mail, un autre un site WordPress sur un hébergement de test.
Ce qui casse pendant ces exercices est toujours instructif, et rarement lié au logiciel de sauvegarde. Une licence applicative se réactive sur la nouvelle machine et le fabricant demande un délai. Un certificat expire pendant que le service est arrêté. Les droits sur les dossiers ne suivent pas parce que les identifiants de sécurité ont changé. Une entrée de résolution de noms pointe encore vers l'ancienne adresse. Nous notons chaque point dans la procédure écrite, puis nous corrigeons cette procédure. Au bout de deux ou trois exercices, le temps de reprise mesuré devient un chiffre défendable devant un assureur ou un client, ce que le questionnaire d'une cyberassurance va précisément chercher.
Si vous n'avez jamais restauré quoi que ce soit, considérez que vous n'avez pas encore de sauvegarde. La formulation est rude, elle est honnête, et elle coûte moins cher qu'une découverte le samedi soir.
Notre séquence quand nous reprenons des sauvegardes existantes
Nous commençons par un inventaire court, qui tient en une réunion et quelques accès : où se trouvent les copies, quelle rétention est réellement conservée, qui détient les droits sur la destination, et quand une restauration a réussi pour la dernière fois. Cet état des lieux révèle souvent qu'un serveur ajouté il y a deux ans n'est dans aucun travail de copie.
Nous corrigeons ensuite l'architecture des copies elles-mêmes, sujet que nous détaillons dans notre article sur la règle 3-2-1 et le hors site. Nous branchons la supervision des travaux, avec une alerte qui arrive chez nous et pas seulement dans une boîte que personne ne lit. Puis nous écrivons la procédure de reprise, service par service, avec les comptes de secours conservés hors du domaine. Enfin nous fixons le calendrier des exercices.
Les données hébergées chez un éditeur en ligne se traitent à part, avec leurs propres mécanismes : nous expliquons pourquoi dans notre article sur le fait que Microsoft 365 n'est pas une sauvegarde. Les sites internet que nous maintenons ont eux aussi leur rythme de copies, en dehors du serveur qui les héberge.
Retenez la distinction : disposer de copies vous protège d'une erreur de manipulation, disposer d'une reprise testée vous protège d'un arrêt d'activité. Si vous ignorez dans quelle catégorie vous vous trouvez, demandez-nous un état des lieux : nous vous dirons si vos copies actuelles tiennent, ou s'il faut d'abord en construire une qui survive à une attaque. Et si tout est déjà chiffré au moment où vous lisez ces lignes, appelez plutôt notre ligne d'urgence, facturée 230 HT / h hors contrat.