COMPRENDRE. CHOISIR. PROFITER.MOINS DE BRUIT. PLUS DE REPÈRES.
Cloud & Infrastructure/Guide

Snapshot ou sauvegarde : ce qui compte, c’est la restauration

Comprendre ce que protège une copie, vérifier son indépendance et préparer un véritable exercice de restauration.

LA RÉPONSE UTILE

Un snapshot peut faire partie d’une stratégie de sauvegarde, mais son nom ne garantit ni l’indépendance de la copie ni la capacité de reprise. Vérifiez ce qui est copié, où la copie se trouve et comment la restaurer.

  • Comparez les mécanismes réels, pas seulement les noms.
  • Une copie inaccessible après un incident ne suffit pas.
  • Testez la restauration dans un environnement séparé.

Derrière les mots, des mécanismes différents

Les fournisseurs emploient les termes selon leurs propres produits. DigitalOcean décrit par exemple ses snapshots comme des images disque à la demande, et ses backups comme un mécanisme de sauvegarde automatique pour les Droplets. Il faut lire la documentation de l’offre retenue plutôt que transposer ces définitions partout.

La question pratique reste la même : qu’obtiendrez-vous après restauration ? Un disque, une machine complète, une base cohérente ou seulement certains fichiers ? Une jolie interface de sauvegarde n’apporte pas cette réponse à votre place.

Partir de trois incidents

Nous proposons trois scénarios pour examiner votre dispositif. Il s’agit d’une méthode de préparation, pas d’un audit de sécurité exhaustif.

  • Vous supprimez un fichier et ne vous en apercevez que plusieurs jours après. Quelle version pouvez-vous récupérer ?
  • La machine ne démarre plus. Avez-vous toutes les données et la configuration nécessaires pour reconstruire le service ?
  • Votre compte principal devient inaccessible. Pouvez-vous atteindre une copie et ses éventuelles clés autrement ?

Les informations à noter

Conservez une fiche courte avec le périmètre, la fréquence, la rétention, les accès nécessaires, l’emplacement et la procédure de restauration. Ajoutez la date du dernier essai et ce qui a réellement été récupéré.

ÉlémentCe qu’il faut préciser
PérimètreFichiers, bases, configuration, secrets nécessaires à la reprise
VersionPoint de reprise disponible et historique conservé
IndépendanceDépendances au compte, à la machine ou au stockage d’origine
RestaurationÉtapes, accès, clés et vérifications fonctionnelles

Un exercice sans toucher à la production

Restaurez une copie sur une destination isolée. Vérifiez d’abord la présence des données, puis ouvrez l’application ou les fichiers essentiels. Comparez quelques éléments connus et documentez les écarts. L’objectif n’est pas de cocher « restauration terminée », mais de vérifier que le service est utilisable.

Ne recopiez pas automatiquement des secrets ou des données personnelles dans un environnement moins protégé. Définissez les accès et nettoyez l’environnement de test selon votre politique après l’exercice. Pour un service critique, faites valider le protocole par la personne responsable.

Les quatre questions qui changent le diagnostic

Combien de travail accepteriez-vous de perdre ? Combien de temps pourriez-vous rester sans le service ? Qui détient les accès nécessaires ? Que se passe-t-il si le même incident touche le système principal et sa copie ? Répondez sans jargon avant de regarder les options du fournisseur.

Ces réponses fixent des objectifs à confronter à la solution, pas des résultats déjà obtenus. Une copie disponible ne garantit pas que votre application redémarrera dans le délai souhaité. C’est l’exercice de restauration qui vous donnera une observation, avec ses conditions et ses limites.

Une fiche de reprise, pas une promesse

Pour un petit site, nous préparerions une fiche avec la liste des éléments indispensables, l’emplacement des copies, la procédure et les vérifications finales. Les mots de passe et clés n’ont pas leur place dans cette fiche partagée : indiquez la procédure d’accès au gestionnaire de secrets, pas les secrets eux-mêmes.

Le carnet de restauration à remplir permet de consigner l’essai, la copie utilisée et le résultat observé. Une case « succès » doit être accompagnée de ce qui a été vérifié : ouverture des fichiers, présence des dernières données attendues, accès à l’application ou autre critère concret.

Ce que nous regarderions après l’exercice

Le temps passé à retrouver les accès est-il plus long que la restauration ? Des fichiers manquent-ils à l’inventaire ? L’application dépend-elle d’un service externe que vous aviez oublié ? Notez ces découvertes pendant l’essai. Elles sont souvent plus utiles que le simple temps total.

Corrigez ensuite une faiblesse précise, puis refaites le contrôle correspondant. N’attendez pas une migration majeure pour remettre la fiche à jour. Notre comparaison VPS et hébergement managé complète cette démarche en clarifiant qui s’occupe de quoi.

Ce qu’il faut retenir

Un snapshot n’est pas inutile parce qu’il porte ce nom, et une offre appelée « backup » n’est pas suffisante par définition. La robustesse vient de l’adéquation aux incidents que vous préparez et de la preuve que vous pouvez restaurer.

Avant d’acheter une option, demandez un exemple de reprise et son périmètre. C’est une question plus productive que « avez-vous des sauvegardes ? ».