Tous les articles
BackupGuide

Sauvegardes VPS : appliquer la règle 3-2-1

Publié le 23 janvier 2024 · 7 min de lecture

Trois copies, deux supports, un site distant

La règle 3-2-1 reste la meilleure synthèse de quarante ans de sinistres informatiques : au moins 3 copies de vos données, sur 2 supports différents, dont 1 hors du site. Appliquons-la à un VPS, concrètement.

Couche 1 : les snapshots hyperviseur

Nos offres incluent des snapshots quotidiens conservés 7 jours. C'est votre filet immédiat : restauration complète en quelques minutes depuis l'espace client. Mais un snapshot hyperviseur a deux limites : il vit dans la même infrastructure que votre VPS, et il capture un état de disque, pas forcément un état cohérent de base de données.

Couche 2 : les dumps applicatifs

La seule sauvegarde de base de données fiable est un export applicatif, réalisé à chaud :

# cron quotidien, 3h15 : dump PostgreSQL compressé et horodaté
15 3 * * * pg_dump -Fc -f /var/backups/app-$(date +%F).dump app

Ajoutez les fichiers applicatifs (uploads, configuration) avec restic ou borg, qui dédupliquent et chiffrent.

Couche 3 : la copie hors site

La copie qui vous sauvera le jour où tout le reste brûle ne doit dépendre d'aucun composant du site principal. Deux options sérieuses :

  • Un second VPS dans un autre datacenter (Paris → Francfort : 12 ms de latence, réplication nocturne sans impact)
  • Un stockage objet, avec chiffrement côté client :
restic -r s3:https://s3.example.com/backups backup /var/backups

Chiffrez toujours avant d'exporter : la copie distante est celle que vous contrôlez le moins.

Le test de restauration, l'étape que 80 % des gens sautent

Une sauvegarde non testée est une hypothèse, pas une sauvegarde. Notre protocole, appliqué à nos propres systèmes :

1. Chaque mois, restaurer une copie sur un VPS jetable (déployé en 55 secondes, supprimé après) 2. Vérifier que l'application démarre et que les données récentes sont présentes 3. Chronométrer : c'est votre RTO réel, pas votre RTO théorique

En interne, environ un test sur douze détecte un problème — cron cassé, disque plein, droits modifiés. Mieux vaut le découvrir ainsi.

Définissez votre RPO avant votre outil

Combien de données pouvez-vous perdre ? Une heure de commandes e-commerce est inacceptable ; une journée d'articles de blog, supportable. Le RPO dicte la fréquence : dumps horaires pour la boutique, quotidiens pour le blog. Le reste n'est que de la plomberie.