Presque tout le monde a quelque chose de configuré pour faire des sauvegardes. Le problème, c’est qu' »avoir une sauvegarde » et « pouvoir restaurer en moment critique » sont deux choses très différentes. Une sauvegarde qui n’a jamais été testée n’est pas une sauvegarde : c’est un espoir.
Le principe 3-2-1 est le point de départ : 3 copies, sur 2 supports différents, avec 1 copie hors site. Et à cela il faut ajouter ce qu’on dit rarement : les sauvegardes doivent être chiffrées, il doit y avoir une période de rétention définie, et la restauration doit être testée régulièrement — pas le jour où c’est nécessaire.
Je me charge de concevoir, d’implémenter et de maintenir la stratégie de sauvegarde de votre infrastructure, sans dépendre de ce que votre hébergeur propose comme sauvegarde incluse.
Problèmes courants
- La sauvegarde est sur le même serveur. Si le serveur tombe, le disque lâche ou un ransomware frappe, la sauvegarde disparaît avec. Une copie stockée au même endroit n’est pas une vraie sauvegarde.
- Les sauvegardes de l’hébergeur. Les backups inclus dans l’hébergement sont généralement sur la même infrastructure, avec une rétention courte et sans chiffrement. Ils fonctionnent pour les petites erreurs ; pour les vrais désastres, ce n’est pas suffisant.
- Pas de chiffrement. Les sauvegardes contiennent des données clients, des commandes, des identifiants. Les stocker en clair dans un bucket externe est à la fois un problème de sécurité et de conformité.
- Personne n’a jamais testé une restauration. La sauvegarde existe, mais le processus de restauration n’a jamais été exécuté dans des conditions réelles. Quand c’est urgentement nécessaire, c’est le pire moment pour découvrir que ça ne fonctionne pas.
- Rétention insuffisante. Une erreur qui passe inaperçue pendant plusieurs jours nécessite de pouvoir revenir à plus de 24 heures en arrière. Sans rétention suffisante, certains scénarios deviennent irrécupérables.
Comment je l’aborde
La conception de la stratégie part des besoins réels : ce qu’il faut protéger, à quelle fréquence les données changent, combien de temps on peut se permettre d’être sans service (RTO) et jusqu’à quel point dans le temps on peut récupérer (RPO). Il n’y a pas de solution identique pour tous les projets.
À partir de là, l’implémentation inclut l’automatisation, la vérification d’intégrité, la rotation des sauvegardes et la documentation du processus de restauration — ce qui compte vraiment quand il faut s’en servir.
Ce qui est inclus
Conception de la stratégie
- Définition du RPO (quelle perte de données vous pouvez vous permettre) et du RTO (en combien de temps vous devez être opérationnel).
- Identification de ce qu’il faut protéger : base de données, fichiers, configurations, volumes de données.
- Sélection des destinations externes : stockage cloud (S3, Backblaze B2, Hetzner Storage Box et autres), serveur de sauvegarde dédié ou offsite.
Implémentation
- Sauvegardes automatisées avec une fréquence adaptée au rythme de changement des données (horaire, quotidienne, hebdomadaire).
- Chiffrement des sauvegardes à la source avant de quitter le serveur (GPG, restic, duplicati et autres).
- Transfert sécurisé vers la destination externe avec vérification d’intégrité.
- Rotation et rétention configurées : copies quotidiennes, hebdomadaires et mensuelles selon le cas.
- Alertes si une sauvegarde échoue ou ne s’exécute pas dans la fenêtre attendue.
Vérification et tests
- Test de restauration périodique en environnement de staging pour confirmer que la sauvegarde est utilisable.
- Vérification automatique de l’intégrité des fichiers de sauvegarde.
- Documentation pas à pas du processus de restauration, pour que n’importe qui dans l’équipe puisse l’exécuter sous pression.
Parlons de la protection des données de votre infrastructure