Snapshots et sauvegardes : deux mécanismes, deux protections
Un instantané de disque et une sauvegarde ne protègent pas des mêmes incidents, et les confondre coûte cher le jour où il faut revenir en arrière. Ce site est indépendant : il n'est ni partenaire, ni mandataire, ni revendeur d'OVH SAS, et les conditions de l'hébergeur citées ici sont celles de son contrat, pas un engagement du site. Voici ce que chaque mécanisme couvre réellement, du fichier effacé par erreur à la panne de zone, et pourquoi seule une restauration testée transforme une copie en sauvegarde.
Un instantané fige un volume, une sauvegarde transporte des données
Un instantané, ou snapshot, est une image d'un volume de stockage prise à un instant précis. Le mécanisme laisse la machine continuer à écrire : les blocs modifiés après la prise sont conservés séparément, ce qui permet de revenir à l'état figé. La copie reste attachée à la machine et à l'infrastructure qui l'ont produite. Une sauvegarde est autre chose : un ensemble de données lisible sans la machine d'origine, que l'on peut restaurer ailleurs, sur un autre disque, dans un autre centre.
La documentation publique de l'hébergeur le dit sans détour : un instantané sert à sécuriser un système qui fonctionne avant une modification risquée, mais il ne constitue pas une stratégie de sauvegarde complète. Sur un serveur dédié, il n'existe d'ailleurs pas d'hyperviseur pour le prendre ; l'espace de sauvegarde attaché à l'offre, lui, ne sauvegarde rien de lui-même, il fournit de l'espace et des protocoles d'accès. Ce que le contrat précise ensuite varie d'une offre à l'autre.
Les deux objets ne répondent donc pas à la même question. L'instantané répond à « comment revenir à l'état d'il y a deux heures ». La sauvegarde répond à « comment retrouver ces données si le serveur, le compte ou la salle n'existent plus ». Un contrat qui promet « des sauvegardes » sans dire laquelle des deux mécaniques est décrite laisse le client seul juge le jour de l'incident. C'est la première question à poser, avant toutes les autres.
Ce que chacun protège, incident par incident
L'erreur de manipulation est le terrain de l'instantané. Une mise à jour qui casse un service, une suppression de répertoire, une table vidée par une requête mal écrite : le retour arrière prend quelques minutes et ne demande aucun autre support. Encore faut-il s'en apercevoir avant que l'instantané ne soit remplacé. Sur certaines offres, un seul instantané peut exister à la fois, et la restauration le consomme : il ne reste alors aucune copie de l'état précédent.
Le rançongiciel et la suspension de compte changent de camp. L'ANSSI rappelle qu'un attaquant cherche souvent à chiffrer ou à effacer l'infrastructure de sauvegarde pour empêcher la reconstruction. Un instantané stocké dans le même compte, avec les mêmes identifiants, tombe avec la production. Une suspension pour impayé, un litige ou un compte compromis produit le même effet : l'accès à l'instantané disparaît avec l'accès au compte ; ce qu'il advient des copies relève alors du contrat, pas de la documentation publique.
Restent la panne et la corruption. Une panne de disque se traite par le matériel et la redondance, pas par une copie. Une panne de zone, elle, emporte tout ce qui est stocké dans cette zone, y compris une copie dite distante si elle reste chez le même fournisseur et dans la même région. Enfin, une corruption silencieuse, base abîmée par une migration ou par une application fautive, se propage aux copies suivantes : seule une rétention assez longue permet de remonter avant la cause.
Une base en cours d'exécution ne se copie pas comme un fichier
Copier les fichiers d'un moteur de base de données pendant qu'il travaille ne produit pas une copie cohérente. Le moteur écrit dans son cache, journalise, réorganise ses pages : le fichier lu à un instant et celui lu trois secondes plus tard ne racontent pas la même transaction. Le résultat ressemble à une coupure de courant. Il peut redémarrer, il peut aussi refuser de démarrer ou perdre les dernières écritures. Un instantané de volume a exactement la même limite : il fige des blocs, pas la mémoire du moteur.
PostgreSQL documente l'approche qui tient : une copie de base accompagnée de l'archivage continu des journaux de transactions permet de rejouer l'activité jusqu'à un instant précis, y compris juste avant une erreur. La documentation précise que la copie de départ n'a pas besoin d'être parfaitement cohérente, puisque le rejeu corrige les incohérences. Un export logique comme pg_dump donne une photographie cohérente même sous charge, mais il ne contient pas de quoi rejouer les journaux.
Côté MySQL, l'option de transaction unique d'un export logique donne l'état cohérent au moment où la transaction s'ouvre, sans bloquer les applications, à condition que les tables soient transactionnelles. Verrouiller les tables base par base ne garantit rien entre deux bases. Pour revenir à un instant précis, il faut conserver les journaux binaires et l'instant de départ de l'export. La méthode retenue doit être écrite : sans elle, personne ne sait ce que la copie contient réellement.
La rétention décide de ce qui existe encore le jour de l'incident
La rétention n'est pas un réglage d'administration, c'est une décision. L'ANSSI demande de la déduire de deux valeurs définies avec le métier : la perte de données maximale admissible et la durée maximale d'interruption admissible. Autrement dit, combien d'heures de travail peut-on perdre, et combien de temps peut-on rester arrêté. Une copie toutes les heures ne sert à rien si le besoin réel est de retrouver l'état d'il y a trois semaines.
Le temps joue contre les copies courtes. Une intrusion par rançongiciel est souvent découverte plusieurs jours ou plusieurs semaines après l'entrée, quand le chiffrement commence. Une rétention de vingt-quatre heures ne contient alors que des données déjà compromises. C'est pourquoi l'ANSSI décrit une répartition par générations : sauvegardes journalières sur quelques semaines, mensuelles sur un an, annuelles sur plusieurs années. Le nombre de générations compte plus que la fréquence des prises.
Cette rétention doit figurer au contrat, pas seulement dans l'interface. Combien de générations, pendant combien de temps, qui peut supprimer une copie, et ce qu'il advient des copies à la fin du contrat, point central de la réversibilité. Un instantané unique, écrasé à chaque prise, n'est pas une rétention : c'est une annulation possible. La question à poser est écrite, et la réponse doit l'être aussi, sinon la rétention reste une intention.
Hors site ne suffit pas : il faut sortir du compte
La règle dite 3-2-1 tient en une phrase : trois copies distinctes, dont les données en production et deux sauvegardes, sur deux supports différents, dont une hors ligne. L'ANSSI la présente comme une recommandation forte et ajoute qu'une copie hors ligne reste indispensable, même moins fréquente que les copies locales. La CNIL reprend la même règle pour les entreprises, avec des tests de restauration réguliers. Une copie qui vit dans le même compte que la production ne compte pas comme une copie séparée.
Externaliser change la nature du risque, pas seulement la distance. L'ANSSI décrit les points de vigilance quand la sauvegarde part chez un tiers : la réplication interne du fournisseur peut recopier une copie compromise, la localisation des données doit être connue, le débit et le délai de restitution doivent tenir dans la durée d'interruption admise. Elle recommande de chiffrer avec un moyen propre avant l'envoi, et rappelle qu'une copie hors ligne reste plus robuste qu'un stockage immuable en ligne.
En pratique, trois vérifications suffisent à rendre la copie réellement hors de portée. Un compte ou un fournisseur distinct, avec des identifiants que la production ne connaît pas. Des droits en écriture seule pour la tâche de sauvegarde, et aucun droit de suppression. Une clé de chiffrement conservée ailleurs que sur le serveur, sinon la copie existe mais reste illisible. Ces trois points se testent : on essaie de supprimer une copie depuis la production, et on regarde ce qui se passe.
Une sauvegarde non testée est une hypothèse
Une copie qui n'a jamais été restaurée n'est pas une sauvegarde : c'est une hypothèse sur le contenu d'un fichier. Les défauts n'apparaissent qu'au moment du retour : la clé de chiffrement manquante, la version du moteur qui a changé entre-temps, l'export tronqué par un disque plein, la tâche qui rendait un code de succès sans rien écrire, la chaîne incrémentale dont le premier élément a été purgé. La copie existe. La restauration, non.
Le test se fait ailleurs que sur la production : une autre machine, un autre réseau, un volume jetable. On y restaure, on ouvre l'application, on compte ce qui manque, on mesure la durée et on la compare à la durée d'interruption admise. Le compte rendu porte une date et un nom. L'ANSSI demande que les sauvegardes soient testées régulièrement et qu'une procédure de restauration soit rédigée puis appliquée. Un changement d'outil, de version ou de fournisseur invalide le test précédent.
Reste l'avertissement. Restaurer un instantané sur le volume de production écrase les données en place, et sur certaines offres la restauration consomme l'instantané : il faut donc copier avant, et prévenir. Une restauration lancée en pleine journée de travail crée un second incident. Et une copie restaurée peut contenir ce que l'attaquant y a laissé : l'ANSSI rappelle qu'une restauration n'est pas un nettoyage. La preuve, au bout du compte, est un rapport de restauration daté.