Sauvegarder WordPress et tester la restauration : la méthode pas à pas

Le problème : une sauvegarde que personne n’a jamais restaurée

Presque tous les sites WordPress sont « sauvegardés » : par l’hébergeur, par une extension, parfois par les deux. Mais le jour où il faut revenir en arrière (mise à jour qui casse, piratage, erreur de manipulation), on découvre souvent la vraie question : cette sauvegarde se restaure-t-elle, et en combien de temps ? Une archive incomplète, une base exportée à part et jamais conservée, un fichier chiffré dont personne n’a la clé… autant de cas où la sauvegarde existait sur le papier seulement.

Dans la méthode de mise à jour en six étapes, je recommandais de vérifier la sauvegarde avant toute mise à jour. Voici la suite pratique : ce qu’il faut sauvegarder, où le ranger, et surtout comment tester une restauration sans risque pour le site en ligne.

Les prérequis

• Un accès administrateur à WordPress et un accès à l’hébergement (gestionnaire de fichiers ou SFTP, phpMyAdmin ou équivalent).
• Idéalement un accès SSH avec WP-CLI : les commandes ci-dessous l’utilisent, mais chaque étape a un équivalent par interface.
• Un espace pour la copie de test : un sous-domaine protégé par mot de passe, un environnement de préproduction proposé par l’hébergeur, ou un environnement local.
• Une base de données vide pour cette copie, avec son propre utilisateur.

1. Lister ce qu’il faut sauvegarder

La documentation WordPress distingue deux ensembles qui ne vivent pas au même endroit. Sauvegarder le dossier du site ne sauvegarde pas la base de données, et inversement.

Élément	Contenu	Pourquoi c’est indispensable
Base de données	Contenus, pages, commentaires, réglages, utilisateurs, données des extensions	Sans elle, le site restauré est vide
wp-content/uploads	Images et documents envoyés	Souvent le dossier le plus lourd, parfois exclu par erreur
wp-content/themes et plugins	Thème (et thème enfant), extensions, y compris celles développées sur mesure	Les extensions sur mesure ne se retéléchargent nulle part
wp-config.php et .htaccess	Paramètres de connexion, clés de sécurité, règles de réécriture	Petits fichiers, mais oubliés très souvent
Cœur WordPress	Fichiers de WordPress lui-même	Retéléchargeable, mais pratique pour restaurer à l’identique

2. Choisir la fréquence, le nombre de copies et les emplacements

La page officielle « Backups » propose un rythme simple : chaque semaine pour un petit site peu actif, chaque jour pour un site très actif, et toujours avant une mise à jour ou un déménagement. Elle conseille de conserver au moins 3 à 5 sauvegardes récentes et de les répartir entre plusieurs lieux : le serveur de l’hébergeur, un stockage en ligne et un poste local, par exemple.

Le point clé : au moins une copie doit se trouver hors de l’hébergeur. Si le compte d’hébergement est suspendu, piraté ou supprimé, les sauvegardes stockées au même endroit disparaissent avec lui.

3. Produire un jeu de sauvegarde cohérent

La documentation recommande de créer l’export de la base et la copie des fichiers au même moment, et de les ranger ensemble. Avec WP-CLI, depuis le dossier WordPress :

cd /chemin/vers/wordpress
mkdir -p ../sauvegardes
wp db export ../sauvegardes/base-$(date +%F).sql
tar -czf ../sauvegardes/fichiers-$(date +%F).tar.gz .

Sans argument, wp db export nomme le fichier d’après la base, la date et un identifiant aléatoire ; ici, je fixe le nom pour retrouver facilement les deux moitiés du même jeu. Sans SSH, l’onglet Exporter de phpMyAdmin produit le même fichier SQL, et le gestionnaire de fichiers de l’hébergeur permet de compresser le dossier. Pensez ensuite à rapatrier ces deux fichiers vers votre stockage externe.

4. Restaurer sur une copie isolée

Le test se fait ailleurs que sur le site en ligne. L’ordre officiel de restauration est l’inverse de la sauvegarde : d’abord les fichiers, puis la base.

Fichiers et configuration

Décompressez l’archive dans le dossier de la copie, puis ouvrez wp-config.php pour y mettre les identifiants de la base vide (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST). Ajoutez deux réglages documentés qui évitent à la copie d’agir comme le vrai site :

