Votre sauvegarde ne fonctionne probablement pas (et comment le vérifier)
La majorité des entreprises que nous auditons disposent d'une sauvegarde. Une minorité dispose d'une sauvegarde restaurable. La différence entre les deux ne se découvre qu'au pire moment.
Le constat qui revient dans presque chaque audit
Quand nous auditons le parc informatique d'une entreprise, la question des sauvegardes reçoit presque toujours la même réponse : « oui, tout est sauvegardé automatiquement ». Quand nous demandons quand une restauration a été testée pour la dernière fois, la réponse est presque toujours qu'aucun test n'a jamais eu lieu.
Ce n'est pas de la négligence. Une sauvegarde qui tourne sans erreur visible donne un sentiment légitime de sécurité, et personne n'a envie de consacrer une demi-journée à vérifier quelque chose qui semble déjà fonctionner. Le problème est que les modes de défaillance d'une sauvegarde sont silencieux par nature.
Nous avons rencontré des sauvegardes interrompues depuis huit mois sans qu'aucune alerte ne remonte, parce que le disque de destination était plein. Des sauvegardes qui copiaient consciencieusement un dossier devenu obsolète après une migration, laissant les données réellement utilisées en dehors du périmètre. Des sauvegardes de base de données réalisées à chaud sans mécanisme de cohérence, produisant des fichiers inexploitables. Dans chacun de ces cas, la tâche s'exécutait, et le rapport indiquait « succès ».
Ce que signifie réellement tester une restauration
Tester une restauration ne consiste pas à vérifier que les fichiers de sauvegarde existent, ni à ouvrir l'interface de l'outil pour constater que la dernière exécution est marquée en vert. Cela consiste à restaurer effectivement les données sur un environnement séparé, et à vérifier qu'elles sont exploitables.
La procédure minimale tient en quatre étapes. D'abord, choisir un jeu de données représentatif : la base de production, pas un fichier texte isolé. Ensuite, restaurer sur un environnement distinct de la production, pour ne prendre aucun risque sur les données vivantes. Puis ouvrir les données restaurées avec l'application qui les utilise — une base restaurée que le logiciel métier refuse d'ouvrir n'a servi à rien. Enfin, mesurer le temps que l'opération a réellement pris.
Cette dernière mesure est souvent la plus instructive. Beaucoup d'entreprises découvrent à cette occasion que restaurer leur système prendrait deux jours, alors que leur activité ne peut pas s'arrêter plus de quelques heures. Ce n'est pas un problème de sauvegarde, c'est un problème de dimensionnement — mais il ne se révèle qu'en testant.
La règle 3-2-1, et ce qu'elle implique concrètement ici
La règle classique reste pertinente : trois copies des données, sur deux types de supports différents, dont une conservée hors site. Elle mérite toutefois d'être traduite dans le contexte d'exploitation local.
Les trois copies incluent la donnée de production. Il faut donc deux sauvegardes distinctes, pas une seule. Les deux supports différents visent à éviter qu'une défaillance matérielle d'un même type détruise les deux copies simultanément — un disque interne et un disque externe du même modèle acheté le même jour ne constituent pas vraiment deux supports.
La copie hors site est le point le plus souvent négligé, et le plus important. Un incendie, un dégât des eaux ou un vol dans les locaux emporte tout ce qui s'y trouve, y compris le disque de sauvegarde posé à côté du serveur. La copie distante peut être un stockage en ligne, un disque conservé dans un autre bâtiment, ou un serveur secondaire — l'essentiel est la séparation physique.
Une précision importante compte tenu de la fréquence des rançongiciels : une sauvegarde accessible en permanence depuis le réseau sera chiffrée en même temps que le reste. Il faut au moins une copie déconnectée ou en écriture unique.
Par où commencer si rien n'est en place
La première étape n'est pas technique. Il s'agit d'identifier ce qui doit absolument être sauvegardé : quelles données feraient réellement s'arrêter l'activité si elles disparaissaient ce soir. La réponse est généralement plus courte qu'on ne l'imagine — souvent une base de données, quelques dossiers partagés et la messagerie.
La deuxième étape consiste à fixer deux valeurs. Combien de temps l'activité peut-elle fonctionner sans ces données, et quelle perte de données récentes est acceptable. Une entreprise qui accepte de perdre une journée de saisie n'a pas besoin du même dispositif qu'une structure où chaque heure compte. Ces deux chiffres déterminent la fréquence et l'architecture, et évitent d'investir dans un dispositif surdimensionné.
Vient seulement ensuite le choix de l'outil et sa configuration. Puis, dès la mise en place, la planification du premier test de restauration — dans le mois suivant, pas « quand on aura le temps ».
Questions fréquentes
À quelle fréquence tester une restauration ?
Au minimum deux fois par an, et systématiquement après tout changement d'infrastructure : migration, changement de serveur, mise à jour majeure du logiciel métier. Un test après changement révèle les sauvegardes devenues obsolètes, qui sont le cas le plus fréquent.
Le cloud dispense-t-il de sauvegarder ?
Non. Un hébergeur garantit la disponibilité de son infrastructure, pas la protection contre vos propres erreurs. Une suppression accidentelle, une corruption applicative ou un compte compromis se répliquent dans le cloud comme ailleurs. La plupart des services proposent des sauvegardes, mais elles doivent être activées, configurées et testées.
Combien coûte une sauvegarde correcte ?
Nettement moins que la perte des données, mais le montant dépend du volume, de la fréquence et du délai de reprise attendu. C'est précisément pourquoi il faut fixer ces paramètres avant de choisir une solution : le dimensionnement détermine le coût bien plus que la marque de l'outil.