Une sauvegarde stockée sur le même disque que le site qu’elle protège ne protège de rien en cas de panne matérielle du serveur. C’est le constat de départ qui a motivé la mise en place d’une sauvegarde externalisée automatique, sans passer par une extension commerciale de sauvegarde, pour un site WordPress hébergé sur un VPS géré directement par l’équipe technique.
Scaleway propose, avec son offre Object Storage, un espace de stockage compatible avec l’API S3 d’Amazon, ce qui permet d’utiliser des outils standards, y compris en ligne de commande, sans dépendre d’un service tiers spécifique à WordPress.
Ce que le script doit accomplir chaque nuit
La sauvegarde se compose de deux éléments distincts, gérés séparément : un export de la base de données MySQL, et une archive du dossier wp-content/uploads contenant les médias. Séparer les deux permet de restaurer l’un sans nécessairement toucher à l’autre, et réduit la taille de chaque transfert individuel.
- Export de la base de données via
mysqldump, compressé immédiatement - Archive du dossier des médias via
tar - Envoi des deux fichiers vers le bucket Object Storage via l’outil
s3cmd - Suppression des sauvegardes locales de plus de trois jours
Le script complet
#!/bin/bash
DATE=$(date +%Y-%m-%d)
DEST=/var/backups/wordpress
SITE=/var/www/exemple-site.fr
mkdir -p "$DEST"
mysqldump --single-transaction -u backup_user -p"$MYSQL_PWD" wordpress_db \
| gzip > "$DEST/db-$DATE.sql.gz"
tar czf "$DEST/uploads-$DATE.tar.gz" -C "$SITE/web/app" uploads
s3cmd put "$DEST/db-$DATE.sql.gz" s3://sauvegardes-exemple/db/
s3cmd put "$DEST/uploads-$DATE.tar.gz" s3://sauvegardes-exemple/uploads/
find "$DEST" -type f -mtime +3 -delete
Configurer l’accès à Object Storage
L’outil s3cmd nécessite une configuration préalable, réalisée une seule fois via s3cmd --configure, avec l’URL du point de terminaison propre à la région Scaleway utilisée et les clés d’accès générées depuis la console. Il est recommandé de créer une clé d’accès dédiée à cet usage, avec des droits limités au bucket concerné, plutôt que de réutiliser une clé disposant d’un accès complet au compte.
host_base = s3.fr-par.scw.cloud
host_bucket = %(bucket)s.s3.fr-par.scw.cloud
access_key = SCWXXXXXXXXXXXXXXXXX
secret_key = ***
use_https = TruePlanifier l’exécution avec un vrai cron système
Le script est appelé chaque nuit via une entrée dans la table cron du serveur, indépendamment de WordPress lui-même, ce qui garantit son exécution même si le site rencontre un problème quelconque au même moment :
0 3 * * * /usr/local/bin/sauvegarde-wordpress.sh >> /var/log/sauvegarde-wordpress.log 2>&1Une sauvegarde qu’on n’a jamais essayé de restaurer n’est qu’une hypothèse de sauvegarde. Après la mise en place de ce script, un test de restauration complet sur un environnement séparé a permis de confirmer que les archives générées étaient réellement exploitables.
Surveiller que la sauvegarde s’exécute réellement
Un script cron qui échoue silencieusement est presque pire qu’une absence totale de sauvegarde, car il donne une fausse impression de sécurité. Une vérification simple, ajoutée après coup, consiste à contrôler la présence du fichier du jour dans le bucket via une commande s3cmd ls, avec une alerte envoyée si le fichier attendu n’apparaît pas dans un délai raisonnable après l’heure prévue d’exécution.
Gérer aussi la rétention côté Object Storage
Conserver indéfiniment toutes les archives envoyées finirait par représenter un coût de stockage croissant, sans bénéfice supplémentaire au-delà d’une certaine ancienneté. Une règle de cycle de vie a donc été configurée directement sur le bucket, via la console Scaleway, pour supprimer automatiquement les objets de plus de trente jours, indépendamment du nettoyage local déjà réalisé par le script.
- Conservation de trente jours glissants sur le bucket distant
- Conservation de trois jours seulement en local, le temps de sécuriser l’envoi
- Une sauvegarde mensuelle supplémentaire, exclue de cette règle de purge, conservée un an
Pour aller plus loin
Ce dispositif, entièrement composé d’outils standards — mysqldump, tar, s3cmd, et un cron système — offre un contrôle total sur le format et la fréquence des sauvegardes, sans dépendre du fonctionnement interne d’une extension WordPress tierce. Il demande en contrepartie une rigueur de maintenance assumée par l’équipe elle-même, notamment sur la rotation des clés d’accès et la vérification périodique des restaurations.
