# Automatiser une sauvegarde vers Scaleway Object Storage avec un cron

> Sans extension commerciale, un script bash, un cron système et un espace de stockage compatible S3 suffisent à externaliser correctement les sauvegardes d'un site.

- Auteur : WordPress Développement
- Publié le : 2021-05-13
- Mis à jour le : 2021-05-13
- Catégorie : Hébergement & serveurs
- URL : https://www.wpmoderne.fr/hebergement/automatiser-sauvegarde-scaleway-object-storage-cron/

## L’essentiel

- Une sauvegarde locale ne protège pas contre une panne du serveur lui-même
- Object Storage de Scaleway expose une API compatible S3
- mysqldump et un simple script bash suffisent, sans extension payante

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
```

> L'essentiel à retenir : Une sauvegarde locale ne protège pas contre une panne du serveur lui-même ; Object Storage de Scaleway expose une API compatible S3 ; mysqldump et un simple script bash suffisent, sans extension payante

## 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 = True
```

## Planifier 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>&1
```

> Une 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.