Un snapshot n'est pas une sauvegarde : la confusion qui coûte des données

Snapshot, réplication, sauvegarde : trois mécanismes qu'on croit interchangeables et qui protègent contre des risques différents. Ce que chacun couvre réellement, et ce qu'aucun ne couvre.

« J'ai des snapshots quotidiens, je suis couvert. » Cette phrase précède un nombre remarquable de pertes de données définitives. Elle n'est pas absurde — les snapshots sont utiles, rapides, et sauvent régulièrement la mise. Elle repose simplement sur une erreur de nature.

Ce qu'un snapshot est réellement

Un snapshot ne copie rien. Il pose un point de référence dans le volume et déclare : à partir de maintenant, toute modification est conservée à côté plutôt que d'écraser l'existant. C'est pour cela qu'il est instantané et qu'il ne coûte presque pas d'espace au départ.

La conséquence est directe : le snapshot vit dans le volume qu'il photographie. Si le disque tombe, si la grappe de stockage est perdue, si le système de fichiers se corrompt, le snapshot disparaît avec le reste. Il ne peut pas vous sauver d'un problème qui affecte son propre support.

Un snapshot répond parfaitement à une question précise : « comment revenir à l'état d'il y a deux heures, avant cette mise à jour ratée ? » Il ne répond pas du tout à : « le serveur a brûlé, comment récupérer mes données ? »

La réplication : le second malentendu

Vient alors l'objection : « je réplique vers un second serveur, donc j'ai bien une copie ailleurs. » C'est exact, et cela ne résout pas le problème.

Une réplication est conçue pour être fidèle. Elle recopie l'état de la source, y compris ses erreurs. Vous supprimez un répertoire par mégarde, la suppression est répliquée. Un rançongiciel chiffre vos fichiers, le chiffrement est répliqué — parfois avant même que vous n'ayez remarqué quoi que ce soit.

La distinction est nette :

  • La réplication protège contre la panne matérielle. C'est de la disponibilité.
  • La sauvegarde protège contre l'erreur et la malveillance. C'est de la récupérabilité.

Les deux sont légitimes. Aucune ne remplace l'autre.

Ce qui fait qu'une copie est une sauvegarde

Trois propriétés, et il les faut toutes les trois :

Un support distinct. La copie doit survivre à la destruction complète de l'original — autre machine, autre bâtiment, autre fournisseur. Une copie sur un second disque de la même machine ne survit ni à un incendie, ni à une surtension, ni à un compte administrateur compromis.

Une rétention indépendante. Si la suppression d'un fichier source entraîne sa disparition de la copie au prochain cycle, ce n'est pas une sauvegarde : c'est une synchronisation. Il faut conserver des versions antérieures, sur une profondeur qui dépasse le délai de détection d'un problème. Une corruption remarquée au bout de trois semaines n'est récupérable que si la rétention dépasse trois semaines.

Une restauration testée. Une sauvegarde jamais restaurée est une hypothèse, pas une garantie. C'est la propriété la plus négligée, et de loin.

Le cas du rançongiciel

C'est le scénario qui départage brutalement les stratégies, parce que l'attaquant ne se contente plus de chiffrer : il cherche d'abord vos moyens de restauration.

Snapshots supprimés, copies fantômes effacées, serveur de sauvegarde atteint avec les identifiants trouvés sur la machine compromise. Si votre serveur de sauvegarde est joignable depuis la machine infectée avec des droits d'écriture et un mot de passe partagé, il est compromis lui aussi.

Ce qui résiste réellement se résume à trois formes :

  • Une copie physiquement déconnectée — un disque externe rangé dans un tiroir reste imbattable pour un homelab.
  • Une copie distante avec des identifiants distincts, que la machine sauvegardée ne possède pas.
  • Une copie en écriture unique, que même un compte administrateur ne peut pas altérer avant l'expiration de la rétention.

Le piège du snapshot qui s'éternise

Dernier point, contre-intuitif : garder un snapshot longtemps ne rend pas plus sûr, cela dégrade.

