Sauvegardes WordPress automatiques : UpdraftPlus vs BackWPup vs rsync à la main

Dans cet article

  • UpdraftPlus reste le plugin de sauvegarde WordPress le plus fiable en 2026, avec une version gratuite qui couvre 90 % des besoins d’un site vitrine ou blog
  • BackWPup offre un export complet vers S3, Dropbox ou FTP mais sa restauration native reste limitée sans la version pro à 69 €/an
  • Un script rsync bien configuré sur VPS sauvegarde un WordPress de 2 Go en moins de 30 secondes en mode incrémental
  • La règle de sauvegarde 3-2-1 (3 copies, 2 supports, 1 hors site) est le minimum vital pour tout site en production
  • J’ai perdu un site client en 2019 à cause d’une sauvegarde jamais testée en restauration : depuis, je teste chaque backup tous les trimestres
  • Le coût réel d’une stratégie de sauvegarde sérieuse se situe entre 0 et 12 € HT/mois selon la méthode choisie

Pourquoi sauvegarder WordPress est non négociable en 2026

En onze ans de freelance WordPress, j’ai vu des dizaines de sites tomber. Piratage, mise à jour de plugin qui casse tout, erreur humaine sur la base de données, hébergeur qui perd un disque. Chaque fois, la question n’est pas si ça arrivera, mais quand.

WordPress propulse encore plus de 40 % du web en 2026 selon les données de W3Techs sur les parts de marché des CMS. Cette popularité en fait une cible privilégiée : le rapport annuel de Sucuri indique que WordPress représente environ 95 % des CMS infectés parmi les sites nettoyés par leurs équipes. Un site non sauvegardé, c’est un site jetable.

Ce qui me frappe, c’est que beaucoup de mes clients arrivent en pensant que leur hébergeur gère tout. En réalité, la plupart des hébergements mutualisés proposent des snapshots quotidiens conservés 7 à 14 jours maximum. Après ce délai, c’est fini. Et quand le problème est détecté trois semaines plus tard (un malware discret, une corruption progressive de la BDD), il n’y a plus rien à restaurer.

J’ai vécu cette situation en 2019. Un client e-commerce sur WooCommerce, base de données corrompue après une mise à jour de PHP. Les sauvegardes OVH remontaient à 7 jours, mais la corruption datait de 12 jours. Résultat : perte de 5 jours de commandes, reconstruction manuelle partielle, et un client furieux à juste titre. Depuis ce jour, je ne livre plus un site sans stratégie de sauvegarde documentée.

Les sauvegardes hors site nécessitent un serveur distant ou un stockage cloud séparé
Les sauvegardes hors site nécessitent un serveur distant ou un stockage cloud séparé

La règle 3-2-1 appliquée à WordPress

La règle 3-2-1 vient du monde de l’administration système et elle s’applique parfaitement à WordPress. Le principe est simple :

  • 3 copies de vos données (le site en production + 2 sauvegardes)
  • 2 supports différents (par exemple le serveur + un stockage cloud)
  • 1 copie hors site (géographiquement séparée du serveur principal)

En pratique, pour un site WordPress, cela signifie que la sauvegarde sur le même serveur que le site ne compte pas comme une vraie sauvegarde. Si le serveur brûle, le disque lâche ou l’hébergeur fait faillite, vous perdez tout. J’ai vu un hébergeur français disparaître du jour au lendemain en 2022 : les clients qui n’avaient pas de copie externe ont tout perdu.

Pour appliquer cette règle concrètement, il faut sauvegarder deux éléments distincts :

  • Les fichiers : le core WordPress, les thèmes, les plugins, le dossier wp-content/uploads
  • La base de données MySQL : les articles, pages, réglages, utilisateurs, commandes WooCommerce

Beaucoup de solutions ne sauvegardent que l’un des deux. Un dump SQL sans les fichiers, c’est un site sans images ni thème. Les fichiers sans la base, c’est une coquille vide. Vérifiez toujours que votre méthode couvre les deux.

Si vous hébergez votre WordPress sur un VPS, j’ai détaillé la configuration serveur complète dans mon tutoriel pour déployer WordPress sur un VPS OVH. La partie sauvegarde s’intègre directement dans ce workflow.

