Une stratégie de sauvegarde VPS pratique (règle 3-2-1)

Écrit par l'équipe ApexVPS • Dernière mise à jour : juillet 2026 • 7 min de lecture

Une stratégie de sauvegarde VPS fiable fait la différence entre une récupération en cinq minutes et une très mauvaise semaine. Les serveurs tombent en panne, les disques se corrompent, les déploiements échouent, et une seule commande mal tapée peut effacer un répertoire. Le Centre d'apprentissage Cloudflare et la plupart des équipes d'infrastructure recommandent la même discipline simple : la règle 3-2-1. Ce guide montre comment l'appliquer à un vrai serveur virtuel, quels outils utiliser, et comment planifier et tester tout cela pour qu'une restauration fonctionne réellement quand vous en avez besoin.

Ce que signifie la règle 3-2-1

La règle 3-2-1 est un principe de sauvegarde vieux de plusieurs décennies qui reste vrai, quel que soit l'endroit où vit votre serveur :

• 3 copies de vos données — la copie en direct plus au moins deux sauvegardes.
• 2 supports de stockage ou systèmes de médias différents — ainsi une seule panne ne peut pas détruire les deux copies à la fois.
• 1 copie hors site — physiquement ou logiquement séparée de la machine que vous protégez.

Sur un VPS, cela signifie généralement votre serveur en fonctionnement, un référentiel de sauvegarde local et une copie chiffrée poussée vers un stockage distant dans un autre lieu. Le but est la redondance sans point de défaillance unique partagé.

Que sauvegarder sur un VPS

Sauvegarder tout le disque bloc par bloc est inutile et lent. Un bon plan de sauvegarde cible les trois éléments qui sont vraiment difficiles à recréer.

Données applicatives et fichiers

Fichiers téléchargés, racines de sites web, volumes de conteneurs et tout ce que les utilisateurs génèrent. Les chemins typiques incluent /var/www, /srv, /home et votre répertoire de volumes Docker. Si vous hébergez des applications comme un serveur de fichiers ou un wiki, c'est là que vit votre contenu irremplaçable — consultez notre guide pour faire tourner un VPS pour l'auto-hébergement pour voir comment ces répertoires sont généralement organisés.

Bases de données

Ne copiez jamais les fichiers de base de données en direct pendant que le service fonctionne — vous pourriez capturer un état corrompu et à moitié écrit. Au lieu de cela, exportez un dump cohérent. Pour MySQL ou MariaDB :

mysqldump --single-transaction --routines --triggers \
  -u backup -p mydatabase > /srv/backups/mydatabase.sql

Le drapeau --single-transaction donne un instantané cohérent des tables InnoDB sans les verrouiller. Pour PostgreSQL, utilisez pg_dump à la place :

pg_dump -U postgres -Fc mydatabase > /srv/backups/mydatabase.dump

Configuration système et des services

Les fichiers qui rendent votre serveur unique : /etc (nginx, unités systemd, cron, configuration SSH), listes de paquets, certificats TLS et règles de pare-feu. Reconstruire cela de mémoire après une panne est exactement le travail fastidieux que les sauvegardes existent pour éviter.

Choisir vos outils de sauvegarde

Trois outils couvrent presque tous les cas de VPS. Choisissez en fonction de votre besoin de déduplication et de chiffrement.

restic — instantanés chiffrés et dédupliqués

restic est un outil de sauvegarde moderne, à binaire unique, qui chiffre et déduplique par défaut. Initialisez un référentiel une fois, puis exécutez des sauvegardes contre lui :

# One-time: create an encrypted repository
restic init --repo /srv/backups/restic

# Back up files and your database dump
restic -r /srv/backups/restic backup /etc /var/www /srv/backups/mydatabase.sql

# List what you have
restic -r /srv/backups/restic snapshots

BorgBackup — archives avec déduplication

BorgBackup offre une déduplication et une compression similaires avec un flux de travail légèrement différent :

borg init --encryption=repokey /srv/backups/borg
borg create --stats /srv/backups/borg::'{hostname}-{now}' /etc /var/www

rsync — simple miroir de fichiers

Quand vous avez juste besoin d'un miroir rapide de fichiers vers un autre hôte, rsync via SSH est difficile à battre :

rsync -aAX --delete /var/www/ [email protected]:/backups/www/

Les drapeaux -aAX préservent les permissions, les ACL et les attributs étendus ; --delete garde le miroir en phase avec la source. rsync seul ne versionne pas l'historique, c'est pourquoi de nombreuses équipes l'associent à restic ou borg.

Automatisez le planning avec cron

Une sauvegarde que vous devez penser à exécuter est une sauvegarde qui n'arrivera pas. Mettez vos étapes dans un script, rendez-le exécutable et planifiez-le avec cron. Modifiez votre crontab avec :

crontab -e

Ensuite, ajoutez des lignes comme celles-ci :

# Full file + config backup every night at 02:15
15 2 * * * /usr/local/bin/vps-backup.sh

# Database dump every hour on the hour
0 * * * * /usr/local/bin/db-dump.sh

Journalisez la sortie et faites en sorte que le script se termine avec un code non nul en cas d'échec afin de pouvoir le connecter aux fonctionnalités de surveillance et d'alerte incluses dans votre plan. Un échec de sauvegarde silencieux est pire que pas de sauvegarde, car il donne une fausse sécurité.

