Une stratégie de sauvegarde pour votre VPS

Une bonne stratégie de sauvegarde VPS repose sur trois couches : des sauvegardes automatiques du serveur pour des restaurations complètes rapides, des dumps applicatifs pour les bases de données, et une copie externe chiffrée sur un second site. Ajoutez un instantané avant chaque modification risquée et testez régulièrement une restauration : une sauvegarde jamais testée n'est qu'un espoir.

Ce guide détaille chaque couche, avec les commandes pour Ubuntu 24.04 et Debian 12.

Partir de la règle 3-2-1

La règle classique tient toujours :

• 3 copies de vos données (la version en production plus deux sauvegardes),
• sur 2 types de stockage ou systèmes différents,
• dont 1 hors site, sur un autre site ou chez un autre fournisseur.

Sur un VPS, cela signifie généralement : le serveur lui-même, les sauvegardes de l'hébergeur et une copie chiffrée ailleurs.

Savoir contre quoi vous vous protégez

Des risques différents appellent des couches différentes. C'est pourquoi une seule méthode ne suffit jamais pour des données importantes.

Couche 1 : sauvegardes et instantanés de l'hébergeur

Sauvegardes automatiques

Chez Wolkra, vous pouvez activer des sauvegardes automatiques quotidiennes par serveur. Elles coûtent 20 % du prix du serveur et conservent 7 points de restauration. Une sauvegarde capture le serveur entier : une restauration ramène ensemble le système, la configuration et les données. C'est le moyen le plus rapide de revenir en arrière après une erreur sérieuse.

Instantanés

Les instantanés se créent à la demande et sont facturés au Go. Utilisez-les :

• avant de mettre à niveau le système, une base de données ou une version majeure d'application ;
• avant d'expérimenter sur les paramètres de pare-feu ou de réseau ;
• comme modèle : vous pouvez créer de nouveaux serveurs à partir d'un instantané.

Voir sauvegardes et instantanés et la documentation pour les étapes.

Des copies au niveau disque cohérentes

Sauvegarder un serveur en marche revient à débrancher la prise : les fichiers sont cohérents au niveau du système de fichiers, mais une base de données en pleine écriture peut avoir besoin d'une récupération. Les bases de données sont conçues pour cela, mais un dump propre (couche 2) lève le doute.

Couche 2 : dumps applicatifs

PostgreSQL

sudo mkdir -p /var/backups/db && sudo chown postgres: /var/backups/db
sudo -u postgres sh -c 'pg_dump -Fc mydb > /var/backups/db/mydb-$(date +%F-%H%M).dump'

-Fc correspond au format personnalisé compressé ; restaurez-le avec pg_restore.

MariaDB ou MySQL

sudo sh -c 'mariadb-dump --single-transaction --routines --all-databases | gzip > /var/backups/db/all-$(date +%F-%H%M).sql.gz'

--single-transaction produit un dump cohérent des tables InnoDB sans les verrouiller.

Avec Docker

docker compose exec -T db pg_dump -U app app | gzip > ~/backups/app-$(date +%F).sql.gz

Planifier et faire le ménage

Placez le dump dans un script lancé par un timer systemd ou par cron, puis supprimez les anciens fichiers :

find /var/backups/db -type f -mtime +14 -delete

Couche 3 : copies externes chiffrées avec restic

restic chiffre, déduplique et envoie les sauvegardes vers de nombreuses cibles : un autre serveur via SFTP, ou n'importe quel stockage objet compatible S3.

Installer

sudo apt install -y restic

Choisir un dépôt

Les exemples utilisent SFTP vers un serveur de sauvegarde que vous contrôlez. Un bucket compatible S3 fonctionne de la même manière, avec des URL de dépôt s3: et les identifiants dans des variables d'environnement.

sudo mkdir -p /etc/restic && sudo chmod 700 /etc/restic
openssl rand -base64 32 | sudo tee /etc/restic/password >/dev/null
sudo chmod 600 /etc/restic/password

