Sauvegarde et plan de reprise
PLAN DE REPRISE · CE PORTFOLIO
Une sauvegarde qu'on n'a jamais restaurée ne prouve rien. Ce site est sauvegardé chaque nuit, chiffré avant de quitter le serveur, conservé sur un second serveur dédié, et un seul script le remonte en entier sur n'importe quelle machine Linux. La restauration a été testée pour de vrai, sur la sauvegarde du jour.
Restauration testée le 3 novembre 2026 · site remonté et vérifiéEn un coup d'œil
Chaque nuit
Tout ce qui fait le site
La base de données, les fichiers (thème, extensions, médias) et la configuration. Le cache, qui se reconstruit tout seul, est exclu.
AES-256
Chiffré avant l'envoi
Les archives sont chiffrées sur le serveur de production. Le serveur de sauvegarde ne reçoit que des fichiers illisibles sans la phrase secrète, gardée hors des serveurs.
14 jours
Sur un serveur séparé
Un second serveur, dans un autre centre de données, dédié aux sauvegardes et sans aucun site public. Les copies de plus de 14 jours sont supprimées automatiquement.
Les deux procédures, étape par étape
Les sorties réelles
root@production:/opt/portfolio# ./backup.sh portfolio-db-2026-11-03.sql.gpg 100% 4723KB portfolio-env-2026-11-03.gpg 100% 226 portfolio-files-2026-11-03.tar.gz.gpg 100% 503MB backup portfolio 2026-11-03 OK
La première sauvegarde : trois fichiers chiffrés, envoyés en quelques secondes.
root@production:~# ./restore-portfolio.sh --test ==> 2/7 Récupération des sauvegardes Sauvegarde restaurée : 2026-11-03 ==> 3/7 Déchiffrement Préfixe des tables : wp_ ==> 5/7 Base de données Tables importées : 73 ==> 7/7 Contrôles Réponse de WordPress en local : HTTP 200 RÉPÉTITION RÉUSSIE Le site de production n'a pas été touché. root@production:~# curl -s 127.0.0.1:8089 | grep -o '<title>.*' <title>Home - Portfolio Nans SALVIA
La répétition de restauration : la sauvegarde du jour, remontée dans une copie jetable à côté du site en ligne.
Les choix, et pourquoi
- Chiffrer avant d'envoyerSi le serveur de sauvegarde était compromis, l'attaquant ne trouverait que des fichiers illisibles.
- Un serveur de sauvegarde isoléAucun site public dessus : une faille dans un site ne peut pas atteindre les sauvegardes.
- Une clé dédiéeLe transfert utilise une clé réservée aux sauvegardes, pas mes accès d'administration, et un compte sans mot de passe.
- La phrase secrète hors des serveursElle est aussi rangée dans un gestionnaire de mots de passe : perdre un serveur ne fait pas perdre les sauvegardes.
- Un seul script pour tout remonterDocker, base, fichiers, HTTPS et contrôles : la reprise ne dépend pas de ma mémoire le jour de la panne.
- Une répétition sans risqueLe mode test restaure dans une copie jetable à côté du vrai site, ou dans une machine virtuelle sur un portable.
Ce que je n'ai pas fait, volontairement : une bascule automatique vers un second serveur actif. Pour un portfolio, la remise en ligne par script suffit ; un serveur de secours public aurait aussi exposé le serveur qui garde les sauvegardes. Le choix est proportionné au besoin.