QUESTIONS & RÉPONSES La collection de Solve DSI - Yann-Eric Devars
← Revenir aux réponses

Quelle différence entre le RTO et le RPO ?

Extrait de Plan de reprise d’activité

RTO — Recovery Time Objective

Le RTO est défini comme la durée maximale durant laquelle un système, une application ou un processus métier peut être indisponible avant que les conséquences ne deviennent inacceptables (financièrement, règlementairement ou en termes d’image).

Au-delà de ce délai, l’entreprise subit un impact majeur qui menace sa pérennité ou ses engagements.

Exemple : Si le RTO d’une application critique est de 4 heures, cela signifie qu’en cas d’incident, on doit être capable de la rétablir dans un délai inférieur ou égal à 4 heures.

L’objectif est de garantir que l’interruption n’excède jamais ce temps.

En pratique, plus le RTO est court, plus il faudra investir dans des solutions de haute disponibilité, des procédures d’automatisation de bascule, des mécanismes de virtualisation et de redondance.

Au contraire, s’il est long, on peut se contenter de méthodes plus simples (sauvegarde quotidienne, remise en route manuelle).

RPO — Recovery Point Objective

Le RPO désigne la quantité de données (ou la période) qu’on peut se permettre de perdre en cas de sinistre.

C’est un indicateur d’antériorité :

Un RPO de 1 heure signifie que l’entreprise peut tolérer de perdre jusqu’à 1 heure de transactions ou de modifications de données.

Les sauvegardes (ou réplications) doivent donc être effectuées plus fréquemment que toutes les heures pour respecter cet objectif.

Un RPO de 24 heures suppose que l’on puisse perdre tout ce qui a été fait depuis la dernière sauvegarde quotidienne (typiquement, la nuit précédente).

Plus le RPO est faible (ex. : proche de zéro), plus la solution technique requise devra être sophistiquée (réplication synchrone, journaux de transactions, etc.) et plus le coût potentiel sera élevé.

En revanche, si le RPO toléré est grand (plusieurs jours), des sauvegardes ponctuelles peuvent suffire.