Presque toute personne ayant administré un serveur a entendu ou vécu la même histoire : une commande mal tapée, une suppression dans le mauvais répertoire, un script de migration qui écrase la base de production — et des années de données disparaissent en quelques secondes. Ce qui sépare vraiment « la belle frayeur » de « la catastrophe », ce n'est jamais la chance, mais l'existence d'une sauvegarde exploitable.

Distinguer d'abord instantané et sauvegarde

Beaucoup pensent qu'activer les instantanés suffit ; en réalité les deux ne jouent pas le même rôle :

  • Instantané (Snapshot) : une image de toute la machine à un instant donné, rapide à restaurer, idéale comme « bouton d'annulation » avant une mise à niveau système ou une modification importante. Mais il réside généralement sur la même infrastructure que l'instance, avec une granularité trop grossière pour récupérer un fichier isolé.
  • Sauvegarde (Backup) : une copie au niveau des fichiers, stockable ailleurs, conservant plusieurs versions historiques — l'outil adapté contre la suppression accidentelle, la corruption et les rançongiciels.

Conclusion : il vous faut les deux, et l'un ne remplace pas l'autre.

La règle 3-2-1 reste le cadre le plus utile

  • 3 copies des données : la production plus deux sauvegardes.
  • 2 supports ou emplacements différents : ne conservez jamais la sauvegarde sur la même machine ni le même disque que la source.
  • 1 copie hors site : au moins une chez un autre fournisseur ou dans une autre région, pour qu'une défaillance unique ou un problème de compte n'emporte pas tout.

Comment procéder concrètement

  • Sauvegardez les bases de données de façon logique : copier le répertoire de données capture souvent un état incohérent. Exportez avec mysqldump, pg_dump ou équivalent, puis compressez l'archive.
  • Utilisez des outils de sauvegarde incrémentale : restic et borg prennent en charge la déduplication, l'incrémental et le chiffrement ; conserver longtemps de nombreuses versions y coûte bien moins d'espace qu'une copie complète quotidienne.
  • Automatisez avec une planification : cron ou un timer systemd, exécuté chaque jour. Les sauvegardes manuelles finissent immanquablement par être oubliées.
  • Chiffrez avant l'envoi hors site : les sauvegardes contiennent souvent des données utilisateurs et des identifiants ; chiffrez avant tout dépôt sur un stockage objet.
  • Définissez une politique de rétention : par exemple sept quotidiennes, quatre hebdomadaires, six mensuelles — pour que le stockage ne gonfle pas sans fin.
  • Surveillez la réussite des sauvegardes : une tâche planifiée qui échoue en silence est plus dangereuse que l'absence de sauvegarde, car vous vous croyez couvert. Mettez une alerte sur l'échec.

L'étape la plus importante : répéter la restauration

C'est celle que presque tout le monde saute et que personne ne devrait sauter. Une sauvegarde dont le chemin de restauration n'a jamais été testé n'est pas une sauvegarde. Une fois par trimestre, consacrez trente minutes à restaurer intégralement votre dernière sauvegarde sur une instance jetable : vérifiez que les données sont complètes, que le service démarre et que vous vous souvenez encore des étapes. Le jour où cela comptera vraiment, vous voudrez une procédure répétée, pas une pile d'archives que personne n'a jamais ouvertes.

SharkCloud prend en charge les instantanés d'instance et un dimensionnement souple : vous pouvez lancer à tout moment une instance temporaire pour un exercice de restauration — un faible prix pour la certitude de pouvoir réellement récupérer.