Sauvegardes : comment vérifier que les vôtres fonctionnent vraiment

Presque toutes les organisations ont des sauvegardes. Très peu ont vérifié qu'elles se restaurent. L'écart entre les deux n'apparaît qu'une seule fois, et c'est le mauvais jour.

Cet article propose un test d'une heure, réalisable sans interrompre quoi que ce soit, qui transforme une intention en certitude. Si vous ne devez retenir qu'une chose : une sauvegarde dont personne n'a jamais restauré le contenu n'est pas une sauvegarde. C'est un fichier dont on espère quelque chose.

Le jour où ça arrive

La séquence est banale. Un fichier essentiel disparaît — supprimé par erreur, écrasé par un import, rendu illisible par une panne de disque ou par un rançongiciel. On cherche la sauvegarde. Elle existe : le prestataire l'avait mise en place, le voyant est vert depuis des mois.

Puis on découvre l'une de ces quatre choses, dans un ordre variable. La sauvegarde s'arrête à une date antérieure à ce que l'on croyait, parce qu'une tâche échoue silencieusement depuis six semaines. Elle contient les fichiers mais pas la base de données. Elle se trouve sur le même serveur que ce qu'elle sauvegarde, et a disparu avec lui. Ou elle est complète et restaurable, mais personne ne sait comment s'y prendre, et l'on découvre la procédure un jour de crise.

Aucun de ces quatre cas n'est rare. Tous se détectent à l'avance, en une heure.

La règle 3-2-1, et le pourquoi de chaque chiffre

Trois copies, sur deux supports différents, dont une hors site. La formule circule partout ; ce qui circule moins, c'est la raison d'être de chaque terme.

• Trois copies — l'original plus deux sauvegardes. Deux copies seulement signifient qu'une défaillance pendant la restauration vous laisse sans rien : c'est précisément le moment où l'on sollicite le matériel.
• Deux supports différents — parce que les défaillances sont souvent liées au type de support. Deux disques du même modèle, achetés ensemble, vieillissent ensemble.
• Une copie hors site — parce qu'un incendie, un dégât des eaux ou un vol emporte tout ce qui se trouve au même endroit, quel qu'en soit le nombre.

Une quatrième exigence s'est imposée depuis : au moins une copie déconnectée, qu'aucune machine ne peut atteindre en écriture. Nous y revenons plus bas.

Les trois questions à poser

À votre prestataire, ou à la personne qui s'en occupe en interne. Elles ne demandent aucune compétence technique.

1. À quelle fréquence, et que perd-on entre deux sauvegardes ? Une sauvegarde quotidienne signifie qu'un incident à 17 h coûte la journée de travail. C'est peut-être acceptable — mais cela doit être une décision, pas une découverte.
2. Sur quelle profondeur d'historique ? Si l'on ne garde que la dernière copie, un fichier corrompu depuis trois semaines a été sauvegardé corrompu vingt et une fois. La profondeur protège des erreurs qu'on ne remarque pas tout de suite.
3. Qui a déjà restauré, et quand ? La seule question qui compte vraiment. Si la réponse est « personne », vous connaissez l'état réel du dispositif.

La restauration à blanc

C'est le cœur de la démarche, et cela se fait sans aucun risque à condition de respecter une règle : on ne restaure jamais sur le système d'origine. Le test ne doit pas pouvoir provoquer l'incident qu'il prévient.

1. Choisir

Prenez une sauvegarde ancienne, pas celle d'hier : deux ou trois semaines. C'est la profondeur d'historique que vous testez en même temps.

2. Isoler

Un serveur de test, une machine virtuelle, un poste dédié. Rien qui communique avec la production.

3. Restaurer

Suivez la procédure écrite. Si elle n'existe pas, c'est le premier résultat du test — et il faut la rédiger pendant que vous la découvrez au calme, pas un jour de panne.

4. Vérifier, avec des données que vous connaissez

Le point le plus souvent bâclé. Une restauration qui « se termine sans erreur » ne prouve rien : elle peut avoir produit une base vide. Comparez ce qui est vérifiable — le nombre d'enregistrements par table, la présence d'un dossier client précis, l'ouverture d'un document que vous savez identifier. Ouvrez réellement les fichiers : une archive qui se décompresse peut contenir des fichiers illisibles.

5. Noter

La date du test, le temps qu'il a pris, ce qui a coincé. Le temps mesuré ici est la donnée la plus utile de tout l'exercice : c'est votre durée d'interruption réelle, celle qu'on vous demandera d'annoncer le jour venu.

Ce qu'une sauvegarde ne protège pas

Un rançongiciel qui atteint votre réseau chiffre aussi ce qu'il peut écrire — y compris les disques de sauvegarde connectés et les dossiers synchronisés dans le nuage. Une sauvegarde en permanence accessible depuis la machine sauvegardée n'est pas une protection contre ce cas-là, quel que soit son volume.

D'où la copie hors ligne : un support physiquement débranché entre deux sauvegardes, ou un espace distant en écriture unique, que rien ne peut modifier après coup. C'est la seule copie qui reste debout quand tout le reste tombe ensemble.

Une sauvegarde connectée en permanence protège d'un disque qui casse. Elle ne protège pas de quelqu'un qui entre.

À quelle fréquence retester

Une cadence tenable vaut mieux qu'une cadence idéale abandonnée au bout d'un mois. Deux fois par an, inscrites au calendrier avec un responsable nommé, suffisent pour la plupart des organisations — plus un test supplémentaire après tout changement de serveur, d'hébergeur ou de logiciel de sauvegarde, car c'est là que les dispositifs se cassent silencieusement.

Ajoutez une alerte en cas d'échec. Sans elle, une tâche qui cesse de tourner ne se signale pas : le silence ressemble exactement au bon fonctionnement.

Ce que vous saurez à la fin

Trois choses que vous ignoriez probablement : combien de temps prend réellement une restauration, quelle quantité de travail vous perdez au maximum, et qui, chez vous, sait faire l'opération. Ces trois réponses valent davantage que le volume de vos archives.

Nos pages Cybersécurité et DevOps & Cloud traitent respectivement de la protection et de l'automatisation de ces dispositifs. Le test décrit ci-dessus, lui, ne demande personne d'autre que vous.