Suite à une fausse manip j’ai supprimé quelques milliers d’articles d’un de mes sites. Comme je savais que mes manipulations étaient dangereuses, j’ai bien sur procédé auparavant à un SQL Dump de tout le site. Problème : quand j’ai tenté une restauration du dump via phpMyAdmin : gros plantage. Comment résoudre ce problème ? On vous explique c’est très simple.
« Désactivez » votre site WordPress avant toute restauration
Un préambule pas du tout intuitif à une restauration de votre site est … de le rendre totalement inactif.
Si vous le laissez tourner d’une façon ou d’une autre pendant votre restauration, des écritures seront générées en base de donnée et votre restauration va planter à cause de l’overlap (des conflits d’écritures liés aux index primaires de certaines tables).
Le plus simple consiste donc à renommer temporairement vos fichiers .htaccess et wp-config.php pour « planter » complètement le site.
Vous les renommerez correctement une fois la restauration terminée.
Supprimez carrément toutes les tables WordPress
Oui ça fait peur, et non tout autre bricolage se soldera par des problèmes sans fin …
Augmentez les délais de traitement PHP
Si comme moi vous avez une base de 800 Mo de données et que vous utilisez un pauvre petit hébergement mutualisé, il y a fort à parier que vous rencontrerez un timeout : l’opération de restauration sera interrompue en plein milieu par le serveur car « trop longue ».
Dans les réglages PHP de votre serveur vous avez généralement par défaut :
- max_execution_time = 360 (6 minutes)
- max_input_time = 360 (6 minutes)
Dans ma situation, 6 loooongues minutes n’ont pas suffi.
Augmentez ces réglages comme un cochon avec pourquoi pas un bon gros 10000, vous les remettrez ensuite à leur bonne valeur.
Lancez votre restauration
C’est bon vous pouvez lancer la restauration de votre Dump. Le plus simple consiste d’ailleurs à faire glisser directement votre fichier vers la fenêtre dans laquelle est ouverte phpMyAdmin.
C’est dégueu ta méthode !
Il existe évidemment des façons plus propres de faire une restauration totale de base de données WordPress … quand on a accès la console SSH du serveur, ce qui n’était pas mon cas ici.
Après avoir tenté plusieurs stratégies différentes (upload de certaines bases seulement avec renommages, split de mon gros dump en petits fichiers, ré-install de WordPress avec vidage des tables et écrasements, etc.) les 3 étapes ci-dessus sont celles qui ont le mieux fonctionné.
Bon courage en tous cas, les problèmes de restauration et de backup étant toujours assez stressants …
- SQL poche pour les Nuls, 4e édition
- SQL – Les fondamentaux du langage (avec exercices et corrigés) – (4e édition)
