En 2026, 30 000 sites web sont piratés chaque jour (Colorlib, WordPress Hacking Statistics 2026). Pour un WordPress sur VPS, la question n’est pas de savoir si une catastrophe peut arriver, mais si tu seras capable de tout restaurer en moins d’une heure. Si tes sauvegardes sont stockées sur le même disque que ton site — comme wp-dbmanager le fait par défaut — c’est un faux sentiment de sécurité.
Je vais te montrer comment j’ai mis en place des backups automatiques complets sur SysKB.com : base de données MariaDB sauvegardée chaque nuit, dossier wp-content (3,4 Go) archivé chaque dimanche, le tout synchronisé en quelques secondes vers Google Drive via rclone. Zéro plugin WordPress, zéro dépendance à la santé de ton site — ça tourne au niveau du système d’exploitation.
Ce que tu vas mettre en place
- rclone v1.74.1 installé sur ton VPS Debian/Ubuntu
- Remote Google Drive configuré via OAuth headless (sans navigateur côté serveur)
- Script bash complet : mysqldump + tar + rotation automatique + sync Drive
- Cron quotidien à 2h du matin, log centralisé dans
/var/log/backup-syskb.log - Politique de rétention : 14 jours pour la DB, 60 jours pour les fichiers
Pourquoi les backups locaux ne te protègent vraiment pas
En octobre 2025, Data Stack Hub rapporte que 64% des organisations ont subi au moins un incident de perte de données sur l’année écoulée. Et selon le Melapress WordPress Security Survey 2025 (264 répondants), seulement 27% des professionnels WordPress disposent d’un plan de reprise après incident. Ce n’est pas qu’ils ne sauvegardent pas — c’est qu’ils sauvegardent au mauvais endroit.
Les plugins comme WP DB Manager ou les solutions par défaut stockent les archives dans wp-content/backup-db/. C’est pratique, c’est aussi inutile si ton disque lâche, si ton VPS est compromis, ou si tu fais un rm -rf par inadvertance. Une sauvegarde qui survit uniquement sur le même serveur que ce qu’elle protège, ça ne s’appelle pas une sauvegarde.
Sur SysKB.com, j’avais WP DB Manager actif avec 14 sauvegardes locales accumulées (231 Mo sur disque). Impressionnant en apparence, inutile en cas de crash réel. La base de données fait 92 Mo non compressés — en stockage offsite, ça tient dans 13 Mo une fois compressé en .sql.gz. Le coût de ne pas le faire est maximal, le coût de le faire est quasi nul.
Ce qu’il te faut avant de démarrer
Ce guide cible un VPS sous Debian 11 ou 12 avec Apache, MariaDB et WordPress installés, et un accès root via SSH. Si tu n’as pas encore configuré ton accès SSH, consulte notre guide pour te connecter en SSH avec PuTTY avant de continuer. Temps estimé : 20 minutes.
- VPS Debian 11/12 (ou Ubuntu 22.04+) avec accès root
- WordPress + MariaDB opérationnels
- Un compte Google avec Google Drive (les 15 Go gratuits suffisent)
- rclone installé sur ta machine locale pour l’étape OAuth (Mac, Windows ou Linux)
Étape 1 — Installer rclone sur le VPS
rclone est un outil open-source compatible avec plus de 70 services de stockage cloud. En 2026, la version stable est la 1.74.1. L’installation sur Debian se fait en une seule commande — pas besoin d’apt, l’installeur officiel gère tout :
ssh root@ton-vps
curl https://rclone.org/install.sh | bashL’installeur télécharge l’archive pour ton architecture (amd64 ou arm64), place le binaire dans /usr/bin/rclone, et installe la page man si disponible. Vérifie l’installation :
rclone version
# Doit afficher : rclone v1.74.1 ou supérieurÉtape 2 — Configurer Google Drive (OAuth headless)
C’est l’étape qui bloque la plupart des tutoriels. Un serveur Linux sans interface graphique ne peut pas ouvrir un navigateur pour valider l’accès OAuth Google. La solution : générer le token sur ta machine locale, puis l’injecter dans la config du VPS. C’est la méthode officielle recommandée par rclone pour les serveurs headless.
Sur ta machine locale (Mac ou Windows)
Installe rclone localement (brew install rclone sur Mac, ou via rclone.org sur Windows), puis lance :
rclone authorize "drive"Un navigateur s’ouvre automatiquement sur accounts.google.com. Sélectionne ton compte Google, autorise rclone à accéder à Drive, et retourne dans le terminal. Tu obtiens un bloc JSON :
Paste the following into your remote machine --->
{"access_token":"ya29.xxx","token_type":"Bearer","refresh_token":"1//03xxx","expiry":"2026-05-19T19:30:56+02:00"}
<---End pastePoint clé : l’access_token expire au bout d’une heure — c’est normal. Le refresh_token est permanent. C’est lui qui permet à rclone de renouveler automatiquement l’accès sans aucune intervention de ta part par la suite.
Sur le VPS — créer le fichier de configuration
mkdir -p /root/.config/rclone
nano /root/.config/rclone/rclone.confColle le contenu suivant en remplaçant le bloc token par celui récupéré à l’étape précédente :
[gdrive]
type = drive
scope = drive
token = {"access_token":"ya29.xxx","token_type":"Bearer","refresh_token":"1//03xxx","expiry":"2026-05-19T19:30:56+02:00"}Teste immédiatement la connexion :
rclone lsd gdrive:
# Doit lister les dossiers racine de ton Google Drive
Étape 3 — Le script de backup complet
Sur SysKB.com, la base MariaDB fait 92 Mo non compressée. Avec gzip, l’archive descend à 13 Mo — soit une compression de 86%. Le dossier wp-content pèse 3,4 Go. Le sync vers Google Drive s’effectue à environ 2 Mo/s, soit 7 secondes pour la DB quotidienne.
Crée la structure et le script :
mkdir -p /root/backups/syskb/{db,files}
mkdir -p /root/scripts
nano /root/scripts/backup-syskb.shVoici le script complet à coller et adapter :
#!/bin/bash
set -euo pipefail
BACKUP_DIR="/root/backups/syskb"
DATE=$(date +%Y%m%d_%H%M%S)
DB_NAME="wordpress2023" # <-- adapte à ton nom de base
WP_DIR="/var/www/html"
LOG="/var/log/backup-syskb.log"
echo "[$DATE] --- Début backup ---" >> $LOG
# 1. Dump de la base de données (quotidien)
mysqldump -u root "$DB_NAME" | gzip > "$BACKUP_DIR/db/db_$DATE.sql.gz"
echo "[$DATE] DB OK : db_$DATE.sql.gz" >> $LOG
# 2. Archive wp-content (chaque dimanche uniquement)
if [ "$(date +%u)" -eq 7 ]; then
tar -czf "$BACKUP_DIR/files/wp-content_$DATE.tar.gz"
--exclude='wp-content/cache'
--exclude='wp-content/upgrade'
-C "$WP_DIR" wp-content
echo "[$DATE] Fichiers OK : wp-content_$DATE.tar.gz" >> $LOG
fi
# 3. Rotation locale automatique
find "$BACKUP_DIR/db/" -name "*.sql.gz" -mtime +14 -delete
find "$BACKUP_DIR/files/" -name "*.tar.gz" -mtime +60 -delete
# 4. Synchronisation vers Google Drive
rclone sync "$BACKUP_DIR" gdrive:SysKB-Backups/ --log-file="$LOG" --log-level INFO
echo "[$DATE] Sync Google Drive OK" >> $LOG
echo "[$DATE] --- Fin backup ---" >> $LOGRends le script exécutable :
chmod +x /root/scripts/backup-syskb.shCe que fait chaque section :
set -euo pipefail: le script s’arrête immédiatement en cas d’erreur — tu ne te retrouves pas avec un backup corrompu silencieuxmysqldump | gzip: dump direct sans fichier intermédiaire, économise de l’espace disque temporairedate +%u: retourne le numéro du jour (1=lundi, 7=dimanche) — le tar ne se déclenche que le dimanche--exclude='wp-content/cache': exclut les dossiers cache et upgrade, inutiles à sauvegarderfind ... -mtime +14 -delete: purge automatiquement les fichiers de plus de 14 joursrclone sync: synchronise le dossier local vers Drive en supprimant ce qui a été purgé localement
Étape 4 — Automatiser avec cron
Une seule ligne à ajouter au crontab de root pour déclencher le script chaque nuit à 2h du matin — heure creuse, bien après les pics de trafic :
# Ajouter au crontab sans écraser les entrées existantes
(crontab -l 2>/dev/null; echo "0 2 * * * /root/scripts/backup-syskb.sh >> /var/log/backup-syskb.log 2>&1") | crontab -
# Vérifier que l'entrée est bien présente
crontab -lLa syntaxe 0 2 * * * signifie : à la minute 0, heure 2, tous les jours. Si ton VPS est en UTC, adapte : 0 0 * * * correspond à 2h heure française en été. Vérifie le fuseau de ton serveur avec timedatectl.
Comment vérifier que tes sauvegardes fonctionnent
Ne fais jamais confiance au cron sans avoir testé manuellement au moins une fois. Beaucoup de scripts fonctionnent en session interactive mais échouent via cron parce que la variable PATH diffère. Lance le script à la main immédiatement après l’installation :
# Lancer manuellement pour tester
/root/scripts/backup-syskb.sh
# Vérifier les fichiers créés localement
ls -lh /root/backups/syskb/db/
# Lire le log
cat /var/log/backup-syskb.log
# Vérifier la présence sur Google Drive
rclone ls gdrive:SysKB-Backups/Ce que tu dois voir dans le log après un run réussi :
[20260519_163133] --- Début backup ---
[20260519_163133] DB OK : db_20260519_163133.sql.gz
2026/05/19 16:31:43 INFO : db/db_20260519_163133.sql.gz: Copied (new)
Transferred: 12.397 MiB / 12.397 MiB, 100%, 2.066 MiB/s, ETA 0s
[20260519_163133] Sync Google Drive OK
[20260519_163133] --- Fin backup ---Politique de rétention recommandée
La règle d’or : la stratégie 3-2-1. 3 copies des données, sur 2 supports différents, dont 1 hors-site. Avec rclone + Google Drive, tu as 2 copies (locale + Drive) sur 2 supports distincts. Pour une protection maximale, ajoute un troisième emplacement — un autre service cloud ou un NAS local (consulte notre guide complet NAS 2026 pour choisir le bon stockage hors-site).
| Type de backup | Fréquence | Rétention locale | Rétention Google Drive | Taille estimée |
|---|---|---|---|---|
| DB dump (.sql.gz) | Quotidien | 14 jours | 14 jours | ~13 Mo/archive |
| wp-content (.tar.gz) | Hebdomadaire (dim.) | 8 semaines | 60 jours | ~3,4 Go/archive |
| Config serveur | Mensuel (manuel) | — | Illimité | < 1 Mo |
Questions fréquentes
Que se passe-t-il quand l’access_token expire ?
Rien — rclone utilise automatiquement le refresh_token pour en obtenir un nouveau avant chaque opération. Le refresh_token ne expire pas tant que tu ne révoque pas l’accès dans les paramètres de ton compte Google. Après la configuration initiale, il n’y a aucune intervention manuelle à faire.
Comment restaurer la base de données depuis une archive ?
Récupère le fichier .sql.gz depuis Drive ou en local, puis :
# Télécharger depuis Google Drive si besoin
rclone copy gdrive:SysKB-Backups/db/db_20260519_163133.sql.gz /tmp/
# Restaurer la base de données
gunzip -c /tmp/db_20260519_163133.sql.gz | mysql -u root wordpress2023Le script fonctionne-t-il aussi sur Ubuntu ?
Oui, sans modification. Le script est compatible avec toute distribution Debian-based (Ubuntu 22.04, 24.04, Debian 11/12). La seule variable à adapter est DB_NAME selon le nom de ta base de données MariaDB ou MySQL.
Comment recevoir une alerte si le backup échoue ?
Installe mailutils sur ton VPS (apt install mailutils), puis ajoute cette ligne en début de script, juste après le shebang :
trap 'echo "BACKUP ÉCHOUÉ sur $(hostname) le $(date)" | mail -s "ALERTE: Backup WordPress" ton@email.com' ERRwp-dbmanager est-il encore utile après cette configuration ?
Non. Tu peux désactiver ses sauvegardes automatiques dans ses réglages pour éviter de doubler les archives DB localement. Le plugin lui-même peut rester installé pour ses autres fonctionnalités (réparation, optimisation de tables), mais la sauvegarde est maintenant gérée par ton script système.
En résumé
En 20 minutes, tu as mis en place une chaîne de backup qui protège réellement ton WordPress : DB compressée quotidiennement vers Google Drive, fichiers archivés chaque semaine, rotation automatique, log centralisé. Aucun plugin, aucune dépendance à l’état de WordPress lui-même.
L’étape suivante logique pour ton VPS : installer un certificat SSL sur Apache sous Debian si ce n’est pas encore fait. Et si tu veux aller plus loin sur la sécurité de ton infrastructure, retrouve tous nos guides dans la section Systèmes & IT.