Sauvegarder son VPS : stratégies et outils en 2026

Pourquoi sauvegarder son VPS ?

Les scénarios catastrophe sont plus fréquents qu'on ne le pense : suppression accidentelle d'une base de données, ransomware, corruption de fichiers suite à une mise à jour ratée, défaillance matérielle imprévue. Un VPS sans stratégie de sauvegarde peut perdre des mois de travail en quelques secondes. La bonne nouvelle : mettre en place une sauvegarde solide ne prend qu'une heure.

La règle 3-2-1 appliquée au VPS

• 3 copies des données
• 2 supports différents
• 1 copie hors site

Concrètement pour un VPS :

• Données en production (sur le VPS)
• Snapshot chez l'hébergeur (support différent)
• Sauvegarde rsync vers un autre VPS ou stockage objet S3 (hors site)

Les snapshots : rapides mais insuffisants seuls

Un snapshot est une copie de l'état entier du VPS à un instant T. Chez Skorpia, les snapshots sont inclus dans tous les plans VPS et se créent en moins d'une minute sans interruption de service.

Avantages : restauration complète en quelques clics, idéal avant une mise à jour risquée.

Limites : stockés chez le même hébergeur. Si le datacenter a un problème, le snapshot l'a aussi. Ne pas confondre snapshot et sauvegarde hors site.

Rsync : la sauvegarde incrémentale vers un site distant

Rsync ne transfère que les fichiers modifiés depuis la dernière sauvegarde. C'est le meilleur outil pour les sauvegardes régulières :

# Sauvegarde du dossier /var/www vers un VPS de backup
rsync -avz --delete /var/www/ user@backup-server:/backups/vps-prod/www/

# Sauvegarder une base de données MariaDB via dump
mysqldump -u root -p --all-databases | gzip > /tmp/db_backup.sql.gz
rsync -avz /tmp/db_backup.sql.gz user@backup-server:/backups/vps-prod/

Automatiser avec cron

Créez un script /usr/local/bin/backup.sh :

#!/bin/bash
DATE=$(date +%Y%m%d_%H%M)
BACKUP_DIR="/backups/$DATE"

# Dump base de données
mkdir -p $BACKUP_DIR
mysqldump -u root -p"motdepasse" --all-databases | gzip > "$BACKUP_DIR/db.sql.gz"

# Rsync vers serveur distant
rsync -avz --delete /var/www/ user@backup-server:/backups/www/
rsync -avz "$BACKUP_DIR/" user@backup-server:/backups/db/

# Nettoyage des backups locaux de plus de 7 jours
find /backups -mtime +7 -type d -exec rm -rf {} +

echo "Backup terminé : $DATE" | mail -s "Backup VPS OK" votre@email.com

chmod +x /usr/local/bin/backup.sh

Programmez via cron : crontab -e

# Tous les jours à 3h00
0 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

Sauvegarder vers un stockage objet (S3)

Pour un stockage hors site économique, les solutions compatibles S3 (AWS S3, Scaleway Object Storage, OVH Object Storage) sont idéales :

apt install s3cmd -y
s3cmd --configure   # entrez vos credentials

# Sauvegarde vers un bucket S3
s3cmd put /tmp/db_backup.sql.gz s3://mon-bucket/backups/

Tester ses sauvegardes régulièrement

Une sauvegarde non testée est une fausse sécurité. Planifiez un test de restauration mensuel :

1. Créez un VPS de test temporaire
2. Restaurez votre backup complet
3. Vérifiez que l'application fonctionne correctement
4. Supprimez le VPS de test

Ce processus prend 30 minutes et vous évitera une mauvaise surprise le jour où vous en aurez vraiment besoin.