define( 'WP_ENVIRONMENT_TYPE', 'staging' );
define( 'DISABLE_WP_CRON', true );

Le premier signale aux extensions qui en tiennent compte qu’il s’agit d’une préproduction ; le second désactive les tâches planifiées de WordPress (publications programmées, envois automatiques, synchronisations). Si une extension envoie des e-mails ou parle à un service externe (paiement, CRM, newsletter), désactivez-la sur la copie dès qu’elle est accessible.

Base de données et adresse du site

wp db import ../sauvegardes/base-2026-11-04.sql
wp search-replace 'https://www.exemple.fr' 'https://test.exemple.fr' --skip-columns=guid --dry-run
wp search-replace 'https://www.exemple.fr' 'https://test.exemple.fr' --skip-columns=guid

wp search-replace remplace l’ancienne adresse dans toute la base en respectant les données sérialisées, que les remplacements « à la main » abîment. Lancez-le d’abord avec --dry-run pour lire le rapport sans rien modifier. L’option --skip-columns=guid suit la consigne de la documentation sur les déménagements : ne jamais modifier la colonne GUID. Enfin, dans Réglages > Lecture, cochez « Demander aux moteurs de recherche de ne pas indexer ce site ».

5. Vérifier que la restauration est vraiment complète

1. Connexion à l’administration avec un compte existant.
2. Dernier article ou dernière page publiés avant la date de la sauvegarde : présents.
3. Images de la médiathèque : affichées (un carré vide signale souvent un dossier uploads incomplet).
4. Formulaires, menus, widgets, pages clés : à l’identique, sans erreur PHP.
5. Outils > Santé du site : pas de nouveau problème critique.
6. Durée totale de l’opération notée : c’est votre temps de remise en service réaliste.

Exemple : un site vitrine avec formulaire de devis

Prenons un cabinet de conseil fictif : un site vitrine WordPress d’une trentaine de pages, un formulaire de devis et quelques centaines d’images. L’hébergeur fait une sauvegarde quotidienne, et une extension envoie chaque semaine une archive vers un stockage en ligne.

Le test de restauration sur un sous-domaine protégé se déroule en trois temps : décompression de l’archive de l’extension, import de la base, remplacement de l’adresse. Imaginons que les pages s’affichent, mais que les images récentes manquent : l’extension excluait les fichiers au-delà d’une certaine taille. Sans test, ce trou serait resté invisible jusqu’au jour de la panne. La correction (réglage d’exclusion modifié, nouvelle sauvegarde, nouveau test) prend une demi-heure, et la fiche de restauration note désormais ce point de contrôle.

Les erreurs fréquentes

• Sauvegarder les fichiers et oublier la base (ou l’inverse) : le site restauré est vide ou sans thème.
• Tout stocker chez l’hébergeur : un seul incident de compte suffit à tout perdre.
• Tester sur le site en ligne : une restauration écrase la base actuelle, avec les commandes ou messages reçus depuis.
• Remplacer l’adresse avec un simple « rechercher-remplacer » SQL : les données sérialisées des thèmes et extensions se corrompent.
• Laisser la copie active : e-mails envoyés à de vrais clients, tâches planifiées exécutées deux fois, copie indexée par les moteurs.

Vous voulez une routine de sauvegarde vérifiée, avec un test de restauration documenté pour votre site ? Je peux mettre en place et tester ce dispositif avec vous, dans le cadre de mon offre de développement et maintenance WordPress. Décrivez-moi votre site : hébergement, extensions et contraintes, et je vous propose une approche adaptée.

Questions fréquentes

La sauvegarde de mon hébergeur ne suffit-elle pas ?

Elle est utile, mais elle reste stockée chez l’hébergeur et sa durée de conservation est souvent courte. Vérifiez ce qu’elle contient (base comprise ?), combien de jours elle remonte, et gardez au moins une copie hors de l’hébergeur.

À quelle fréquence tester la restauration ?

Il n’existe pas de règle officielle. Un test après chaque changement d’hébergeur, d’extension de sauvegarde ou de structure du site, et au minimum une ou deux fois par an, est un bon point de départ.

Et pour un réseau multisite ?

Le principe est le même, mais le remplacement d’adresse concerne toutes les tables du réseau : wp search-replace ne traite que le site courant sans l’option --network. Testez avec --dry-run avant toute modification.