UpdraftPlus : configuration complète et retour d’expérience

UpdraftPlus est le plugin que j’installe par défaut sur tous les sites clients en hébergement mutualisé. Plus de 3 millions d’installations actives, une note de 4,8/5 sur le répertoire officiel, et surtout une restauration en un clic qui fonctionne vraiment.

Ce que fait la version gratuite

La version gratuite couvre l’essentiel :

  • Sauvegarde complète (fichiers + base de données) planifiable (toutes les 4h, 8h, 12h, quotidien, hebdomadaire, mensuel)
  • Envoi vers Google Drive, Dropbox, S3, Rackspace, FTP, email
  • Restauration native depuis l’interface WordPress
  • Choix du nombre de sauvegardes conservées (je mets 4 en hebdomadaire, soit un mois de rétention)

Ma configuration type

Voici les réglages que j’applique sur un site vitrine classique :

  • Fichiers : sauvegarde hebdomadaire, conservation de 4 exemplaires
  • Base de données : sauvegarde quotidienne, conservation de 7 exemplaires
  • Destination : Google Drive (dossier dédié par client)
  • Exclusions : wp-content/cache, wp-content/updraft, fichiers .log

La base de données change plus souvent que les fichiers (nouveaux articles, commentaires, commandes), d’où une fréquence plus élevée. Les fichiers bougent surtout lors des mises à jour de plugins ou d’ajout de médias.

Les limites que j’ai constatées

UpdraftPlus montre ses limites sur les gros sites. Au-delà de 2 Go de fichiers ou 500 Mo de base de données, les sauvegardes peuvent échouer en mutualisé à cause des limites de mémoire PHP et de temps d’exécution. La version premium (70 $/an) résout en partie ce problème avec la sauvegarde incrémentale, mais ce n’est pas une solution miracle.

Autre point : UpdraftPlus ne sauvegarde pas les fichiers hors de wp-content par défaut. Si vous avez modifié wp-config.php, .htaccess, ou ajouté des fichiers à la racine, il faut les inclure manuellement dans la version premium. En gratuit, ces fichiers ne sont tout simplement pas couverts.

BackWPup : l’alternative solide pour les exports planifiés

BackWPup adopte une philosophie différente. Là où UpdraftPlus pense « sauvegarde + restauration », BackWPup pense « job d’export automatisé« . C’est un outil plus technique, plus configurable, mais moins accessible pour un client non-dev.

Un script rsync en cours d'exécution dans un terminal pour sauvegarder un site WordPress
Un script rsync en cours d’exécution dans un terminal pour sauvegarder un site WordPress

Les points forts de BackWPup

  • Granularité des jobs : vous pouvez créer plusieurs jobs avec des périmètres différents (un job pour la BDD, un job pour les uploads, un job pour les logs)
  • Formats d’export : ZIP, TAR, TAR.GZ, TAR.BZ2
  • Destinations multiples par job : un même job peut envoyer vers S3 et Dropbox simultanément
  • Vérification de la base : BackWPup peut vérifier et optimiser les tables MySQL avant l’export
  • Version gratuite qui envoie vers S3, Dropbox, FTP, email

Le problème de la restauration

Le gros défaut de BackWPup en version gratuite : il n’y a pas de restauration intégrée. Vous obtenez une archive ZIP contenant les fichiers et un dump SQL. Pour restaurer, il faut :

  1. Décompresser l’archive
  2. Uploader les fichiers via FTP ou SSH
  3. Importer le dump SQL via phpMyAdmin ou en ligne de commande
  4. Vérifier et corriger les URLs si le domaine change

C’est faisable pour un développeur, mais impensable pour un client en situation de stress. La version pro (69 €/an) ajoute une fonction de restauration, mais à ce prix, UpdraftPlus Premium fait mieux.

Quand BackWPup a du sens

J’utilise BackWPup dans deux cas précis : quand le client a besoin d’archives régulières pour conformité (certains secteurs exigent des archives datées), et quand je veux un dump SQL propre envoyé automatiquement sur S3 pour alimenter un environnement de staging. Pour la sauvegarde de sécurité classique, UpdraftPlus reste mon premier choix.

