Table of Contents
- 1. Exporter la base de données
- 2. Archiver les fichiers utiles
- 3. Sortir une copie du serveur
- 4. Tester une vraie restauration
- 5. Noter le contexte technique
- La règle qui évite les mauvaises surprises
Une mise à jour de plugin se termine sur une page blanche. Le tableau de bord ne répond plus et la boutique doit rouvrir dans quelques minutes. Dans cette situation, une sauvegarde récente ne suffit pas. Il faut savoir exactement ce qu'elle contient et comment la restaurer.
Voici une procédure volontairement simple, sans extension payante. Elle utilise WP-CLI et les outils disponibles sur la plupart des hébergements Linux.
1. Exporter la base de données #
La base contient les articles, les réglages, les utilisateurs et une grande partie de la configuration des extensions.
1wp db export backup-$(date +%Y%m%d-%H%M).sql
Vérifiez immédiatement que le fichier existe et qu'il n'est pas vide.
1ls -lh backup-*.sql
2head -n 5 backup-*.sql
La présence d'instructions SQL dans les premières lignes confirme que l'export a réellement produit des données.
2. Archiver les fichiers utiles #
Le cœur de WordPress peut être téléchargé à nouveau. Les éléments difficiles à reconstruire sont surtout wp-content, la configuration et les règles du serveur.
1tar czf backup-files-$(date +%Y%m%d-%H%M).tar.gz \
2 wp-content wp-config.php .htaccess
Contrôlez ensuite le contenu de l'archive sans l'extraire.
1tar tzf backup-files-*.tar.gz | head -n 20
Sur une installation Nginx, le fichier .htaccess n'existe généralement pas. Retirez-le simplement de la commande et conservez séparément la configuration du virtual host si vous y avez accès.
3. Sortir une copie du serveur #
Une sauvegarde stockée uniquement à côté du site disparaît avec lui en cas de panne du disque, de suppression du compte ou de compromission complète.
Copiez les deux archives vers une seconde destination. Un ordinateur local, un stockage objet ou un autre serveur conviennent. Le point important est l'indépendance vis-à-vis de l'hébergement principal.
Gardez au minimum trois générations. Si un fichier malveillant est resté discret pendant plusieurs jours, la sauvegarde de la veille peut déjà être contaminée.
4. Tester une vraie restauration #
Une sauvegarde jamais restaurée reste une hypothèse. Montez un environnement temporaire, placez-y une installation WordPress propre, puis importez la base.
1wp db import backup-20260801-1200.sql
Extrayez ensuite les fichiers.
1tar xzf backup-files-20260801-1200.tar.gz
Adaptez les URL si le domaine de test diffère.
1wp search-replace 'https://exemple.com' 'https://test.exemple.net' \
2 --all-tables --skip-columns=guid
Ouvrez la page d'accueil, une publication, la médiathèque et l'administration. Vérifiez aussi les formulaires et les tâches planifiées importantes.
5. Noter le contexte technique #
Ajoutez un petit fichier texte à chaque sauvegarde avec les versions actives.
1wp core version
2wp plugin list
3wp theme list
4php -v
Cette trace évite de restaurer un ancien site dans un environnement devenu incompatible. Elle accélère aussi le diagnostic quand la panne apparaît juste après une montée de version PHP.
La règle qui évite les mauvaises surprises #
La bonne séquence tient en quatre verbes : exporter, vérifier, copier, restaurer. Elle prend quelques minutes et transforme une mise à jour risquée en opération réversible.
Pour automatiser cette routine avec une tâche cron et une politique de rétention, le guide complet est disponible sur WP Admin Lab.
Publié par l'équipe WP Admin Lab.