Sauvegarde UpdraftPlus ou BackWPup déjà infectée

La dernière n'est pas la saine

L'infection a souvent plusieurs semaines. Updraft a fait son travail : il a photographié le site déjà habité, chaque nuit. « La plus récente » est la plus complète, et la plus sale. C'est le réflexe qui explique la moitié des « on a restauré, ça a recommencé à 6 h ».

BackWPup, All-in-One, les backups cPanel, les snapshots d'hébergeur : même logique. L'outil n'est pas en cause. La date l'est. On remonte jusqu'à un point où les fichiers extraits correspondent encore aux zips officiels, et où `uploads` n'exécute rien.

Une restauration n'est pas un nettoyage. C'est un voyage dans le temps. Si le temps choisi contient la porte, vous voyagez avec elle. Les premiers gestes demandent une copie de l'état actuel — distincte de « remettre la dernière sauvegarde ».

Ouvrir l'archive avant de la pousser

Téléchargez le zip (ou les zips fractionnés) hors prod. Poids de `index.php`, de `wp-load.php`, présence de PHP dans `uploads`, dossiers à noms aléatoires, `mu-plugins` inconnus, `.htaccess` hors norme. Comparez un cœur au zip WordPress de la même version.

Si l'archive est un dump SQL seul : cherchez des users admin incongrus, des options `siteurl`, des posts de masse. Ne l'importez pas « pour voir » sur la prod. Un import est une écriture.

Les archives chiffrées ou stockées chez Updraft « remote » : téléchargez, ouvrez, même rituel. Le nuage n'a pas lu le PHP pour vous.

• PHP dans `uploads` ou à la racine, hors cœur.
• `index.php` beaucoup plus lourd que l'officiel.
• Plugins que vous n'avez jamais installés.

Remonter, comparer, ne pas empiler

Prenez un point à J-7, J-21, J-45 selon la chronologie de vos symptômes (premier titre japonais, premier mail d'abus). Ouvrez, comparez. Dès qu'un point est propre sur les fichiers, notez-le. Vous n'êtes pas obligé de le restaurer en entier : il sert de référence pour récupérer un thème, un contenu, une liste de plugins légitimes.

Empiler trois restaurations « on essaie » sur la prod détruit les journaux et mélange les bases. Une copie figée de l'infecté actuel + des archives lues à côté, c'est la méthode. La prod attend.

HPOS / Woo : une vieille table de commandes n'est pas un cadeau. WooCommerce et tables.

La sauvegarde est sur le même compte

Un dossier `/updraft` ou `/backups` dans le home, accessible en PHP ou en HTTP, se chiffre avec le rançongiciel, se télécharge avec le reste, se réinfecte avec le voisin. Ce n'est pas un filet. C'est une copie locale du problème.

Après incident, ces dossiers se ferment (plus de listing, plus d'exécution, idéalement plus d'HTTP). Les prochaines sauvegardes partent ailleurs : autre compte, autre fournisseur, rétention que l'attaquant du panel A n'a pas.

Sauvegardes hors serveur : le critère n'est pas « Updraft est payé ». C'est « un accès au site ne donne pas les archives ».

Cloud, Drive, et le zip déjà lu

Si le panel ou un `.env` a fuité, les tokens Drive / S3 d'Updraft aussi. Partez du principe que les archives distantes ont pu être lues. Elles restent utiles comme historique de fichiers ; elles ne sont plus secrètes. Tournez les tokens. Relisez les partages « anyone with the link ».

Un bucket public qui liste les backups est un `.env` / secrets cousin : on ferme le listing, on tourne, on ne fait pas comme si le cloud isolait par magie.

BackWPup vers FTP : le mot de passe FTP du remote se tourne. S'il était le même que la prod, vous avez la démonstration du même secret partout.

Restaurer quoi, une fois un point propre trouvé

Souvent : contenus et médias légitimes, pas le `wp-content/plugins` entier, pas les mu-plugins, pas la racine. On réinstalle cœur et extensions depuis les officiels, on réimporte les contenus sains, on rejoue les commandes depuis un export, pas depuis une table douteuse.

Une restauration « full site » du point propre, puis re-téléchargement de tout ce qui a été créé après (articles, commandes) à la main ou par export ciblé, est plus longue à expliquer et plus sûre qu'un full de la nuit dernière.

Refermez l'entrée avant de rerendre public. Restaurer un 1.6 ou un plugin abandonné « propre de 2021 » remet une porte connue. Le point propre n'est pas un cœur maintenu.

Après : sauvegardes hors serveur, testées

Une sauvegarde que personne n'a jamais extraite n'existe pas. Une fois par trimestre, ouvrez un zip sur une machine morte, pas en prod. Vérifiez qu'il se décompresse et que `index.php` a le bon poids.

Rétention : assez loin pour dépasser la date d'une infection lente (6 à 12 semaines n'est pas du luxe). Trop de copies sur le même FTP, si.

Updraft et BackWPup peuvent rester, une fois le site propre, avec une destination que le PHP de prod n'administre pas seul. Filet, pas totem.

Quand aucune archive n'est propre

Alors on ne restaure pas. On nettoie l'état actuel par comparaison aux officiels, on accepte de perdre ce qui n'existe que dans le sale, on reconstruit le minimum. C'est plus honnête qu'un voyage vers 2022.

Un prestataire qui « restaure quand même, on verra » vend un second incident. Relisez le devis.

Vous pouvez nous envoyer un échantillon d'archive (pas toute la base clients en clair par mail). Nous dirons si elle est utilisable comme référence. Souvent, une partie l'est : médias, pas PHP.