rsync à la main : la méthode serveur pour les devs

Si vous gérez votre propre VPS ou serveur dédié, rsync est la Rolls-Royce de la sauvegarde de fichiers. Pas de plugin, pas de surcharge PHP, pas de limite d’hébergeur : juste un transfert de fichiers incrémental, rapide et fiable.

Le script que j’utilise en production

Voici le script que j’ai affiné sur une dizaine de VPS clients :

#!/bin/bash
# Sauvegarde WordPress complète : fichiers + BDD
# À placer dans /usr/local/bin/backup-wp.sh

DATE=$(date +%Y-%m-%d_%Hh%M)
SITE_PATH="/var/www/monsite"
BACKUP_LOCAL="/var/backups/wordpress"
BACKUP_REMOTE="user@backup-server:/backups/monsite"
DB_NAME="wp_monsite"
DB_USER="wp_user"
DB_PASS="motdepasse_fort"
RETENTION=30

# Création du dossier du jour
mkdir -p "$BACKUP_LOCAL/$DATE"

# Dump de la base de données
mysqldump --single-transaction --quick \
  -u "$DB_USER" -p"$DB_PASS" "$DB_NAME" \
  | gzip > "$BACKUP_LOCAL/$DATE/db_$DATE.sql.gz"

# Sync des fichiers (incrémental)
rsync -avz --delete \
  --exclude='wp-content/cache/' \
  --exclude='wp-content/updraft/' \
  --exclude='*.log' \
  "$SITE_PATH/" "$BACKUP_LOCAL/$DATE/files/"

# Envoi vers le serveur distant
rsync -avz "$BACKUP_LOCAL/$DATE" "$BACKUP_REMOTE/"

# Nettoyage des sauvegardes locales > 30 jours
find "$BACKUP_LOCAL" -maxdepth 1 -type d -mtime +$RETENTION -exec rm -rf {} \;

echo "Sauvegarde terminée : $DATE"

Planification avec cron

J’ajoute ce script dans le crontab pour une exécution quotidienne à 3h du matin, quand le trafic est au plus bas :

# crontab -e
0 3 * * * /usr/local/bin/backup-wp.sh >> /var/log/backup-wp.log 2>&1

Le flag --single-transaction dans mysqldump est crucial : il garantit un dump cohérent sans verrouiller les tables. Sans ce flag, un visiteur qui passe une commande WooCommerce pendant le dump pourrait créer des données incohérentes.

Les avantages concrets de rsync

  • Vitesse : rsync ne transfère que les fichiers modifiés. Un site de 2 Go se sauvegarde en 20 à 30 secondes après le premier sync complet
  • Zéro impact sur WordPress : pas de plugin PHP qui consomme de la mémoire, pas de timeout
  • Contrôle total : vous choisissez exactement quoi sauvegarder, où, et combien de temps conserver
  • Gratuit : rsync est installé par défaut sur toute distribution Linux

Les prérequis

Cette méthode demande un accès SSH au serveur, des connaissances en ligne de commande Linux, et idéalement un second serveur ou un espace de stockage distant (un VPS à 3 €/mois chez un autre hébergeur fait très bien l’affaire). Si vous n’êtes pas à l’aise avec le terminal, restez sur UpdraftPlus. C’est aussi pour ça que je recommande de vérifier l’accès SSH avant de choisir un hébergement, comme je l’explique dans mon guide de déploiement sur VPS OVH.

Comparatif détaillé : UpdraftPlus vs BackWPup vs rsync

Après avoir utilisé ces trois solutions sur des dizaines de projets, voici le comparatif que j’aurais aimé trouver quand j’ai commencé.

