Sauvegardes hors du serveur : le point qui décide de la reprise
Une sauvegarde sur le même compte se chiffre, se corrompt ou se retélécharge avec le site. La règle 3-2-1 n'est pas un slogan : c'est la différence entre une reprise d'un jour et trois semaines d'archéologie. Après un piratage, on vérifie *où* vivent les copies, pas seulement « on a Updraft ».
Une sauvegarde sur le même compte se chiffre ou se corrompt avec le site. 3-2-1 n'est pas un slogan : c'est la différence entre un jour et trois semaines.
Ce que « hors serveur » veut dire
Un autre *compte*, une autre *machine*, idéalement un autre *prestataire* que l'hébergeur web. Un dossier `/backup` sur le même FTP, c'est le même incident. Un bucket S3 / un Drive / un NAS de bureau dont *seul* le site a la clé trop large, c'est mieux — encore faut-il que l'attaquant n'ait pas cette clé dans `wp-config`.
« Hors serveur » n'est pas « dans le zip Updraft téléchargeable en HTTP ». C'est l'inverse d'une exfiltration offerte. Sortez ces zips du webroot *aujourd'hui*.
L'objectif : pouvoir reconstruire si le compte brûle (rançon, suspension, formatage host).
Le 3-2-1 en TPE, sans nuage de mots
Trois copies (prod + 2), deux supports différents, une hors site (vraiment). Pour une vitrine : quotidien distant + hebdo sur un disque. Pour une boutique : plus fréquent, plus de rétention de *base*. Le fichier seul sans SQL, ou le SQL sans `uploads`, n'est pas une reprise.
Vous n'avez pas besoin d'un poster NASA. Vous avez besoin que *une* copie survive à un compte host compromis. C'est le minimum après ce que vous venez de vivre.
La troisième copie sert aussi quand la deuxième est déjà infectée (rétention : J-14 propre vs J-1 sale).
- Au moins une copie l'attaquant n'atteint pas avec le FTP du site.
- Fichiers *et* base.
- Plusieurs dates, pas un seul « latest ».
Updraft, cPanel, et le piège du zip web
Updraft vers Google Drive / S3 avec une clé *restreinte* : correct s'il tourne. Updraft qui écrit dans `wp-content/updraft` public : une porte et une fuite. cPanel « backup » stocké *sur* le compte : utile à l'host, insuffisant contre un ransomware de compte, souvent déjà sale.
Les backups host « gratuits » ont une rétention courte et un délai de restauration. Demandez la politique *avant* le prochain incident. Hébergeur : ce n'est pas votre plan de reprise, c'est le leur.
Un plugin backup abandonné est une surface. Moins de plugins, un flux distant fiable.
La copie d'incident n'est pas un backup métier
Le zip *infecté* du jour J est une preuve et un filet pour comparer. On ne s'en sert pas pour « remettre en ligne vite ». On le stocke à part, label « forensique ». Les logs voyagent avec.
Confondre les deux, c'est restaurer la porte en croyant restaurer la boutique. Le guide backdoor et les 48 h sont pleins de ce geste.
Nommez clairement : `prod-clean-2026-04-01` vs `incident-raw-2026-04-12`.
Tester une restauration, vraiment
Une fois par trimestre : un sous-domaine ou une machine jetable, restore, login admin, une commande test. Si ça échoue *maintenant*, ça échouera le jour J. Notez la durée réelle (souvent plus que le slide).
Vérifiez que la copie « propre » n'embarque pas déjà un admin fantôme. Lire, pas seulement copier.
Qui sait le faire si vous êtes absents ? Une ligne dans le contrat de maintenance.
Rétention, chiffrement, accès
Rétention : assez pour remonter *avant* la fenêtre d'intrusion (souvent 14–30 jours min, plus si vous le pouvez). Chiffrement des archives distantes : utile ; la clé n'habite pas le même `wp-config`. Accès : nominatif, 2FA sur le Drive / S3, pas la boîte partagée `backup@`.
Les archives sont des données. Un Drive ouvert, c'est une fuite latente. Durée et destinataires dans le registre.
Révoquez les clés de backup dans la même liste que les API après incident.
Après l'incident : sale vs propre
On remonte jusqu'à un point *lu* propre, on réapplique les contenus légitimes ensuite — pas « latest » par défaut. On *arrête* les jobs qui écrasent le distant avec l'état encore infecté (vous contamineriez le filet). Pause, puis job depuis un état validé.
Une fois propre : nouvelle chaîne de backups, nouvelles clés, ancien canal considéré compromis.
Si vous n'aviez rien : commencez le soir où le site est tenu, pas « un jour ». L'incident a fixé le prix de l'absence.
Écrire ça dans le contrat
Qui lance, où ça atterrit, qui teste, qui paie le stockage, comment vous récupérez si l'agence part. Sans ça, vous découvrirez que les backups étaient « sur leur Dropbox perso ».
L'assureur aime cette clause. L'exclusion « pas de sauvegarde » est fréquente. Une copie distante datée est une pièce, pas une option marketing.
Le nettoyage en cours peut se déclarer. Le plan 3-2-1, c'est vous + maintenance, à froid, après.
- Hors compte web, plusieurs dates.
- Pause des jobs sales, puis chaîne neuve.
- Un test de restore par trimestre.