Un thème mal codé qui corrompt des options, une mauvaise manipulation en base directement depuis phpMyAdmin, une extension qui modifie en masse des métadonnées : dans tous ces scénarios, la seule échappatoire fiable est une copie antérieure des données, prise avant l’incident.
mysqldump, l’outil de référence
La commande historique pour produire cette copie reste mysqldump, qui génère un fichier SQL rejouable tel quel sur une autre installation. WP-CLI propose une enveloppe plus pratique autour de cet outil, wp db export, qui reprend automatiquement les identifiants définis dans wp-config.php sans avoir à les ressaisir.
Exemple
wp db export sauvegarde-$(date +%Y%m%d).sql
mysqldump -u utilisateur -p wordpress > sauvegarde.sql
Bon à savoir
- Une sauvegarde de base seule ne suffit jamais à restaurer un site complet : les fichiers de la médiathèque et le thème actif vivent sur le disque, hors de la base de données.
- Sur une table volumineuse utilisant InnoDB, l’option
--single-transactiondemysqldumppermet une sauvegarde cohérente sans verrouiller les écritures en cours, contrairement à un export brut. - Tester réellement une restauration sur un environnement de recyclage reste la seule façon de vérifier qu’une sauvegarde est exploitable : un fichier généré sans erreur n’est pas une garantie suffisante.
- Automatiser cette copie via une tâche planifiée du serveur, distincte du WP-Cron interne à WordPress, garantit qu’elle continue de s’exécuter même si le site reçoit peu de visites pendant plusieurs jours.