Critère UpdraftPlus (gratuit) BackWPup (gratuit) rsync + cron
Facilité d’installation 5 min, sans code 10 min, sans code 30 min, accès SSH requis
Sauvegarde fichiers wp-content uniquement Tout le site Tout le serveur si besoin
Sauvegarde BDD Oui Oui + vérification tables Via mysqldump (script)
Restauration intégrée Oui, en 1 clic Non (manuelle ou pro) Non (manuelle)
Sauvegarde incrémentale Non (premium seul) Non Oui, natif
Impact sur les performances Modéré (PHP) Modéré (PHP) Très faible
Destinations cloud gratuites Google Drive, Dropbox, S3, FTP S3, Dropbox, FTP Tout serveur SSH/FTP
Taille max recommandée 2 Go (mutualisé) 2 Go (mutualisé) Illimité
Coût version premium 70 $/an 69 €/an Gratuit (coût serveur distant)
Adapté aux non-devs Oui Partiellement Non

Le choix dépend vraiment du profil. Pour mes clients en mutualisé qui ne mettent jamais les mains dans le code, UpdraftPlus gratuit est la réponse. Pour mes projets perso et mes clients sur VPS, rsync + mysqldump est imbattable en fiabilité et en performance.

Comparaison des trois solutions de sauvegarde WordPress sur les critères essentiels
Comparaison des trois solutions de sauvegarde WordPress sur les critères essentiels

Quelle solution choisir selon votre profil

Après des années d’essais et d’erreurs, voici mes recommandations selon le contexte.

Vous êtes un client avec un site vitrine

Installez UpdraftPlus gratuit, configurez l’envoi vers Google Drive, et demandez à votre développeur de tester la restauration une fois. C’est tout. Ne touchez à rien d’autre. Cette configuration vous protège de 95 % des scénarios de perte de données.

Vous êtes freelance et gérez plusieurs sites clients

Deux approches selon l’hébergement :

  • Sites en mutualisé : UpdraftPlus gratuit sur chaque site, avec un compte Google Drive dédié par client (15 Go gratuits par compte). Documentez la procédure de restauration dans votre livrable client.
  • Sites sur VPS : rsync + mysqldump centralisé. Un seul script gère tous les sites du serveur. C’est ce que je fais sur mes VPS OVH avec 4 à 6 sites WordPress par machine.

Pour organiser le suivi de ces sauvegardes entre clients, un bon outil de gestion de projet aide énormément. J’ai comparé les options dans mon article sur ClickUp vs Notion vs Asana pour gérer ses clients freelance.

Vous avez un site WooCommerce avec du volume

Ici, pas de compromis. Je recommande UpdraftPlus Premium pour la sauvegarde incrémentale (les uploads produits peuvent peser des dizaines de Go), combiné avec un rsync quotidien vers un serveur séparé. La base de données WooCommerce est critique : une commande perdue, c’est du chiffre d’affaires perdu. Sauvegardez la BDD toutes les 4 heures minimum.

Vous êtes développeur et aimez tout contrôler

rsync + mysqldump + un dépôt Git pour le thème et les plugins custom. C’est ma stack préférée. Le Git ne remplace pas la sauvegarde (il ne versionne pas la BDD ni les uploads), mais il complète parfaitement rsync. Pour choisir votre outil de gestion de tâches autour de ce workflow, consultez mon comparatif Linear vs Jira vs GitHub Projects.

Les erreurs qui rendent vos sauvegardes inutiles

Avoir une sauvegarde qui tourne ne signifie pas être protégé. J’ai identifié sept erreurs récurrentes chez mes clients et dans les audits que je réalise.

Erreur n°1 : ne jamais tester la restauration

C’est l’erreur la plus courante et la plus dangereuse. Vous avez des sauvegardes qui tournent depuis deux ans, mais vous n’avez jamais vérifié qu’elles fonctionnent. Le jour où vous en avez besoin, vous découvrez que l’archive est corrompue, que le dump SQL est incomplet, ou que la version PHP du serveur de restauration n’est pas compatible. Testez la restauration au moins une fois par trimestre.

Erreur n°2 : sauvegarder sur le même serveur

Je le répète : une sauvegarde stockée uniquement sur le même serveur que le site n’est pas une sauvegarde. C’est un miroir qui mourra en même temps que l’original. Envoyez toujours une copie hors du serveur.

Erreur n°3 : oublier la base de données

Certains scripts ne sauvegardent que les fichiers via rsync sans faire de mysqldump. Le contenu du site (articles, pages, réglages, utilisateurs) est dans la base MySQL, pas dans les fichiers. Sans la base, vous n’avez rien.