sudo tee /etc/restic/env >/dev/null <<'EOF'
RESTIC_REPOSITORY=sftp:[email protected]:/srv/restic/web-1
RESTIC_PASSWORD_FILE=/etc/restic/password
EOF
sudo chmod 600 /etc/restic/env

Root a besoin d'une clé SSH capable de se connecter à backup.example.com (voir clés SSH). Conservez aussi le mot de passe restic hors du serveur. Sans lui, personne ne peut lire les sauvegardes, vous compris.

Initialiser et lancer

sudo bash -c 'set -a; . /etc/restic/env; restic init'
sudo bash -c 'set -a; . /etc/restic/env; restic backup /etc /var/www /var/backups/db /home --exclude-caches'
sudo bash -c 'set -a; . /etc/restic/env; restic snapshots'

Rétention

sudo bash -c 'set -a; . /etc/restic/env; restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune'

Vous conservez ainsi une semaine de sauvegardes quotidiennes, un mois d'hebdomadaires et six mois de mensuelles.

Automatiser avec un timer systemd

/etc/systemd/system/restic-backup.service :

[Unit]
Description=restic backup
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
EnvironmentFile=/etc/restic/env
ExecStart=/usr/bin/restic backup /etc /var/www /var/backups/db /home --exclude-caches
ExecStartPost=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

/etc/systemd/system/restic-backup.timer :

[Unit]
Description=Nightly restic backup

[Timer]
OnCalendar=*-*-* 03:30
RandomizedDelaySec=15m
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
systemctl list-timers restic-backup.timer

Lancez le dump de base de données avant restic, par exemple avec une ligne ExecStartPre= qui appelle votre script de dump.

Se protéger contre un serveur compromis

Si un attaquant obtient les droits root, il peut supprimer les sauvegardes accessibles depuis le serveur. Réduisez ce risque :

• donnez à l'utilisateur de sauvegarde sur la cible un accès en ajout seul quand l'outil le permet (le serveur REST de restic dispose d'un mode --append-only) ;
• lancez la purge depuis une autre machine ;
• conservez au moins une copie dans un endroit pour lequel le serveur ne possède aucun identifiant.

Que sauvegarder

• /etc pour la configuration.
• Le code de l'application et les fichiers envoyés : /var/www, /srv, /opt ou le répertoire de votre application.
• Les dumps de bases de données, pas les fichiers bruts de la base.
• Les volumes Docker des conteneurs avec état, ou leurs dumps.
• Les secrets TLS et applicatifs, chiffrés.
• Un court README qui explique comment reconstruire le serveur.

En général, inutile de sauvegarder /var/cache, /tmp, les caches de paquets ou les couches d'images Docker qu'on peut retélécharger.

Volumes de stockage en bloc

Si vos données résident sur un volume de stockage en bloc, le volume peut être détaché puis attaché à un nouveau serveur, ce qui aide en cas de panne du serveur. Cela reste une seule copie : incluez-le dans restic ou dans vos dumps comme n'importe quelle autre donnée.

Tester la restauration

Fixez un rythme, par exemple mensuel, et faites l'un des tests suivants :

1. Serveur complet : créez un nouveau serveur à partir d'une sauvegarde ou d'un instantané, démarrez-le sous un nom de test et vérifiez que l'application fonctionne.
2. Fichiers : restaurez dans un répertoire temporaire et comparez.

sudo bash -c 'set -a; . /etc/restic/env; restic restore latest --target /tmp/restore-test --include /etc/caddy'
sudo bash -c 'set -a; . /etc/restic/env; restic check'

3. Base de données : chargez un dump dans une base vierge et lancez quelques requêtes.

Avec la facturation à l'heure, un serveur de test de restauration pendant une heure coûte très peu. Notez la durée de la restauration : c'est votre véritable temps de reprise.

Un plan simple à reprendre

Adaptez ces chiffres à la quantité de données que vous pouvez vous permettre de perdre et à la vitesse à laquelle vous devez être de retour en ligne. Pour le reste de la configuration du serveur, voir premiers pas sur un nouveau VPS et comment sécuriser un serveur Ubuntu.