Comment sauvegarder un site WordPress

Une sauvegarde complète de WordPress est une copie de deux éléments capturés ensemble : vos fichiers et votre base de données MySQL. Oublier l’un ou l’autre condamne la restauration à l’échec. Ce guide présente la méthode fiable depuis la ligne de commande — mysqldump, tar et une tâche cron qui transfère les archives hors site — afin que vous possédiez vos sauvegardes plutôt que de les louer à un plugin. Il couvre également les options proposées par les hébergeurs et les plugins de façon équilibrée, et présente les commandes de restauration qui prouvent qu’une sauvegarde fonctionne réellement.

Que contient une sauvegarde WordPress complète ?

Un site WordPress repose sur deux systèmes distincts, et une sauvegarde doit capturer les deux. Les fichiers comprennent le cœur de WordPress, tout ce qui se trouve sous wp-content — vos thèmes, plugins et le dossier uploads (généralement la partie la plus volumineuse) — ainsi que le fichier wp-config.php à la racine. Sur Apache, il faut également inclure .htaccess ; sur nginx ou Caddy, il n’y a pas de .htaccess à sauvegarder car les règles de réécriture se trouvent dans la configuration du serveur, en dehors de la racine web. La base de données est une base MySQL qui contient vos articles, pages, commentaires, utilisateurs, taxonomies, ainsi que tous les paramètres des plugins et des thèmes.

L’erreur la plus courante chez les débutants est de sauvegarder les fichiers via FTP en oubliant la base de données. Les thèmes et le cœur de WordPress peuvent être retéléchargés ; votre contenu, non. Si une « sauvegarde » ne contient que des fichiers, le site restauré s’affiche sans aucun article ni paramètre.

Quelles sont les trois façons de sauvegarder WordPress ?

Il existe trois approches pratiques, chacune offrant un compromis entre commodité et contrôle.

Les sauvegardes de l’hébergeur sont pratiques, mais ne doivent pas être votre seule copie — les fenêtres de rétention sont courtes, et si le serveur est compromis ou tombe en panne, les sauvegardes qui y sont stockées peuvent disparaître avec lui. Les plugins tels qu’UpdraftPlus gèrent la planification et l’envoi vers le cloud depuis le tableau de bord et constituent un choix raisonnable pour les utilisateurs non techniques. La voie CLI est celle qu’un développeur peut versionner, planifier et auditer.

Sauvegarder WordPress depuis la ligne de commande

La sauvegarde en ligne de commande se déroule en trois étapes via SSH : exporter la base de données, archiver les fichiers, puis transférer les deux hors du serveur. Commencez par vous connecter :

ssh user@example.com -p 2222

Archivez ensuite les fichiers et exportez la base de données :

# Archiver les fichiers du site depuis le répertoire parent de la racine web
tar -zcf files.tar.gz public_html

# Exporter la base de données avec un instantané cohérent
mysqldump --single-transaction -u DB_USER -p DB_NAME > db.sql

L’option --single-transaction est ce qui rend l’export fiable sur un site en production. Seules les tables InnoDB sont exportées dans un état cohérent ; les tables MyISAM ou MEMORY peuvent encore évoluer pendant l’export. WordPress fonctionnant sur InnoDB par défaut, --single-transaction est bien préférable à --lock-tables car elle ne nécessite aucun verrouillage des tables — votre site reste accessible pendant l’opération. Utilisez mysqldump et non mysqlpump — ce dernier a été supprimé dans MySQL 8.4, de sorte que les scripts qui l’appellent échoueront purement et simplement sur les serveurs actuels.

Rapatriez les deux fichiers avec scp :

scp -P 2222 user@example.com:~/files.tar.gz .
scp -P 2222 user@example.com:~/db.sql .

Un piège que les tutoriels passent souvent sous silence : scp utilise un -P majuscule pour le port, tandis que ssh et mysqldump utilisent un -p minuscule (respectivement pour le port et le mot de passe). Les confondre est une erreur classique qui fait échouer la commande.

Si vous disposez de WP-CLI, wp db export est plus élégant : il exécute l’utilitaire mysqldump en utilisant les identifiants DB_HOST, DB_NAME, DB_USER et DB_PASSWORD définis dans wp-config.php, et accepte tous les paramètres mysqldump valides.

wp db export --single-transaction db.sql

Sur les hébergements managés et cPanel, un mysqldump brut peut échouer avec une erreur de privilège PROCESS lors de l’export des tablespaces. WP-CLI gère déjà ce cas : wp db export ajoute --no-tablespaces à mysqldump par défaut. Avec mysqldump brut sur un hébergement managé, ajoutez vous-même --no-tablespaces.

Automatiser les sauvegardes WordPress avec cron et rclone

Automatisez l’ensemble avec un court script shell planifié via cron, qui exporte la base de données, archive wp-content avec tar et transfère l’archive hors serveur. rclone — « rsync pour le stockage cloud » — prend en charge S3, Backblaze B2 et Google Drive, entre autres.

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

SITE_DIR="/var/www/example.com"
DEST="b2remote:example-backups"     # une remote rclone configurée
STAMP="$(date +%F)"
WORK="$(mktemp -d)"

cd "$SITE_DIR"

# Base de données — WP-CLI lit les identifiants depuis wp-config.php
wp db export --single-transaction "$WORK/db-$STAMP.sql"

# Fichiers — thèmes, plugins, uploads et configuration
tar -zcf "$WORK/wp-content-$STAMP.tar.gz" wp-content wp-config.php

# Transfert hors site
rclone copy "$WORK" "$DEST/$STAMP"

rm -rf "$WORK"

Planifiez-le avec une ligne crontab qui s’exécute quotidiennement à 03h15 et journalise la sortie :

