Sauvegardes qui restaurent vraiment : le titre est volontairement sec. Les incidents WordPress, Woo, Presta, Symfony que je vois ont souvent une sauvegarde dans un dashboard, et une restauration qui échoue (fichier manquant, base d'un autre jour, plugin qui n'a pas tout pris, backup sur le même disque mort). Cet article pose ce qu'une sauvegarde utile contient, où elle vit, à quelle fréquence, comment la tester, et comment l'inscrire dans la TMA et le monitoring. Sans folklore d'outil.
🔎 Ce qu'il faut sauver, concrètement
Fichiers (code, uploads, .env), base, parfois volumes (médias hors WP). Une sauvegarde « fichiers seuls » sur WordPress est une demi-sauvegarde : sans la base, pas de contenus. Une base seule sans uploads, des pages sans images. Les deux, le même jour, le même run.
Les secrets : s'ils sont dans un coffre, le coffre se sauvegarde aussi. Un site restauré sans clés de paiement « marche » visuellement. Il n'encaisse plus.
🛠️ Où : pas sur le même disque que la prod
Un ransomware, un rm, un disque plein, un hébergeur qui ferme : la copie locale meurt avec la prod. On pousse hors site (autre région, autre compte). On chiffre. On ne laisse pas un bucket public « backup.zip ».
L'hébergeur « fait des snapshots » : bien. Demandez la rétention, le délai, si ça inclut la base, si vous pouvez restaurer sans attendre 48 h la réponse du support. Un snapshot que seul le support peut rejouer un jour ouvré n'est pas une TMA de boutique.
✅ Fréquence et rétention
Vitrine calme : quotidien plus quelques points hebdo. Boutique : plusieurs fois par jour sur la base, ou binlogs, selon le chiffre d'affaires. On garde assez pour revenir avant « le plugin d'il y a dix jours ». Trop de rétention sur le disque de prod, c'est l'incident disque plein (voir monitoring).
Les backups toutes les heures que personne ne purge sont une bombe. La rétention se dessine. Elle se paie en stockage. Elle se dit.
⚠️ Le test : restaurer pour de vrai
Trimestriel au minimum, mensuel si boutique. On restaure sur un clone, on démarre, on se connecte, on ouvre une commande, on voit une image. On chronomètre. On écrit : 40 minutes, telle étape a coincé. Ce texte est le runbook. Sans lui, la nuit d'incident est une découverte.
Un test « le fichier pèse 2 Go donc c'est bon » n'est pas un test. Les archives corrompues pèsent aussi 2 Go.
- Fichiers + base du même run
- Copie hors site chiffrée
- Rétention écrite, pas infinie sur la prod
- Restauration réelle chronométrée, runbook à jour
📌 Outils : l'hébergeur, le plugin, le snapshot, le dump
Peu importe tant que le test passe. Les plugins WordPress de backup remplissent parfois le disque local et ratent les gros sites. Les dumps SSH plus rsync, c'est laid et ça marche. Les snapshots de VM sont rapides et aveugles (on restaure tout, y compris le malware si on ne fait pas attention).
Je combine souvent : snapshot infra pour le crash serveur, plus dumps applicatifs pour le « revenir avant le plugin ». Un seul outil pour tout, rarement.
🧭 RGPD et données de clients
Les backups contiennent des personnes. On les protège, on les limite, on sait les expurger si une demande l'exige (c'est dur, on le dit). Une copie de test restaurée n'est pas publique. Voir « Tester un site WordPress en local et en préprod ».
Garder cinq ans de commandes en clair sur un FTP n'est pas de la prudence. C'est une fuite en attente.
💡 Dans le forfait TMA
Une ligne : sauvegarde, lieu, rétention, date de dernière restauration test. Si le prestataire ne peut pas donner la dernière date, vous n'avez pas de sauvegarde. Vous avez une case.
Sauvegardes qui restaurent vraiment : c'est le titre que je veux sur un contrat. Pas « backup quotidien inclus ». Les deux phrases n'ont pas le même prix. Elles n'ont pas le même sommeil.
🧪 Scénarios à jouer au moins une fois
Fichier corrompu (on restaure les uploads). Plugin qui casse (on restaure la veille). Serveur mort (on restaure ailleurs). Ransomware (on restaure une copie hors site, pas le snapshot déjà chiffré). Chaque scénario a un temps. Sauvegardes qui restaurent vraiment : celles dont on a joué au moins le premier et le troisième.
On n'attend pas le ransomware pour découvrir que le snapshot est dans la même région compromise. C'est banal. C'est encore oublié.
🔎 Qui a le droit de restaurer
Deux personnes, une procédure, un coffre. Un seul humain, et les vacances deviennent un risque. La TMA indépendante doit prévoir un relais (vous, un pair). Je le dis. Je le documente.
Restaurer n'est pas cliquer sur « Restaurer » dans un plugin. C'est décider jusqu'à quand on revient, prévenir les utilisateurs, rejouer les commandes perdues si boutique. Le runbook a ces phrases. Pas seulement l'URL du bucket.
Un backup jamais restauré n'est pas une sauvegarde. C'est une case.
