WordPress sauvegarde avant mise à jour : méthode sûre

Pour une WordPress sauvegarde avant mise à jour, faites une sauvegarde complète des fichiers et de la base de données, vérifiez qu’elle est lisible, puis testez la restauration sur une copie de travail. La méthode la plus sûre consiste à exporter la base avec WP CLI ou phpMyAdmin, archiver au minimum wp-content et wp-config.php, conserver une copie hors du serveur, puis mettre à jour un site de staging avant la production. Cette procédure réduit fortement le risque de perdre des articles, des réglages ou des fichiers personnalisés.

Une WordPress sauvegarde avant mise à jour est un point de retour daté. Elle ne remplace pas un staging ni un plan de restauration, mais elle permet d’annuler proprement une mise à jour de WordPress, d’un thème ou d’une extension. Voici une méthode reproductible pour un site mutualisé, un VPS et un environnement local.

Pourquoi sauvegarder WordPress avant chaque mise à jour

Une mise à jour modifie du code qui dialogue avec la base de données, le thème, les extensions et la version de PHP. La plupart des opérations se passent bien, mais une incompatibilité peut provoquer une erreur critique, une page blanche, une boucle de connexion ou une perte de fonctionnalité. Le risque est plus élevé quand plusieurs extensions sont mises à jour en même temps, car la cause devient difficile à isoler.

La sauvegarde doit être réalisée juste avant l’opération, et non plusieurs jours auparavant. Un export ancien peut ignorer des commandes, des inscriptions ou des réglages ajoutés depuis. Notez aussi la version de WordPress, de PHP, du thème et des extensions. Ces informations rendent le retour arrière plus fiable, car vous saurez exactement quel état restaurer.

# Relever les versions avant la mise à jour
wp core version --path=/var/www/html
wp plugin list --update=available --path=/var/www/html
php -v

# Enregistrer la liste complète des extensions
wp plugin list --format=csv --path=/var/www/html > plugins-avant-maj.csv

Une sauvegarde complète contient deux familles de données. Si une mise à jour provoque déjà une erreur critique, consultez aussi notre guide pour activer le mode debug WordPress afin de relever la cause avant de restaurer. La base SQL contient les articles, les pages, les utilisateurs, les réglages et les métadonnées. Les fichiers contiennent le thème, les extensions, les médias, les personnalisations et la configuration. Sauvegarder uniquement la base ne permet pas de récupérer un thème modifié. Sauvegarder uniquement les fichiers ne récupère pas les données publiées depuis le dernier export.

Faire l’inventaire du site avant l’export

Commencez par identifier le chemin réel de l’installation, la base utilisée et le dossier qui reçoit les médias. Sur un hébergement cPanel, WordPress se trouve souvent dans public_html, mais ce n’est pas une règle. Un mauvais chemin peut produire une archive vide tout en donnant l’impression que la commande a réussi.

Contrôlez l’espace disque disponible. Une archive de wp-content peut être volumineuse à cause des images, des caches et des anciennes sauvegardes. Ne placez pas la nouvelle archive dans un dossier qui est lui-même inclus sans limite dans l’archive, sinon sa taille peut augmenter à chaque exécution.

# Vérifier le chemin et l’espace disponible
pwd
du -sh /var/www/html/wp-content
df -h