Erreur n°4 : des rétentions trop courtes

Conserver uniquement la dernière sauvegarde est risqué. Si votre site est compromis et que la sauvegarde suivante écrase la précédente, vous sauvegardez un site piraté. Gardez au minimum 4 sauvegardes hebdomadaires (un mois de profondeur).

Erreur n°5 : ignorer les emails d’échec

UpdraftPlus et BackWPup envoient des notifications par email quand une sauvegarde échoue. Configurez une adresse email que vous consultez réellement, pas l’adresse info@ que personne ne lit. Pour le suivi de ces alertes dans un workflow plus large, un outil d’automatisation comme ceux que je compare dans mon article n8n vs Make vs Zapier peut centraliser les notifications.

Erreur n°6 : ne pas exclure les fichiers inutiles

Le dossier wp-content/cache peut peser plusieurs centaines de Mo. Les logs d’erreur PHP s’accumulent. Ces fichiers sont inutiles dans une sauvegarde et ne font que la ralentir et l’alourdir. Excluez-les systématiquement.

Erreur n°7 : mots de passe en clair dans les scripts

Si vous utilisez rsync + mysqldump, ne mettez pas le mot de passe MySQL en dur dans le script. Utilisez un fichier ~/.my.cnf avec les permissions 600 :

[mysqldump]
user=wp_user
password=motdepasse_fort

Puis dans le script, appelez simplement mysqldump --defaults-file=~/.my.cnf. C’est un réflexe de sécurité que la CNIL rappelle dans son guide de sécurité des données personnelles.

Automatiser et monitorer ses sauvegardes

Une sauvegarde qu’on oublie de vérifier finit toujours par échouer silencieusement. Voici comment je mets en place un suivi fiable.

Monitoring des sauvegardes plugin

Pour UpdraftPlus et BackWPup, configurez les notifications email sur succès ET échec. Je crée une règle Gmail qui tague automatiquement ces emails pour les repérer. Chaque lundi, je vérifie que tous les sites ont bien leurs sauvegardes de la semaine.

Monitoring des sauvegardes rsync

Pour les scripts serveur, j’ajoute une vérification automatique qui m’alerte si la dernière sauvegarde date de plus de 48 heures :

#!/bin/bash
# check-backup.sh : alerte si pas de backup récent
LAST_BACKUP=$(find /var/backups/wordpress -maxdepth 1 -type d -mtime -2 | wc -l)
if [ "$LAST_BACKUP" -eq 0 ]; then
  echo "ALERTE : aucune sauvegarde WordPress depuis 48h" | \
  mail -s "[BACKUP] Échec sauvegarde WordPress" [email protected]
fi

Tester la restauration automatiquement

Pour les clients importants, je mets en place un test de restauration mensuel automatisé. Le script restaure la dernière sauvegarde sur un sous-domaine de test, vérifie que la page d’accueil répond en HTTP 200, et m’envoie un rapport. C’est du travail à mettre en place, mais c’est la seule façon d’être sûr à 100 % que les sauvegardes fonctionnent.

Pour le suivi de ces automatisations, je m’appuie sur des outils d’analytics respectueux du RGPD pour monitorer la disponibilité des sites, comme ceux que j’ai comparés dans mon article Plausible vs Umami vs Matomo.

Le coût réel d’une stratégie de sauvegarde

Beaucoup hésitent à investir dans les sauvegardes. Voici ce que ça coûte réellement :

  • UpdraftPlus gratuit + Google Drive : 0 €/mois (15 Go gratuits par compte Google)
  • UpdraftPlus Premium : environ 5,80 €/mois (70 $/an)
  • rsync vers un VPS dédié backup : 3 à 5 €/mois (VPS Starter chez la plupart des hébergeurs)
  • rsync vers un bucket S3 : 0,50 à 2 €/mois pour un site standard (tarification au Go stocké)

Comparez ces montants au coût de reconstruction d’un site : entre 500 et 5 000 € selon la complexité, sans compter la perte de référencement et les données clients irrécupérables. La sauvegarde est l’investissement le plus rentable qu’un site WordPress puisse faire. Si vous gérez votre comptabilité en parallèle, j’en parle dans ce que mon expert-comptable m’a appris en 5 ans de freelance.

