La règle 3-2-1
des sauvegardes

Trois copies de vos données — l'original plus deux —, sur deux supports de nature différente, dont l'une hors du bâtiment où se trouve l'original. Chaque chiffre couvre une panne différente : la deuxième copie couvre la défaillance de la première ; le second support évite qu'un même type de panne (mécanique, firmware, défaut de série) touche les deux à la fois ; la copie hors site couvre l'incendie, le vol, le dégât des eaux ou tout ce qui peut arriver au bâtiment entier. C'est une règle de conception, pas de contrôle : elle vous dit combien de copies avoir et où les placer, mais rien sur la possibilité de les ouvrir le jour où vous en aurez besoin. Cette partie — celle qui détermine vraiment si la règle a servi à quelque chose — est l'objet de cet article : le test de restauration.

En restaurant, pas en consultant le journal du logiciel de sauvegarde. Choisissez un fichier quelconque — pas le plus facile, un au hasard —, retirez-le de votre vue ou travaillez sur une copie du système, et récupérez-le depuis la sauvegarde comme si vous l'aviez réellement perdu. Puis ouvrez-le. S'il s'ouvre et que le contenu est celui attendu, cette sauvegarde fonctionne à ce moment-là. Si le processus échoue, se bloque, demande un mot de passe dont personne ne se souvient ou si le fichier récupéré ne s'ouvre pas, vous venez de trouver le problème avec tout le temps nécessaire pour le corriger, au lieu de le découvrir le jour où vous aurez vraiment perdu quelque chose. Un rapport « sauvegarde terminée sans erreur » ne prouve pas cela : il confirme que des octets ont été écrits quelque part, pas que ces octets forment un fichier lisible.

Cela dépend de votre dépendance à ces données, pas d'un calendrier fixe valable pour tous. Pour un particulier avec des photos et des documents, une vérification trimestrielle est raisonnable : prendre un fichier au hasard et l'ouvrir. Pour une PME avec des dossiers partagés utilisés au quotidien, une fréquence mensuelle a plus de sens, car davantage de personnes produisent de nouvelles données et il y a plus de risques qu'une panne passe inaperçue. Pour les données critiques — comptabilité, un serveur dont la panne arrête l'activité —, il convient d'ajouter une restauration complète, pas seulement d'un fichier, au moins une fois par an, pour vérifier aussi combien de temps il faut pour redevenir opérationnel. L'important n'est pas de trouver la cadence exacte, mais qu'il en existe une, écrite quelque part, avec la date de la dernière fois.

Le traiter pour ce qu'il est : une sauvegarde cassée qui donnait jusqu'ici un faux sentiment de sécurité — et mieux vaut le découvrir maintenant que le jour où vous en aurez vraiment besoin. D'abord, vérifiez si le problème est ponctuel — ce fichier précis s'est corrompu lors de la copie — ou général — la dernière restauration complète ne fonctionne pas non plus, ce qui désigne la tâche planifiée, la connexion à la destination ou une destination pleine depuis longtemps où les copies récentes n'ont jamais été écrites. Regardez la date réelle du fichier que vous avez pu restaurer : s'il date de plusieurs mois, la sauvegarde n'est plus mise à jour depuis des mois, même si le logiciel affirme le contraire. Une fois la panne corrigée, refaites le test avec un autre fichier avant de considérer à nouveau le système comme fiable.

Parce que « sans erreur » certifie seulement que le processus d'écriture n'a rencontré aucun problème qu'il sache lui-même détecter, et certaines pannes n'entrent pas dans cette catégorie : un fichier corrompu lors de la compression mais écrit quand même, un dossier sorti du périmètre de sauvegarde après un changement de chemin que personne n'a reporté, des identifiants d'accès à la destination expirés pendant que le système réessaie en silence, un disque de destination plein où les copies les plus récentes ne tiennent tout simplement plus et sont écartées sans alerte visible. Tous ces cas produisent à la fois un historique « terminé avec succès » et une sauvegarde inutile. La seule façon de les découvrir avant d'en avoir besoin est d'essayer de récupérer quelque chose de réel et de vérifier que le résultat est bien celui attendu.

Une personne précise, avec la tâche inscrite à son agenda, et non comme quelque chose que « quelqu'un devrait regarder de temps en temps » — la formule qui garantit que ce n'est jamais fait. Il n'est pas nécessaire que ce soit le profil technique le plus expérimenté : le test lui-même — choisir un fichier, le restaurer, l'ouvrir, noter la date — peut être réalisé par n'importe qui ayant accès au système de sauvegarde, en suivant une liste de contrôle fixe. Il vaut mieux, en revanche, que ce soit la même personne à chaque fois, pour qu'elle remarque les changements de comportement, et que le résultat soit noté quelque part avec la date, même dans un simple tableur partagé. Si personne dans l'entreprise n'a le temps ou le recul pour l'assumer durablement, c'est exactement le vide que comble un service de maintenance géré.