# Identifier les dossiers volumineux
du -sh /var/www/html/wp-content/* 2>/dev/null | sort -h | tail -10

Excluez les caches recréables si l’hébergement manque d’espace, mais conservez les uploads, le thème actif, les extensions et les fichiers de configuration. Ne supprimez rien avant la mise à jour. Si une extension stocke des données dans un dossier particulier, cherchez sa documentation ou incluez tout wp-content par défaut.

Exporter la base de données avec WP CLI

WP CLI est la méthode la plus pratique quand vous avez un accès SSH. L’export crée un fichier SQL que vous pouvez compresser, contrôler et importer sur un autre environnement. Utilisez un nom horodaté, afin de ne pas écraser la sauvegarde précédente et de retrouver immédiatement le bon état.

#!/usr/bin/env bash
set -euo pipefail

SITE=/var/www/html
BACKUP=/var/backups/wordpress/$(date +%Y%m%d-%H%M%S)
mkdir -p "$BACKUP"

wp db export "$BACKUP/database.sql" --add-drop-table --path="$SITE"
gzip -9 "$BACKUP/database.sql"
sha256sum "$BACKUP/database.sql.gz" > "$BACKUP/database.sql.gz.sha256"

echo "Export créé dans $BACKUP"

L’option --add-drop-table facilite une restauration propre dans une base de test, car les tables existantes sont supprimées avant leur recréation. Protégez le dossier de sauvegarde contre la lecture web. Si le répertoire se trouve sous la racine publique, ajoutez une règle serveur appropriée ou déplacez l’archive hors de public_html.

Vous pouvez aussi utiliser phpMyAdmin sur un hébergement mutualisé. Si votre export échoue avec une erreur de connexion, notre diagnostic de mysql server has gone away dans WordPress aide à distinguer la base, le serveur et le script. Sélectionnez la bonne base, choisissez l’export personnalisé, activez la création des tables et téléchargez le fichier SQL. Vérifiez le préfixe des tables dans wp-config.php, surtout après une migration. Un export de la mauvaise base peut être parfaitement valide, mais inutilisable pour votre site.

# Vérifier une archive SQL compressée
gzip -t database.sql.gz
zcat database.sql.gz | head -20
ls -lh database.sql.gz

Archiver les fichiers WordPress sans oublier wp-content

Les fichiers les plus importants sont wp-content, wp-config.php et les éventuelles règles .htaccess ou configurations propres au serveur. Le noyau WordPress peut être téléchargé à nouveau, mais le thème, les extensions et les médias ne sont pas toujours récupérables ailleurs. Sauvegardez donc ces éléments avant toute mise à jour.

#!/usr/bin/env bash
set -euo pipefail

SITE=/var/www/html
OUT=/var/backups/wordpress/$(date +%Y%m%d-%H%M%S)
mkdir -p "$OUT"

tar --create --gzip --file="$OUT/wp-files.tar.gz" 
  --exclude='wp-content/cache' 
  --exclude='wp-content/*/cache' 
  -C "$SITE" wp-content wp-config.php .htaccess

sha256sum "$OUT/wp-files.tar.gz" > "$OUT/wp-files.tar.gz.sha256"
tar -tzf "$OUT/wp-files.tar.gz" | head -20

Les dossiers de cache sont généralement recréables, mais ne les excluez que si vous savez qu’ils ne contiennent pas une donnée métier. Certains outils utilisent un dossier personnalisé pour des rapports ou des fichiers générés. En cas de doute, incluez tout wp-content et nettoyez les caches dans une copie séparée.

Conserver une copie hors serveur avec la règle 3 2 1

Une sauvegarde laissée sur le même hébergement ne protège pas contre la suppression du compte, une compromission ou une panne du serveur. Appliquez la règle 3 2 1 : trois copies, deux supports distincts, dont une copie hors site. Pour un petit WordPress, cela peut être la copie de travail, une archive locale chiffrée et un stockage objet ou un second serveur.

Transférez uniquement les archives terminées et vérifiées. La commande suivante utilise Rclone, mais le principe reste identique avec un stockage S3 ou un serveur SFTP. Activez le chiffrement côté destination si des données personnelles ou des identifiants sont présents.

# Envoyer une archive vérifiée vers un stockage distant
sha256sum -c wp-files.tar.gz.sha256
rclone copy wp-files.tar.gz backup-distant:site-wordpress/ --immutable
rclone copy database.sql.gz backup-distant:site-wordpress/ --immutable

# Vérifier la présence distante
rclone lsl backup-distant:site-wordpress/

Conservez plusieurs générations. Une sauvegarde créée après une corruption peut reproduire le problème. Une rotation de sept sauvegardes quotidiennes et quatre sauvegardes hebdomadaires convient à de nombreux petits sites, mais une boutique ou un site éditorial très actif peut nécessiter une fréquence plus élevée.

Tester la restauration avant de mettre à jour

Une archive qui existe n’est pas nécessairement une sauvegarde exploitable. Testez au moins l’intégrité du fichier et, idéalement, restaurez-le dans un staging. Importez la base, décompressez les fichiers, adaptez les URLs et vérifiez l’accueil, la connexion, les formulaires, les médias et les fonctions propres au site.

# Exemple de restauration dans un environnement de test
mkdir staging-site
 tar -xzf wp-files.tar.gz -C staging-site
 gunzip -c database.sql.gz | wp db import - --path=staging-site
wp search-replace 'https://www.exemple.fr' 'https://staging.exemple.fr' 
  --skip-columns=guid --path=staging-site

Le test doit aussi confirmer que l’archive contient les bonnes versions. Comparez le nombre d’extensions, la présence du thème actif et quelques fichiers médias. Si le staging affiche une erreur PHP, corrigez la procédure avant la mise à jour de production. Cette étape est souvent plus utile qu’une simple vérification de taille.

Mettre à jour par étapes et contrôler le résultat

Une fois la sauvegarde vérifiée, mettez à jour une seule famille de composants à la fois. Commencez par les extensions, puis le thème et enfin le noyau si c’est l’ordre adapté à votre stratégie. Évitez le bouton qui applique quinze changements simultanément. Entre chaque étape, contrôlez les journaux et les pages principales.