Un snapshot retient tous les blocs modifiés depuis sa création. Plus il vieillit, plus il occupe d'espace — parfois jusqu'à saturer le volume, ce qui provoque un incident bien plus grave que celui contre lequel on croyait se protéger. Sur certains systèmes de fichiers, la fragmentation induite dégrade aussi les écritures.

Un snapshot est un filet à court terme : quelques heures, quelques jours. Au-delà, c'est le travail de la sauvegarde.

La formulation qui évite l'erreur

Pour chaque mécanisme en place, posez une seule question : « de quoi ceci me protège-t-il, et de quoi ne me protège-t-il pas ? »

Le snapshot protège de vos erreurs récentes, pas de la perte du support. La réplication protège de la panne matérielle, pas de vos erreurs. La sauvegarde protège des deux, à condition d'être distincte, versionnée — et restaurable.

Questions fréquentes

Quelle est la différence exacte entre un snapshot et une sauvegarde ?
Un snapshot fige l'état d'un volume à un instant donné, en ne conservant que les différences ultérieures. Il vit dans le volume qu'il photographie et en partage le sort. Une sauvegarde est une copie des données sur un support distinct, qui survit à la destruction complète de l'original. Le snapshot est quasi instantané et ne coûte presque rien ; la sauvegarde prend du temps et de l'espace. Ce coût, c'est exactement ce que vous payez pour l'indépendance.
Un snapshot me protège-t-il d'un rançongiciel ?
Parfois, et c'est ce « parfois » qui est dangereux. Si le rançongiciel chiffre seulement les fichiers, un snapshot antérieur permet de revenir en arrière. Mais les rançongiciels modernes cherchent activement les mécanismes de restauration et suppriment snapshots et copies fantômes avant de chiffrer. Un compte administrateur compromis peut détruire tous les snapshots en une commande. Seule une copie hors de portée de la machine compromise — déconnectée, distante avec des identifiants distincts, ou en écriture unique — offre une garantie réelle.
La réplication vers un second serveur suffit-elle ?
Non, et c'est le piège le plus courant en homelab. La réplication est conçue pour être fidèle : elle recopie tout, y compris vos erreurs. Une suppression accidentelle ou un chiffrement malveillant est répliqué sur la cible, souvent en quelques minutes. La réplication protège contre la panne matérielle — c'est de la disponibilité. Elle ne protège pas contre l'erreur humaine ni contre la malveillance : ça, c'est de la sauvegarde. Les deux sont utiles, ils ne se remplacent pas.
Combien de temps faut-il garder un snapshot ?
Le moins longtemps possible. Un snapshot conserve tous les blocs modifiés depuis sa création : plus il vieillit, plus il occupe d'espace, et sur certains systèmes de fichiers la fragmentation induite dégrade les performances en écriture. Une rétention courte — quelques heures à quelques jours — couvre l'usage réel du snapshot : annuler une mise à jour ratée ou une fausse manipulation récente. Au-delà, c'est le rôle de la sauvegarde, pas du snapshot.
Un snapshot d'une base de données est-il exploitable ?
Pas automatiquement. Un snapshot capture l'état du disque, pas celui de la mémoire : les transactions en cours et les écritures encore en cache n'y figurent pas. Selon le moteur, vous obtenez au mieux un état équivalent à une coupure de courant, dont la reprise nécessite un rejeu du journal, au pire des fichiers incohérents. Pour une base, il faut soit un vidage logique par les outils du moteur, soit une mise en attente des écritures pendant la prise du snapshot.

Cet article vous a plu ?

Commentaires

Morgann Riu

Expert en cybersécurité et administration Linux. J'aide les entreprises à sécuriser et optimiser leurs infrastructures critiques.

Retour au blog

Checklist Sécurité Linux

30 points essentiels pour sécuriser un serveur Linux. Recevez aussi les nouveaux tutoriels par email.

Pas de spam. Désabonnement en 1 clic.