RPO et RTO : définitions et calculateur
Le RPO est la perte de données maximale acceptable : combien de temps de saisies vous pouvez perdre. Le RTO est la durée d'arrêt maximale acceptable : combien de temps le service peut rester indisponible.
Le calculateur ci-dessous estime ceux que vos sauvegardes permettent réellement, et montre quelle étape pèse le plus.
Le calcul se fait dans votre navigateur : aucune valeur saisie n'est envoyée.
Calculer le RPO et le RTO de votre sauvegarde
Résultat
RPO obtenu
1 j 0 h 30 min
Intervalle + durée d'une sauvegarde · objectif : 1 h
RTO obtenu
2 h 42 min
objectif : 4 h
Décomposition du RTO
| Détection | 15 min | 9 % |
| Intervention | 1 h | 37 % |
| Rapatriement des données | 57 min | 35 % |
| Remise en service | < 1 s | 0 % |
| Vérifications | 30 min | 18 % |
RPO et RTO sur une ligne de temps
Les deux objectifs se lisent de part et d'autre de l'incident. Le RPO se mesure en arrière, jusqu'au dernier point de restauration utilisable. Le RTO se mesure en avant, jusqu'au retour en service.
dernière sauvegarde incident reprise
|<------- RPO ------->|<----------- RTO ----------->|
données perdues service indisponibleLes deux se fixent métier par métier, avant de choisir une technique. Une messagerie tolère souvent quelques heures de RPO ; une base de commandes, quelques minutes. C'est ce choix qui décide ensuite de la fréquence des sauvegardes, de l'expédition des journaux et de l'architecture de reprise.
Comment le calcul est fait
Le RPO retient le pire cas : l'incident survient juste avant la fin de la sauvegarde suivante.
RPO = intervalle entre sauvegardes + durée d'une sauvegarde
(ou l'intervalle d'expédition des journaux, s'il est plus court)
RTO = détection + intervention
+ rapatriement (volume × 8 / (débit × rendement))
+ remise en service (volume / vitesse de rechargement)
+ vérificationsLe rapatriement compte les Gio en binaire (2³⁰ octets) et le débit en Mbit/s décimaux, comme les outils réseau. Le rendement corrige l'écart entre le débit du lien et le débit utile : protocole, chiffrement, charge du serveur. La remise en service couvre ce qui suit le transfert, comme le rechargement d'un dump SQL. Pour une VM restaurée directement, elle est négligeable.
Ce que montrent nos mesures
Pour une base MariaDB, notre méthode pour sauvegarder MariaDB vers Proxmox Backup Server envoie un dump chaque nuit et les binlogs toutes les 5 minutes. La restauration à la minute près y est validée : 180 000 lignes retrouvées sur 180 000 après un DROP TABLE fautif. C'est le préréglage « quotidienne + binlogs » du calculateur : le RPO passe de plus de 24 h à 5 minutes.
Sur le RTO, la même page compare deux modes de restauration sur nos petites bases de test : 43 s pour rapatrier et remettre en service une copie physique de 4,05 Gio, contre environ 195 s pour rapatrier et recharger un dump de 1,7 Gio. Seule la copie physique sert de repère dans le calculateur. Le rechargement d'un dump dépend des index et ne s'extrapole pas en ligne droite : une vitesse tirée de 1,7 Gio donnerait un RTO faux sur 100 Gio. Mesurez-la sur votre base. Ces deux durées incluent le rapatriement et viennent de petites bases : ne les prenez pas pour une promesse sur la vôtre. Le choix de l'outil de dump pèse aussi, comme le montre notre comparatif mariadb-dump contre mydumper.
Pour un serveur de fichiers, le premier backup d'un serveur Windows de 1 To a pris 20 h 30 pour 876 Go. C'est un envoi, pas une restauration, mais il donne l'ordre de grandeur d'un débit réel sur une ligne internet ordinaire. Pour estimer vos propres durées d'envoi, le calculateur de fenêtre de sauvegarde fait le calcul inverse.
Réduire son RPO ou son RTO
Le RPO baisse en sauvegardant plus souvent ou en expédiant les journaux de transactions entre deux sauvegardes. Pour des machines virtuelles, une stratégie de sauvegarde 3-2-1 sur plusieurs datacenters garde une copie récente hors du site de production.
Le RTO baisse d'abord sur les étapes humaines. La détection dépend de la supervision, l'intervention de la présence d'une personne à 3 h du matin : c'est le rôle d'une astreinte informatique 24/7. Le rapatriement baisse en gardant une copie proche ; le reste demande une architecture de reprise. Notre article sur le PRA Proxmox multi-site décrit ce montage, et la page disaster recovery Proxmox avec PBS la reprise depuis une sauvegarde externalisée. Pour cadrer le tout côté organisation, voyez PRA et PCA en infogérance.
Le RTO se traduit ensuite en disponibilité : quelques heures d'arrêt par an pèsent sur un SLA, ce que chiffre notre calculateur de disponibilité. Et si le rapatriement traverse un lien lointain, le calculateur de débit TCP montre ce que la latence retire au débit utile.
Questions fréquentes
Quelle est la différence entre RPO et RTO ?
Le RPO (Recovery Point Objective) est la perte de données maximale acceptable, exprimée en temps : avec un RPO de 24 h, vous acceptez de perdre jusqu'à une journée de saisies. Le RTO (Recovery Time Objective) est la durée d'arrêt maximale acceptable, entre l'incident et la reprise du service. Le RPO regarde en arrière, vers la dernière sauvegarde utilisable ; le RTO regarde en avant, vers le retour en service.
Que sont la PDMA et la DIMA ?
Ce sont les équivalents français du RPO et du RTO. La PDMA, perte de données maximale admissible, correspond au RPO. La DIMA, durée d'interruption maximale admissible, correspond au RTO. Les deux couples de sigles désignent les mêmes objectifs dans un plan de reprise d'activité.
Comment calculer le RPO d'une sauvegarde ?
Dans le pire cas, l'incident survient juste avant la fin de la sauvegarde suivante : vous perdez l'intervalle entre deux sauvegardes plus la durée d'une sauvegarde. Une sauvegarde quotidienne qui dure 30 minutes donne un RPO de 24 h 30 min. Si des journaux de transactions (binlogs MariaDB, WAL PostgreSQL) partent toutes les 5 minutes, le RPO tombe à 5 minutes.
Combien de temps faut-il pour restaurer 1 To ?
Le rapatriement seul de 1 000 Gio sur un lien de 1 Gbit/s utilisé à 50 % prend environ 4 h 46 min. Il faut y ajouter la détection de l'incident, le délai avant qu'une personne intervienne, la remise en service (rechargement d'un dump, par exemple) et les vérifications avant reprise. Le transfert n'est souvent qu'une partie du RTO.
Dump ou copie physique : quel effet sur le RTO d'une base de données ?
Un dump se restaure en rejouant chaque instruction SQL et en reconstruisant les index, une copie physique se remet en place au débit du disque. Sur nos petites bases de test, rapatriement compris, une copie physique de 4,05 Gio a été remise en service en 43 s, contre environ 195 s pour recharger un dump de 1,7 Gio. Ces vitesses ne sont pas garanties sur une grosse base : mesurez la vôtre.
Un RTO calculé suffit-il pour un plan de reprise ?
Non. Le calcul donne un ordre de grandeur et montre quelle étape pèse le plus. Seul un essai de restauration chronométré, sur une copie réelle de vos données, donne votre vrai RTO. Un RTO jamais testé est une hypothèse, pas un engagement.
Contact
Adresse
5 B RUE DES NOYERS, 95300 PONTOISE, FRANCE