Aller au contenu
Retour au glossaire
Continuité d'activité

Qu'est-ce que RPO (Recovery Point Objective) ?

Le RPO est la quantité maximale de données acceptable à perdre après un sinistre. Indicateur jumeau du RTO dans tout plan de reprise.

À quoi sert le RPO

Le Recovery Point Objective (RPO) est l'engagement de quantité maximale de données acceptable à perdre entre le dernier point de sauvegarde valide et le moment d'un sinistre. Exprimé en durée (5 minutes, 1 heure, 24 heures), il dimensionne directement la stratégie de sauvegarde et de réplication.

Concrètement, un RPO de 1 heure signifie : en cas de perte totale, l'organisation accepte de perdre au maximum 60 minutes de données récentes. Cela implique une sauvegarde ou une réplication au moins toutes les heures. Un RPO de 5 minutes implique une réplication quasi temps-réel (synchrone ou asynchrone à faible latence). Un RPO de 24 heures permet une simple sauvegarde nocturne.

Comment fixer un RPO réaliste

Comme le RTO, le RPO est une décision business. Trois questions guident l'arbitrage :

  1. Quelle est la valeur d'une heure de données perdues ? Une transaction bancaire perdue est inacceptable. Une saisie de tableau de bord interne peut être ressaisie. Le RPO se calibre par criticité.

  2. Quel est le coût d'un RPO court ? Diviser un RPO par 10 (24h vers 2h) augmente le coût de stockage de 3 à 5 fois ; passer d'un RPO de 1h à 5 minutes multiplie typiquement les coûts d'infrastructure par 2 à 4 (réplication synchrone, redondance multi-zone).

  3. Quelles sont les contraintes réglementaires ? La FINMA exige un RPO documenté pour les institutions financières suisses. La nLPD impose une protection adéquate proportionnée à la sensibilité des données.

RPO et types de stockage

Catégorisation typique :

  • RPO < 1 seconde : réplication synchrone multi-zone (Postgres streaming replication synchrone, Galera Cluster). Toute écriture est confirmée seulement après réplication. Latence accrue mais aucune perte possible.
  • RPO < 5 minutes : réplication asynchrone avec WAL shipping fréquent. La majorité des SGBD professionnels (Postgres, MySQL, MongoDB) atteignent ce niveau sans difficulté.
  • RPO 1 heure : snapshots horaires automatisés vers stockage objet (S3-compatible) avec versioning. Standard sur les workloads non critiques.
  • RPO 24 heures : sauvegardes nocturnes traditionnelles. Compatible avec une politique de rétention 30/90/365 jours.

RPO dans le contexte Kubernetes

Sur Kubernetes, le RPO se gère à trois niveaux distincts :

  • PersistentVolumes : snapshots CSI configurables par StorageClass (Ceph, Longhorn, EBS, etc.). Fréquence ajustable de 5 min à 24h.
  • Bases de données managées : Hikube, AWS RDS, Azure Database proposent des Point-in-Time Recovery (PITR) avec RPO de quelques secondes via WAL continuous archiving.
  • État Kubernetes : etcd doit être sauvegardé séparément avec un RPO court (15 min typique) car sa perte rend le cluster inopérant.

Le piège du RPO théorique

Un RPO documenté qui n'a jamais été testé en restauration réelle vaut zéro. Sur nos missions Hidora, nous observons régulièrement des clients avec des politiques de sauvegarde de 5 ans qui découvrent, lors du premier test de restauration, qu'un fichier de configuration manquant fait échouer la procédure. La règle : tester la restauration au minimum tous les 3 mois, documenter chaque échec, intégrer les corrections au runbook.

Services Hidora associés

  • SLA Expert : engagements RPO contractuels avec mesure mensuelle et rapport de conformité.
  • Consulting : audit des politiques de sauvegarde, calibration du RPO par criticité applicative, tests de restauration.
  • Managed Services : exploitation des sauvegardes et réplications avec dashboards de couverture RPO.
  • RTO, DRP, Observabilité : indicateurs et processus associés.