# Vérifier les mises à jour disponibles
wp plugin update --all --dry-run --path=/var/www/html

# Mettre à jour une extension précise
wp plugin update nom-extension --path=/var/www/html

# Vérifier le noyau sans l’installer
wp core check-update --path=/var/www/html

Après chaque mise à jour, testez la page d’accueil, un article, la recherche, la connexion administrateur et les formulaires. Regardez aussi la console du navigateur et les journaux PHP. Si une erreur apparaît, notez l’extension modifiée en dernier et restaurez l’état précédent plutôt que d’ajouter des corrections improvisées.

Pour une mise à jour majeure, activez une fenêtre de maintenance courte et prévenez les personnes qui publient. Désactivez temporairement les tâches automatiques qui pourraient modifier la base pendant la restauration. Purgez ensuite les caches, puis vérifiez le site depuis un navigateur non connecté et un mobile.

Que faire si la mise à jour casse le site

Commencez par distinguer une panne du serveur, une erreur PHP et un problème de cache. Consultez les journaux, activez temporairement le journal de debug sans afficher les erreurs aux visiteurs et rappelez l’heure exacte de l’incident. Si une extension est responsable, désactivez-la avec WP CLI ou renommez son dossier par SSH.

# Désactiver une extension qui provoque une erreur
wp plugin deactivate nom-extension --path=/var/www/html

# Revenir à une version connue, si elle est disponible
wp plugin update nom-extension --version=1.2.3 --force --path=/var/www/html

# Contrôler l’état du noyau
wp core version --path=/var/www/html

Si la désactivation ne suffit pas, restaurez la base. Pour choisir le bon point de retour et récupérer une version antérieure, voyez notre guide sur comment revenir en arrière dans WordPress. et les fichiers depuis le même point daté. Ne mélangez pas une base récente avec des fichiers anciens sans comprendre les migrations effectuées par l’extension. Certaines versions ajoutent des tables ou modifient la structure des données. Une restauration cohérente évite ce type de décalage.

Après le retour arrière, protégez le site et planifiez un nouvel essai sur staging. Recherchez une version compatible, corrigez le conflit ou remplacez l’extension. Ne laissez pas une version vulnérable active indéfiniment : le retour arrière est une mesure temporaire, pas une stratégie de maintenance.

Checklist WordPress sauvegarde avant mise à jour

Avant de cliquer sur Mettre à jour, utilisez cette checklist courte. Elle est conçue pour éviter les oublis les plus coûteux.

  • Le site répond et les pages importantes ont été testées.
  • La version de WordPress, de PHP, du thème et des extensions est notée.
  • La base de données a été exportée et l’archive peut être ouverte.
  • wp-content, wp-config.php et les règles serveur sont archivés.
  • Les sommes de contrôle correspondent aux fichiers transférés.
  • Une copie hors serveur existe avec des accès séparés.
  • Le staging a été restauré ou un test de restauration récent est disponible.
  • Une fenêtre de contrôle et une procédure de retour arrière sont prévues.

Pour un site critique, ajoutez une sauvegarde avant chaque changement, une surveillance des erreurs et une restauration testée régulièrement. Le meilleur plan fonctionne quand personne ne se souvient plus de la commande exacte.

FAQ sur la sauvegarde WordPress avant mise à jour

Quelle sauvegarde faire avant une mise à jour WordPress ?

Faites une sauvegarde complète de la base de données et des fichiers, en particulier wp-content, wp-config.php et les règles serveur. Gardez une copie hors du serveur et vérifiez que les archives sont lisibles.

Faut-il sauvegarder WordPress avant chaque mise à jour ?

Oui, sauvegardez avant chaque mise à jour importante du noyau, du thème ou d’une extension. Une sauvegarde datée juste avant l’opération permet de revenir à l’état exact du site si une incompatibilité apparaît.

Comment restaurer WordPress après une mise à jour ratée ?

Restaurez la base et les fichiers depuis le même point de sauvegarde, puis purgez les caches et testez les pages principales. Si une extension est responsable, désactivez-la avant de relancer le site.

La sauvegarde WordPress doit-elle être stockée sur le même hébergement ?

Non, une copie sur le même serveur ne protège pas contre une panne ou une compromission de l’hébergement. Conservez au moins une copie hors site, idéalement chiffrée et protégée par un compte séparé.

Comment savoir si une sauvegarde WordPress fonctionne ?

Vérifiez son intégrité, sa taille et son contenu, puis restaurez-la dans un environnement de staging. Un test réel confirme que la base, les fichiers, les médias et les URLs peuvent être récupérés ensemble.

Sources et références

G
WP Admin Lab

Architecte web full-stack. WordPress, performance, data et sécurité. Notes de terrain, tests reproductibles et retours d'expérience.