RPO et RTO : définition et calcul

Le RPO (Recovery Point Objective) est la quantité maximale de données qu'on accepte de perdre, exprimée en temps : avec un RPO de 4 heures, on accepte de perdre au plus les 4 dernières heures de travail. Le RTO (Recovery Time Objective) est la durée maximale d'interruption acceptée : avec un RTO de 8 heures, le service doit être rétabli au plus tard 8 heures après l'incident. En français, l'ANSSI parle de PDMA (perte de données maximale admissible) et de DMIA (durée maximale d'interruption admissible). Ces deux objectifs viennent du métier, et ils décident de tout le reste : la fréquence des sauvegardes, le support, l'architecture de secours et le budget.

Le RPO regarde en arrière (les données perdues), le RTO regarde en avant (le temps d'arrêt)

Le RPO : combien de données on accepte de perdre

Le RPO répond à la question : « si tout s'arrête maintenant, jusqu'à quand pouvons-nous revenir ? ». Il se mesure en temps, parce que la perte est faite de tout ce qui a été saisi depuis le dernier point de restauration.

Un RPO de 24 heures se satisfait d'une sauvegarde nocturne : on accepte de ressaisir une journée.
Un RPO de 1 heure demande une sauvegarde plus fréquente qu'horaire (toutes les 45 minutes si elle dure 15 minutes), ou une sauvegarde des journaux de transactions de la base.
Un RPO proche de zéro ne s'obtient pas par la sauvegarde : il faut une réplication, synchrone pour zéro perte, asynchrone pour quelques secondes ou minutes. L'ANSSI range d'ailleurs le besoin d'une perte de données maximale admissible de moins de 24 heures parmi les cas que la sauvegarde ne couvre pas à elle seule, et conseille alors de privilégier la réplication, synchrone ou asynchrone. Des sauvegardes plus fréquentes ou des journaux de transactions réduisent aussi la perte, au prix d'une exploitation plus lourde.

Le RPO pilote donc la fréquence.

Le RTO : en combien de temps on doit repartir

Le RTO répond à la question : « combien de temps l'activité peut-elle se passer de ce service ? ». Il pilote la méthode de reprise : support rapide ou lent, serveur de secours prêt ou à commander, procédure répétée ou improvisée.

Un RTO de plusieurs jours se contente de restaurer sur du matériel racheté.
Un RTO de quelques heures demande une sauvegarde proche (sur site), un serveur ou un hyperviseur capable d'accueillir la restauration, et une procédure écrite et testée.
Un RTO de quelques minutes demande une infrastructure de secours qui tourne déjà : réplique prête à démarrer, cluster qui bascule seul. On parle alors de haute disponibilité et de PCA (chapitre 12).

Calculer le RPO réel d'un plan de sauvegarde

Le RPO est un objectif ; le plan de sauvegarde donne une perte réelle, qu'il faut comparer à l'objectif. La perte maximale n'est pas toujours l'intervalle entre deux sauvegardes.

Prenons SRV-ERP, sauvegardé toutes les 4 heures (0 h, 4 h, 8 h, 12 h, 16 h, 20 h), chaque sauvegarde durant 30 minutes. Le point de restauration est l'instant où la sauvegarde commence à lire les données.

Panne à 11 h : la sauvegarde de 8 h est terminée depuis 8 h 30. On revient à 8 h, on perd 3 heures.
Panne à 12 h 20 : la sauvegarde de 12 h est en cours, donc inutilisable. On revient à 8 h, on perd 4 h 20.
Pire cas : une panne juste avant la fin d'une sauvegarde, à 12 h 29. On perd 4 h 29, presque l'intervalle plus la durée de la sauvegarde.

perte maximale ≈ intervalle entre deux sauvegardes + durée d'une sauvegarde

Et si une sauvegarde échoue sans que personne ne s'en aperçoive, la perte double : on revient deux points en arrière. C'est pourquoi la supervision des sauvegardes fait partie du plan (chapitre 11).

Calculer le RTO réel : additionner les étapes

Le RTO réel est la somme de toutes les étapes de la reprise, et la restauration elle-même n'en est qu'une. Pour SRV-FIC, qui contient maintenant 540 Go, voici une estimation :

Étape	Durée	Ce qui la conditionne
Détecter l'incident	15 min	Une supervision qui alerte, plutôt qu'un appel d'utilisateur
Décider de restaurer, prévenir	15 min	Une procédure claire : qui décide, qui fait
Préparer la cible (VM vide sur l'hyperviseur)	30 min	Un hyperviseur qui a de la place, un modèle prêt
Restaurer 540 Go à 150 Mo/s	1 h	540 000 Mo ÷ 150 Mo/s = 3 600 s
Vérifier (droits, partages, fichiers témoins)	30 min	Une liste de contrôles écrite à l'avance
Total	2 h 30

Si la seule copie disponible est dans le cloud, téléchargée à 100 Mbit/s, soit 12,5 Mo/s, la restauration seule prend 540 000 ÷ 12,5 = 43 200 s, soit 12 heures, et le RTO réel passe à 13 h 30. Le choix du support décide du RTO (chapitre 5).

RPO, RTO, SLA et coût

Le lien avec le SLA. Un contrat de service (SLA) promet une disponibilité, par exemple 99,5 % sur le mois. Sur 30 jours en continu, cela tolère 0,5 % de 720 heures, soit 3 h 36 min d'arrêt. Si le RTO du service est de 4 heures, un seul incident sérieux suffit à rompre l'engagement. Le RTO doit donc être cohérent avec la disponibilité promise. Le calcul de la disponibilité et ses pièges sont détaillés dans le chapitre SLA, OLA et contrat de service du cours ITIL.

Disponibilité promise	Arrêt toléré sur 30 jours	Arrêt toléré sur 365 jours
99 %	7 h 12 min	3 j 15 h 36 min
99,5 %	3 h 36 min	1 j 19 h 48 min
99,9 %	43 min 12 s	8 h 45 min 36 s
99,99 %	4 min 19 s	52 min 34 s

Le lien avec le coût. Réduire le RPO et le RTO coûte de plus en plus cher : passer de 24 heures à 4 heures demande un meilleur outil et une procédure ; passer de 4 heures à quelques minutes demande une infrastructure doublée qui tourne en permanence. La bonne question n'est pas « quel est le meilleur RTO ? » mais « combien coûte une heure d'arrêt, et combien coûte chaque heure gagnée ? ».

Chez Alvéa, l'arrêt de l'ERP bloque la préparation des commandes : on l'estime à 1 500 € par heure. Avec un RTO de 24 heures, un incident coûte 36 000 €. Avec une réplique de la VM prête à démarrer sur un second serveur, le RTO tombe à 2 heures, et l'incident coûte 3 000 €. Si la réplique coûte 6 000 € par an, elle se rentabilise dès qu'elle évite un incident tous les cinq ans et demi : le gain par incident, 33 000 €, couvre 5,5 années d'abonnement (5,5 × 6 000 = 33 000 €).

La durée maximale tolérable. Certaines méthodes distinguent la durée au-delà de laquelle l'activité est en péril (on parle aussi de durée maximale d'interruption tolérable) et le RTO que l'on choisit, qui doit rester en dessous avec une marge. Le bilan d'impact sur l'activité (BIA) sert à les établir (chapitre 12).

Des objectifs par application, pas un chiffre global

Un seul RPO et un seul RTO pour toute l'entreprise, c'est soit trop cher, soit trop faible. On classe les applications par criticité, avec le métier.

Application d'Alvéa	Conséquence d'un arrêt	RPO	RTO
ERP (commandes, production)	Atelier à l'arrêt, livraisons en retard	1 h	4 h
Annuaire Active Directory, DNS	Plus personne ne se connecte à rien	24 h	2 h
Serveur de fichiers	Gêne forte, contournable quelques heures	24 h	8 h
Messagerie Microsoft 365	Gêne forte, assurée par le fournisseur	24 h (copie de sauvegarde)	Selon le fournisseur
GLPI	Tickets notés à la main en attendant	24 h	2 jours
Intranet d'information	Aucune urgence	1 semaine	3 jours

L'annuaire montre que les deux objectifs ne vont pas ensemble : ses données changent peu (un RPO de 24 heures suffit), mais rien ne fonctionne sans lui (RTO court). Et les dépendances comptent : l'ERP ne redémarre pas sans l'annuaire et le DNS, qui doivent donc revenir avant lui (l'ordre de restauration).

Exercices

Exercice 1 sur 5 RPO réel d'un plan Réussi À revoir

Un serveur est sauvegardé toutes les 6 heures, à 0 h, 6 h, 12 h et 18 h. Chaque sauvegarde dure 40 minutes.

Une panne survient à 15 h 10. Jusqu'à quelle heure peut-on revenir, et combien de temps de données est perdu ?
Même question pour une panne à 18 h 30.
Quelle est la perte maximale possible avec ce plan ?