On affiche un RTO (Recovery Time Objective) de 4 minutes sur nos pages. Ce n’est pas une promesse marketing, c’est une mesure. Voici comment on la teste.

Le setup

Une VM WordPress de test, dimensionnée comme un site client moyen : 4 vCPU, 8 Go RAM, 80 Go de disque, base MySQL avec 2 millions de lignes, 12 Go de fichiers uploads. Tout ça stocké sur un pool ZFS RAID-Z2 en NVMe Gen4.

On simule un incident : suppression accidentelle de la VM. Démarrage du chrono à l’instant où l’incident est détecté.

Le runbook

00:00  ↳ Incident détecté (alerte Prometheus)
00:08  ↳ Astreinte notifiée (PagerDuty)
00:35  ↳ Connexion sysadmin au cluster Proxmox
00:42  ↳ Identification du dernier snapshot valide
          (ZFS snapshot horaire — 38 minutes avant)
01:05  ↳ Lancement du clone ZFS du snapshot
01:12  ↳ Création de la VM cible depuis le clone
01:50  ↳ Reconfiguration réseau (VLAN, IP)
02:30  ↳ Démarrage de la VM
03:10  ↳ Vérification healthcheck WordPress
03:35  ↳ Bascule DNS (TTL 60s)
03:47  ↳ Site accessible ✓

Pourquoi c’est rapide

Le secret n’est pas magique : c’est ZFS et les snapshots copy-on-write. Quand on fait un snapshot, ZFS ne copie rien. Il marque juste l’état actuel des blocs. Restaurer un snapshot, c’est juste pointer vers ces blocs marqués — pas une copie physique.

Le clone ZFS, c’est encore plus malin : il crée un nouveau volume partagé avec le snapshot, qui ne consomme de l’espace que pour les blocs qui divergent. Concrètement, créer un clone de 80 Go prend 7 secondes.

Les RPO selon les niveaux

RPO (Recovery Point Objective) = quantité maximale de données perdues acceptable. Chez nous :

  • Standard : snapshot toutes les heures → RPO 1h max
  • Pro / dédié : snapshot toutes les 15 minutes → RPO 15 min
  • Sur-mesure : réplication continue possible → RPO < 1 min

Et si tout le cluster brûle ?

Là, on ne parle plus de snapshot local. On parle de la sauvegarde distante S3 Scaleway. Restaurer une VM depuis S3, c’est plus long : compter 30 à 90 minutes selon la taille (la limite étant la bande passante de téléchargement). Mais l’événement “datacenter entier indisponible” est rare et planifiable — pas un incident d’astreinte.

Pour les clients qui ont besoin d’une vraie résilience multi-DC en temps réel, on bascule sur une architecture sur-mesure (réplication active/active). Mais c’est un autre niveau de prix.