Sauvegardes : une copie jamais restaurée ne protège de rien
Presque tous les hébergements annoncent des sauvegardes quotidiennes. Très peu peuvent dire quand ils ont restauré la dernière, en combien de temps, et si le site était réellement complet au bout du compte. La différence entre une copie et une sauvegarde tient dans un seul geste, celui de la restauration, et c'est précisément celui que personne ne fait.
Une copie n'est pas une sauvegarde
Une copie de fichiers prouve qu'un script a tourné à une heure donnée. Une sauvegarde prouve qu'on peut revenir en arrière : retrouver le site tel qu'il était avant la panne, avant l'effacement, avant la mise à jour qui a cassé quelque chose. Entre les deux, il y a un essai de restauration, un chronomètre et une vérification du contenu. Tant que cet essai n'a pas eu lieu, l'existence du fichier ne dit rien de sa qualité.
Les deux mesures qui comptent se nomment perte de données acceptable et délai de retour acceptable. La première indique combien d'heures de travail peuvent disparaître sans conséquence réelle. La seconde indique combien de temps le site peut rester indisponible. Ces deux chiffres décident de la fréquence des copies et de la vitesse du matériel de secours, pas l'inverse. Un hébergement qui ne les connaît pas ne peut pas dimensionner grand-chose.
Les copies qui existent et qui ne restaurent pas
Le cas le plus fréquent n'est pas l'absence de sauvegarde : c'est la sauvegarde incomplète. Une base de données exportée chaque nuit, mais sans les fichiers envoyés par les visiteurs, donne un site qui redémarre avec des articles et sans images. Un export réalisé pendant une écriture donne une base tronquée, que l'on découvre au moment de la restauration, c'est-à-dire au pire moment.
- La copie posée sur le même disque que les données : elle disparaît avec lui.
- La rétention trop courte : sept jours de copies quotidiennes, et l'erreur découverte au dixième jour n'est plus réparable.
- La copie qui n'inclut pas les fichiers envoyés, les images, les documents ou les boîtes de courriel.
- Le compte de sauvegarde qui dispose d'un accès en écriture aux sauvegardes : un rançongiciel efface les deux.
- La copie jamais relue : une archive de deux gigaoctets peut être vide à l'intérieur.
Ce qu'il faut tester, et à quelle fréquence
Une restauration complète devrait être tentée au moins une fois par trimestre, sur un environnement séparé, sans toucher au site en production. On y mesure trois choses : le temps total, la complétude du contenu et la capacité à faire fonctionner le site restauré sans intervention manuelle oubliée. Un site qui redémarre mais dont le certificat, les redirections ou les tâches planifiées manquent n'est pas vraiment restauré.
La restauration partielle, elle, se teste à chaque changement de configuration : récupérer un fichier effacé par erreur, une table vidée par une mauvaise requête, une version d'un article d'avant la modification. C'est ce type de restauration qui sert au quotidien, et c'est celui que les procédures oublient le plus souvent.
Trois copies, deux supports, une hors site
La règle communément retenue tient en trois nombres : trois copies des données, sur deux supports différents, dont une hors du site principal. Elle protège à la fois de la panne matérielle, de l'erreur humaine et de l'incident qui touche une salle entière. Une sauvegarde sur le même serveur ne satisfait aucun des trois nombres.
La copie hors site mérite une attention particulière depuis la généralisation des rançongiciels : elle doit être inaccessible en écriture depuis le serveur qu'elle protège. Un espace de sauvegarde monté en permanence sur la machine compromise est effacé avec elle. La déconnexion, manuelle ou planifiée, n'est pas un détail d'exploitation, c'est la condition qui rend la copie utile.
Ce qu'un hébergement doit écrire noir sur blanc
Trois engagements suffisent à distinguer un hébergement sérieux : la fréquence des sauvegardes et la durée de conservation, la date et le résultat de la dernière restauration testée, et la possibilité de récupérer une copie complète en partant, sans passer par une demande commerciale. Ce dernier point est le plus révélateur : une sauvegarde que le client ne peut pas emporter n'est pas une protection, c'est une retenue.
Ces éléments se demandent avant la signature, et se consignent. Un prestataire qui répond par une promesse de disponibilité plutôt que par une date de test répond à côté de la question. La disponibilité se mesure en service rendu ; la sauvegarde se mesure en restauration réussie.
La question à poser avant de compter dessus
La question utile n'est pas de savoir si des sauvegardes existent, mais quand elles ont servi pour la dernière fois. Si la réponse est une date, elle vaut un contrat. Si la réponse est un engagement de principe, la protection reste à démontrer, et le jour où elle sera nécessaire sera celui où il sera trop tard pour la tester.