Conservez une vraie copie hors site

Le « 1 » dans 3-2-1 est la partie que la plupart des gens sautent. Une sauvegarde qui repose sur le même serveur qu'elle protège disparaît avec ce serveur. Poussez une copie chiffrée vers un endroit indépendant — stockage d'objets, boîte SFTP distante ou autre fournisseur. restic et borg écrivent tous deux directement vers des référentiels distants, par exemple via SFTP :

restic -r sftp:[email protected]:/backups/restic backup /var/www

Parce que restic et borg chiffrent avant que les données ne quittent votre VPS, l'hôte distant ne voit jamais votre texte en clair. Purgez les anciens instantanés selon une politique afin que le stockage ne croisse pas indéfiniment :

restic -r /srv/backups/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Testez vos restaurations — à chaque fois

Une sauvegarde non testée est une rumeur. Planifiez une restauration périodique dans un emplacement jetable et confirmez que les fichiers et les bases de données reviennent intacts :

# Restore the latest snapshot into a scratch directory
restic -r /srv/backups/restic restore latest --target /tmp/restore-test

# Verify repository integrity
restic -r /srv/backups/restic check

# Re-import a database dump into a scratch database
mysql -u root -p restore_test < /srv/backups/mydatabase.sql

Si la restauration réussit et que les données correspondent, vous avez une stratégie. Si ce n'est pas le cas, vous venez d'apprendre cela un mardi après-midi plutôt que lors d'une véritable panne.

Les instantanés ne sont qu'une couche, pas la stratégie complète

Chaque offre ApexVPS comprend des sauvegardes automatisées — des instantanés quotidiens sur Starter Pro et des instantanés horaires sur Business — et ils sont vraiment utiles pour des retours en arrière rapides après un mauvais déploiement ou une suppression accidentelle. Mais soyons honnêtes sur ce qu'ils sont : une couche première pratique qui réside sur notre plateforme. Ils ne remplacent pas la copie hors site, vérifiée de manière indépendante, exigée par la règle 3-2-1. Considérez les instantanés de la plateforme comme votre point de restauration local rapide, et exécutez votre propre tâche restic ou borg pour satisfaire les parties hors site et de restauration testée de la règle. Cette approche en couches est ce qui distingue une configuration pleine d'espoir d'une configuration résiliente, que vous hébergiez des applications comme Nextcloud ou que vous exploitiez une base de données en production.

Votre liste de contrôle pour la stratégie de sauvegarde VPS

En rassemblant les pièces, une stratégie de sauvegarde complète pour un serveur virtuel ressemble à ceci. Parcourez-la une fois, scriptez-la, et laissez cron la faire avancer :

• Identifiez ce qui compte — fichiers d'application, dumps de base de données, et la configuration sous /etc.
• Choisissez un outil — restic ou BorgBackup pour des sauvegardes chiffrées, dédupliquées et versionnées ; rsync pour des miroirs simples.
• Effectuez des dumps de base de données cohérents — mysqldump --single-transaction ou pg_dump, jamais une copie brute des fichiers en direct.
• Automatisez — planifiez le script avec cron et alertez sur toute sortie non nulle.
• Poussez une copie hors site — chiffrée, sur un stockage indépendant, avec une politique de conservation judicieuse.
• Testez régulièrement les restaurations — restaurez dans un emplacement temporaire et confirmez que les données sont intactes.

Faites ces six choses et la règle 3-2-1 cesse d'être une théorie et devient une habitude sur laquelle votre infrastructure peut s'appuyer. L'heure de configuration initiale est négligeable par rapport au coût de découvrir, en plein incident, que votre seule copie se trouvait sur le disque qui vient de mourir.

Questions fréquemment posées

Les instantanés du fournisseur comptent-ils comme une stratégie de sauvegarde ?

Les instantanés sont une couche utile, mais pas une stratégie complète. Nos instantanés quotidiens et horaires protègent contre la plupart des erreurs à court terme, mais ils résident sur la même plateforme que votre serveur. Une stratégie de sauvegarde 3-2-1 complète nécessite toujours une copie indépendante hors site que vous contrôlez et des restaurations que vous avez réellement testées.

À quelle fréquence dois-je sauvegarder un VPS ?

Faites correspondre la fréquence à la quantité de données que vous pouvez vous permettre de perdre. Les fichiers statiques et les configurations peuvent être sauvegardés quotidiennement, tandis que les bases de données actives justifient souvent des dumps horaires. Utilisez cron pour automatiser le calendrier afin que les sauvegardes ne dépendent jamais du fait de s'en souvenir.

Quel est le meilleur outil pour les sauvegardes VPS ?

restic et BorgBackup sont tous deux excellents : ils dédupliquent, compressent et chiffrent les sauvegardes, et prennent en charge les dépôts hors site. rsync convient pour la mise en miroir simple de fichiers, et mysqldump ou pg_dump gèrent les exportations de bases de données. De nombreuses configurations combinent un dump de base de données avec une exécution restic ou borg.

Comment savoir si mes sauvegardes fonctionnent réellement ?

Testez les restaurations selon un calendrier. Restaurez dans un répertoire temporaire, vérifiez le contenu des fichiers et les sommes de contrôle, et importez un dump de base de données dans une base de données de test. Une sauvegarde que vous n'avez jamais restaurée n'est qu'une supposition optimiste, pas un plan de récupération.