15 3 * * * /usr/local/bin/wp-backup.sh >> /var/log/wp-backup.log 2>&1

C’est là tout l’intérêt de « posséder ses sauvegardes » : pas de tableau de bord, pas de plugin, pas d’intervention manuelle. Si WP-CLI n’est pas installé, remplacez la ligne d’export par mysqldump --single-transaction --no-tablespaces -u DB_USER -pPASS DB_NAME > "$WORK/db-$STAMP.sql".

Stocker les sauvegardes selon la règle 3-2-1

Respectez la règle 3-2-1 : conservez au moins trois copies de votre site, sur deux types de supports différents, dont une copie hors site. Ne laissez jamais l’unique sauvegarde résider sur le même serveur que le site — une intrusion ou une défaillance disque emporte les deux simultanément. C’est précisément pourquoi le script d’automatisation ci-dessus transfère les archives vers du stockage objet plutôt que de les laisser dans la racine web. L’archive contenant une copie complète de votre site, y compris les secrets présents dans wp-config.php, sécurisez la destination avec des identifiants robustes et une authentification à deux facteurs sur le compte de stockage.

Tester la restauration et les erreurs à éviter

Une sauvegarde non testée n’est pas une sauvegarde. Restaurez périodiquement votre archive .sql et votre archive de fichiers sur un site de staging ou en local pour prouver que la copie permet bien de reconstruire le site :

tar -xzf wp-content-2026-07-06.tar.gz
wp db import db-2026-07-06.sql          # ou, sans WP-CLI :
mysql -u DB_USER -p DB_NAME < db-2026-07-06.sql

Trois modes de défaillance expliquent la plupart des sites perdus : sauvegarder les fichiers sans la base de données, conserver la sauvegarde sur le même serveur que le site, et se fier uniquement aux sauvegardes automatiques de l’hébergeur. Chacun est évitable avec le processus décrit ci-dessus.

La méthode fiable est simple et sans surprise : une tâche cron qui exporte la base de données de façon cohérente, archive les fichiers, transfère les deux hors site, et une restauration que vous testez réellement. Écrivez le script une fois, pointez-le vers du stockage objet, ajoutez la ligne crontab et effectuez un test de restauration cette semaine — vous aurez alors une sauvegarde que vous maîtrisez, plutôt qu’une sauvegarde dont vous espérez qu’elle s’exécute.

FAQ

Quelle est la différence entre wp db export et l'exécution directe de mysqldump ?

wp db export est une fine couche d'abstraction au-dessus de mysqldump. Il exécute l'utilitaire mysqldump en utilisant les identifiants DB_HOST, DB_NAME, DB_USER et DB_PASSWORD déjà stockés dans wp-config.php, ce qui évite de les rechercher ou de les saisir manuellement, et il accepte tous les paramètres mysqldump valides. Il ajoute également --no-tablespaces par défaut, évitant ainsi l'erreur de privilège PROCESS fréquente sur les hébergements managés. mysqldump brut produit le même export, mais nécessite de fournir soi-même les identifiants et les paramètres.

Pourquoi mysqldump génère-t-il une erreur de privilège PROCESS sur les hébergements managés, et comment y remédier ?

Sur les hébergements managés et cPanel, mysqldump tente d'exporter les informations de tablespace, ce qui requiert le privilège PROCESS dont les utilisateurs de bases de données partagées ne disposent généralement pas, produisant une erreur « Access denied; you need the PROCESS privilege ». Ajoutez le paramètre --no-tablespaces pour ignorer cette étape et l'export se termine normalement. La commande wp db export de WP-CLI ajoute --no-tablespaces automatiquement. Dans la plupart des cas, l'export aboutit malgré l'erreur ; vérifiez le fichier obtenu en vous assurant que vos tables sont bien présentes.

Puis-je me passer de la sauvegarde des fichiers puisque le cœur de WordPress et les plugins sont retéléchargeables ?

Vous pouvez réduire ce que vous archivez, mais ne sautez jamais complètement la sauvegarde des fichiers. Le cœur de WordPress, les thèmes et les plugins sont retéléchargeables depuis leurs sources, si bien que certains outils de sauvegarde ne conservent que la base de données et le dossier uploads. Cependant, le dossier uploads contient tous les médias que vous ne pouvez pas retélécharger, wp-config.php contient vos identifiants de base de données et vos clés de sécurité, et tout fichier personnalisé ou modifié est irremplaçable. Sauvegarder wp-content et wp-config.php capture les éléments véritablement uniques à votre site.

Comment restaurer un site WordPress depuis une sauvegarde mysqldump et tar ?

Extrayez l'archive de fichiers dans le répertoire du site avec tar -xzf archive.tar.gz, puis importez la base de données. Avec WP-CLI, exécutez wp db import db.sql, qui lit les identifiants depuis wp-config.php. Sans WP-CLI, exécutez mysql -u DB_USER -p DB_NAME < db.sql sur une base de données existante. Restaurez les deux parties ensemble et, si le domaine a changé, effectuez un chercher-remplacer dans la base de données pour mettre à jour les URL stockées. Testez toujours la restauration sur un site de staging ou en local avant de vous y fier en production.

mysqldump est-il toujours sûr à utiliser, ou faut-il passer à mysqlpump ?

Utilisez mysqldump, et non mysqlpump. L'utilitaire mysqlpump a été déprécié dans MySQL 8.0.34 et entièrement supprimé dans MySQL 8.4, de sorte que les scripts qui l'appellent échouent sur les serveurs actuels. mysqldump reste pris en charge et à jour ; MySQL recommande mysqldump ou les utilitaires de dump MySQL Shell comme remplaçants. Pour un instantané cohérent d'un site InnoDB en production, exécutez mysqldump avec le paramètre --single-transaction, qui évite de verrouiller les tables pendant l'export.