Des sauvegardes de sites qui vous sauvent vraiment : 7 règles pour des backups chiffrés et hors-site
La plupart des « sauvegardes » échouent précisément quand on en a besoin : même serveur, jamais testées, sans chiffrement. Voici sept règles pour des sauvegardes qui survivent à un vrai sinistre — et comment arrêter de les faire à la main.
Tout le monde a des sauvegardes — jusqu'au jour où il en a besoin. On découvre alors que la sauvegarde vivait sur le serveur qui vient de mourir, qu'elle ne tournait plus depuis trois semaines, ou qu'elle restaure un chaos inutilisable. Une sauvegarde que vous n'avez jamais testée n'est pas une sauvegarde ; c'est un espoir. Voici sept règles qui transforment l'espoir en quelque chose dont vous pouvez réellement vous remettre.
1. Automatisez — sinon ça n'arrivera pas
Une sauvegarde que vous devez penser à lancer est une sauvegarde qui s'arrête en silence. Planifiez-la. Quotidienne est un défaut raisonnable pour la plupart des sites ; les sites très actifs veulent des snapshots de base plus fréquents. La seule bonne cadence est celle à laquelle aucun humain n'a à penser.
2. Appliquez le 3-2-1
La règle classique tient toujours : 3 copies de vos données, sur 2 supports différents, dont 1 hors-site. Ça semble excessif jusqu'à ce qu'une seule panne — disque mort, mauvais déploiement, bucket supprimé — emporte tout ce qui était stocké au même endroit.
3. Sortez-la du serveur
C'est l'étape qu'on saute. Une sauvegarde posée sur le même VPS que le site meurt avec le VPS. Envoyez les sauvegardes vers du stockage objet — un bucket S3, Backblaze B2, ou une cible SFTP sur une autre machine. Le hors-site, c'est la différence entre « on a perdu un après-midi » et « on a perdu l'activité ».
4. Chiffrez avant l'envoi
Votre sauvegarde contient tout : base de données, données clients, secrets, configuration. Dès qu'elle quitte votre serveur, c'est une cible de choix. Chiffrez-la avant l'envoi (AES-256 est le standard), et stockez aussi les identifiants de stockage chiffrés. Une sauvegarde non chiffrée dans un bucket mal configuré est une fuite qui n'attend que d'arriver.
5. Sauvegardez la base et les fichiers
Une sauvegarde de fichiers seuls restaure un site qui ne peut pas joindre ses données ; une sauvegarde de base seule restaure des données sans site autour. Il vous faut les deux — uploads, config et code et la base — idéalement capturés au même moment pour rester cohérents.
6. Gardez des versions, pas seulement « la dernière »
Si votre seule sauvegarde est celle d'hier soir, alors un problème repéré une semaine trop tard — table corrompue, chiffrement silencieux par rançongiciel, mauvaise migration — est déjà dans votre sauvegarde. Gardez une fenêtre de rétention (par ex. quotidienne sur une semaine, hebdomadaire sur un mois) pour revenir avant les dégâts.
7. Testez vos restaurations
L'étape la plus zappée, et la seule qui prouve que le reste a fonctionné. Restaurez régulièrement une sauvegarde dans un endroit jetable et vérifiez que le site démarre vraiment. Une restauration jamais exécutée est un pile-ou-face le jour le plus difficile.
La façon simple
Fait à la main, c'est un empilement de bricolage fragile : une tâche cron, mysqldump, un tar, une étape gpg, un aws s3 cp, un script de rétention et un mode opératoire de restauration que personne n'a répété. C'est exactement le genre de chose qui pourrit en silence.
Un panel devrait simplement le faire. ShadowPanel exécute des sauvegardes planifiées et chiffrées en AES-256 de vos fichiers et bases directement vers votre propre cible S3 ou SFTP, conserve un historique avec rétention, stocke vos identifiants de stockage chiffrés au repos — et restaure n'importe quel snapshot en un clic. Vous obtenez les sept règles par défaut, au lieu d'un mode opératoire dont vous espérez qu'il marche encore.
Sauvegardez comme il faut
Palier gratuit — 3 sites, sans carte bancaire — et vous pouvez l'installer sur n'importe quel VPS Ubuntu en une dizaine de minutes :
curl -fsSL https://shadowpanel.de/install.sh | bash