Pour les aspects contractuels, pensez aussi à inclure une clause de sauvegarde dans vos devis. J’ai détaillé les clauses indispensables dans mon article devis et contrats freelance : les 8 clauses à ajouter.

À retenir

  • Installez UpdraftPlus gratuit et envoyez les sauvegardes sur Google Drive si vous êtes en mutualisé : c’est la solution la plus fiable pour 0 €
  • Sur VPS, mettez en place un script rsync + mysqldump + cron qui envoie les données sur un serveur séparé chaque nuit
  • Appliquez la règle 3-2-1 : 3 copies, 2 supports, 1 hors site, et vérifiez que fichiers ET base de données sont couverts
  • Testez la restauration au moins une fois par trimestre : une sauvegarde jamais testée n’est pas une sauvegarde
  • Configurez les alertes email et vérifiez chaque semaine que les sauvegardes n’échouent pas silencieusement

Questions fréquentes


UpdraftPlus gratuit suffit-il pour un site WooCommerce ?

Pour un petit WooCommerce avec moins de 100 produits et quelques commandes par jour, la version gratuite suffit. Configurez la sauvegarde de la base de données toutes les 4 à 8 heures pour ne pas perdre de commandes. Au-delà de 2 Go de fichiers ou pour la sauvegarde incrémentale, la version premium devient nécessaire.

Comment restaurer un site WordPress à partir d’une sauvegarde rsync ?

Copiez les fichiers sauvegardés vers le dossier du site avec rsync ou scp, puis importez le dump SQL avec la commande mysql -u utilisateur -p base_de_donnees < dump.sql.gz. Vérifiez que le fichier wp-config.php pointe vers la bonne base de données et le bon préfixe de tables. Si le domaine change, lancez un rechercher-remplacer des URLs dans la base avec WP-CLI : wp search-replace ancien-domaine.fr nouveau-domaine.fr.[/site_a] [site_q]Peut-on combiner UpdraftPlus et rsync sur le même site ?[/site_q] [site_a]Oui, et c'est même ce que je recommande pour les sites critiques. UpdraftPlus gère la sauvegarde applicative avec restauration facile depuis l'admin WordPress, tandis que rsync assure une copie système complète vers un serveur distant. Les deux méthodes sont complémentaires et n'interfèrent pas entre elles.[/site_a] [site_q]Quelle est la fréquence de sauvegarde idéale pour un blog WordPress ?[/site_q] [site_a]Pour un blog qui publie 2 à 3 articles par semaine, une sauvegarde quotidienne de la base de données et hebdomadaire des fichiers est un bon équilibre. Conservez au moins 4 sauvegardes hebdomadaires pour avoir un mois de profondeur. Si vous publiez quotidiennement ou recevez beaucoup de commentaires, passez la base de données en sauvegarde toutes les 8 heures.[/site_a] [site_q]BackWPup ou UpdraftPlus : lequel choisir en 2026 ?[/site_q] [site_a]UpdraftPlus pour la majorité des cas grâce à sa restauration en un clic. BackWPup si vous avez besoin d'archives datées pour conformité réglementaire ou si vous voulez des dumps SQL propres pour alimenter un environnement de staging. En gratuit, UpdraftPlus est clairement supérieur grâce à la restauration native. En premium, les deux se valent davantage mais UpdraftPlus reste plus simple d'utilisation.[/site_a] [site_q]Comment vérifier que mes sauvegardes WordPress fonctionnent vraiment ?[/site_q] [site_a]Téléchargez la dernière sauvegarde et restaurez-la sur un environnement de test : un sous-domaine, un serveur local avec Local by Flywheel, ou un VPS de test. Vérifiez que le site s'affiche correctement, que les pages chargent, que les formulaires fonctionnent et que les données récentes sont présentes. Faites ce test au minimum une fois par trimestre. Une sauvegarde que vous n'avez jamais restaurée est une promesse non vérifiée.[/site_a] [/site_faq] [site_bio]