Deux outils qui n'ont pas la même promesse
Un snapshot fige l'état d'un disque à un instant donné pour pouvoir y revenir vite. Une sauvegarde copie les données ailleurs, avec un historique, pour pouvoir reconstruire après une perte. Les deux mots circulent comme des synonymes dans les panneaux d'hébergement, et c'est là que naît le malentendu : le bouton snapshot rassure, alors qu'il ne répond qu'à une partie des sinistres.
Pour une agence qui héberge des sites clients sur des VPS, la nuance a un coût direct. Le jour où une machine disparaît, le client ne demande pas si un snapshot existait : il demande quand son site revient et avec quelles données. Cet article donne un critère simple pour choisir, VPS par VPS, entre retour arrière et reconstruction, puis une façon de l'écrire dans le contrat.
Ce qu'un snapshot fait très bien
- Retour arrière en quelques minutes — avant une montée de version, un changement de configuration ou une migration, revenir à l'état précédent est rapide.
- Point de repère daté — on sait exactement à quel instant on revient, ce qui simplifie le diagnostic après un incident.
- Aucune reconstruction à mener — la machine repart telle qu'elle était, réglages système compris.
- Geste accessible — un clic ou une commande dans le panneau, sans outil à installer ni dépôt à configurer.
- Adapté aux essais — tester une mise à jour sur le site d'un client en gardant une sortie de secours.
- Utile avant une intervention humaine — une fausse manipulation d'administration se rattrape sans passer par une restauration longue.
L'objection : « j'ai déjà des snapshots »
Un snapshot vit le plus souvent chez le même fournisseur, sur le même stockage et sous le même compte que la machine. Il partage donc ses pannes. Si la VM est supprimée, par erreur ou à la suite d'un impayé, les snapshots rattachés peuvent disparaître avec elle selon les fournisseurs. Si le compte hébergeur est compromis, la personne qui y entre peut supprimer la machine et ses snapshots d'un seul geste. Si le stockage sous-jacent a un incident, la copie et l'original tombent ensemble.
Deux limites s'ajoutent. Un snapshot est cohérent au niveau du disque, pas au niveau de l'application : une base de données en pleine écriture peut y figurer dans un état inachevé. Et un snapshot n'est jamais une preuve de restauration : tant qu'on ne l'a pas relu, c'est une hypothèse.
Contre-objection honnête : rien de tout cela ne rend le snapshot inutile. Il reste l'outil le plus rapide pour revenir en arrière avant une opération risquée. Il ne faut pas le jeter, il faut cesser de lui demander ce qu'il ne sait pas faire.
Snapshot et sauvegarde hors machine, critère par critère
Faites défiler le tableau
| Critère | Snapshot | Sauvegarde hors machine |
|---|---|---|
| Emplacement | Le plus souvent chez le même fournisseur, sur le même stockage | Hors du fournisseur de la VM, sur un stockage distinct |
| Survie à la suppression de la VM | Variable : selon l'offre, il peut disparaître avec la machine | Oui, la copie existe indépendamment de la machine |
| Survie à la compromission du compte hébergeur | Non, mêmes identifiants que la VM | Oui, si les accès au dépôt sont séparés de ceux du compte hébergeur |
| Cohérence applicative | Cohérence du disque seulement | Possible avec un export applicatif réalisé avant la copie |
| Durée de conservation | Courte, souvent quelques points récents | Longue, avec un historique et une rétention choisie |
| Vitesse de retour arrière | Très rapide | Plus lente : il faut recopier les données |
| Chiffrement avant transfert | Rarement sous votre contrôle | Possible, avec une clé que vous conservez |
| Preuve de restauration | Aucune tant qu'on n'a pas testé | Aucune tant qu'on n'a pas testé, d'où le test planifié |
Cohérence applicative : le piège de la base de données
Copier un disque pendant qu'une base écrit revient à photographier une page en train d'être tournée. Le système de fichiers est sain, mais la base peut contenir une transaction à moitié écrite, et elle se rétablira parfois après une phase de récupération, parfois pas. La parade consiste à produire un export cohérent de la base avant le snapshot ou avant la copie, puis à l'inclure dans ce qui est sauvegardé.
Pour PostgreSQL, la commande documentée est pg_dump, qui produit un export cohérent même pendant que la base sert des requêtes. Pour MySQL et MariaDB avec des tables InnoDB, mysqldump --single-transaction lit un état cohérent sans bloquer les écritures. Dans les deux cas, le fichier d'export rejoint la sauvegarde, et c'est lui que vous restaurez d'abord. Ce point vaut autant pour un snapshot que pour une copie de fichiers : le disque seul ne garantit rien sur l'état logique de la base.
Quatre sinistres, quatre protections
Faites défiler le tableau
| Sinistre | Ce qui protège | Pourquoi |
|---|---|---|
| Une mise à jour casse le système | Un snapshot pris juste avant | Retour arrière rapide vers un état connu |
| Un fichier ou une table supprimé par erreur, découvert plusieurs jours après | Une sauvegarde avec historique | Le snapshot récent contient déjà l'erreur : il faut un point plus ancien |
| VM supprimée ou compte hébergeur compromis | Une sauvegarde hors fournisseur | La copie ne dépend ni de la machine ni du compte |
| Corruption silencieuse découverte tard | Une sauvegarde à rétention longue | Il faut remonter avant la date où les données ont commencé à se dégrader |
La règle de décision en une phrase
Snapshot : retour arrière court avant une opération risquée. Sauvegarde : capacité de reconstruire après la perte de la machine ou du compte.
Si la question est « peut-on annuler dans l'heure ce qui va être fait », le snapshot répond. Si la question est « que reste-t-il si cette machine ou ce compte n'existent plus demain », seule la sauvegarde hors machine répond. Un VPS client sérieux a donc les deux, avec des rôles qui ne se recouvrent pas.
Les deux ne s'opposent pas. Le snapshot se pose avant l'intervention et se supprime une fois le résultat validé, alors que la sauvegarde tourne selon un calendrier fixe, sans que personne ait besoin de la déclencher à la main. Confondre ces rythmes est la source de la plupart des mauvaises surprises : un snapshot oublié pendant des semaines occupe de l'espace sans protéger de grand-chose, tandis qu'une sauvegarde déclenchée seulement avant les gros travaux laisse des trous dans l'historique.
Appliquer la règle à chaque VPS client
Inventorier les VPS et ce qu'ils portent
Pour chaque machine, notez les sites, les bases de données, les fichiers téléversés et le niveau de criticité pour le client.
Fixer la perte de données acceptable
Demandez combien d'heures de données le client peut perdre. Cette valeur est le RPO : elle dicte la fréquence de la sauvegarde.
Fixer le délai de reprise acceptable
Demandez combien de temps le site peut rester hors ligne. Cette valeur est le RTO : elle dicte la méthode de reconstruction.
Placer la sauvegarde hors du fournisseur de la VM
Utilisez un stockage distinct, avec des identifiants distincts de ceux du compte hébergeur, et chiffrez avant l'envoi avec une clé que vous conservez.
Ajouter l'export de la base avant chaque copie
Lancez
pg_dumpoumysqldump --single-transactionselon le moteur, et incluez le fichier produit dans le jeu sauvegardé.Réserver le snapshot aux opérations risquées
Prenez un snapshot avant chaque montée de version ou changement majeur, puis supprimez-le une fois le résultat validé.
Tester la restauration : sans test, une hypothèse
Une sauvegarde jamais restaurée en test n'est qu'une hypothèse. La différence entre snapshot et sauvegarde se joue aussi sur la preuve : seul un exercice de restauration chronométré dit si le site repart et en combien de temps.
Notre guide sur la procédure de test de restauration pour une agence détaille l'exercice trimestriel sur un VPS jetable, la mesure du RTO et du RPO constatés, et le journal à remettre au client. Nous ne le redécrivons pas ici. Retenez le principe : planifier le test, le dater, et corriger ce qu'il révèle, qu'il s'agisse d'accès manquants, de secrets absents ou d'une version logicielle différente.
Pour la mise en œuvre d'un outil, le guide sur la stratégie 3-2-1 avec Restic et S3 résume en un paragraphe ce qu'un snapshot d'hébergeur ne garantit pas, puis montre une sauvegarde hors fournisseur en pratique. Cet article-ci reste volontairement conceptuel : il sert à décider, pas à installer.
Écrire la règle dans le contrat
Le contrat d'une agence gagne à dire ce qui est protégé, par quel mécanisme et avec quel objectif, plutôt que promettre « des sauvegardes ». Trois éléments suffisent : le RPO, c'est-à-dire la perte de données maximale acceptée ; le RTO, c'est-à-dire le délai de remise en service visé ; et le mécanisme qui tient ces deux valeurs.
Exemple fictif, à adapter et à ne pas copier tel quel : « Les données du site sont copiées chaque nuit vers un stockage situé hors de l'hébergeur de la machine, avec une conservation de plusieurs mois. Le prestataire s'engage sur un RPO de 24 heures et un RTO de 8 heures après la décision de restaurer. Un snapshot est pris avant chaque mise à jour majeure et supprimé après validation. Une restauration de test est réalisée chaque trimestre et son journal est remis au client. »
Ces chiffres sont inventés pour l'illustration. Les vôtres doivent résulter de vos mesures de restauration, pas d'une intention.
Avant l'opération risquée : snapshot et sauvegarde vérifiée
Avant une montée de version, prenez le snapshot, mais vérifiez aussi que la dernière sauvegarde hors machine est récente et lisible. Le snapshot sert si l'opération échoue vite. La sauvegarde sert si le problème apparaît trois jours plus tard, quand le snapshot a déjà été supprimé.
Une politique par client, et ce que ServOrbit met à portée
Une agence peut tenir sa politique de sauvegarde dans un tableau : une ligne par client, avec le RPO, le RTO, le mécanisme et la date du dernier test.
Côté hébergement web, les sauvegardes sont hebdomadaires en entrée de gamme, quotidiennes sur l'offre Pro et sur toutes les offres revendeur, avec une sauvegarde quotidienne premium disponible en option. Pour un VPS, la présence et les conditions des snapshots dépendent de l'offre de votre fournisseur : vérifiez dans la documentation du panneau avant de les inscrire dans un contrat, et ne les comptez jamais comme votre seule copie.
