RPO et RTO : comprendre les différences

Le RPO et le RTO sont des concepts importants dans la planification de la reprise après sinistre. Découvrez les différences entre le RPO et le RTO et comment ils peuvent contribuer à protéger vos données.

Written By
Zac Amos
Zac Amos
Nov 13, 2023
13 minute read
Enterprise Storage Forum content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More

Les objectifs de temps de reprise (RTO) et les objectifs de point de reprise (RPO) mesurent respectivement la durée d’interruption logicielle qu’une entreprise peut tolérer et l’intervalle entre deux sauvegardes.

  • RTO : la durée maximale d’interruption d’une application avant que les activités de l’entreprise ne subissent des dommages considérables.
  • RPO : la quantité de données qui peut être perdue avant que l’entreprise ne subisse d’importantes répercussions opérationnelles ou financières.

Ensemble, le RTO et le RPO sont des outils utiles dans les procédures de reprise après sinistre et de continuité d’activité, et sont indispensables aux organisations qui doivent suivre de près leurs exigences en matière de sauvegarde. Cet article examine en détail ces deux indicateurs, leurs différences et leurs cas d’utilisation.

Tableau comparatif du RTO et du RPO

Le tableau ci-dessous présente en un coup d’œil les différences entre les objectifs de temps de reprise et les objectifs de point de reprise.

CaractéristiqueMesuré enVarie en fonction deConsidérations pertinentes
RTOSecondes, minutes, heures ou jours, ainsi que les étapes nécessaires à la reprise des activités de l’entreprise Caractère critique de l’application compromiseCoût moyen prévu des temps d’arrêt
Vitesse à laquelle la reprise doit avoir lieu pour limiter les complications
RPOQuantité de données perduesFréquence des sauvegardes planifiéesQuantité de données qu’une organisation peut se permettre de perdre

Fréquence et exhaustivité des sauvegardes existantes

Comment fonctionnent le RPO et le RTO ?

Les responsables informatiques d’une organisation réalisent une analyse d’impact sur l’activité (BIA) afin d’identifier les valeurs de RPO et de RTO, et de déterminer les effets probables des perturbations touchant des applications ou processus critiques en raison de sinistres, d’erreurs importantes ou d’autres situations d’urgence.

Les résultats de la BIA varient selon des facteurs tels que le type d’applications métier dont dispose l’entreprise, la nature des données qu’elle recueille et conserve, ainsi que le type de situation d’urgence auquel elle pourrait être confrontée. Les sinistres concernés incluent notamment :

  • Tempêtes ou inondations affectant les installations de stockage des données
  • Virus informatiques infectant des applications critiques
  • Attaques par rançongiciel restreignant l’accès aux fichiers
  • Menaces internes malveillantes commettant des vols de données
  • Pannes d’applications tierces
Advertisement

Les entreprises peuvent exprimer le RPO et le RTO comme un continuum et considérer les deux comme des objectifs. Au-delà de cette similitude, des différences fondamentales existent lors des calculs nécessaires.

Fonctionnement de l’objectif de temps de reprise

L’objectif de temps de reprise mesure la durée pendant laquelle une entreprise peut se permettre qu’une application soit indisponible sans subir de dommages importants. Certaines applications peuvent rester indisponibles pendant plusieurs jours sans conséquences majeures, tandis que les applications hautement prioritaires ne peuvent être arrêtées que quelques secondes avant de provoquer la frustration des clients et une perte d’activité.

Calcul du RTO

Pour calculer le RTO, une entreprise doit classer les applications par priorité et par perte potentielle en fonction des ressources ou options disponibles. Par exemple, les plans standard visant des RTO quasi nuls nécessitent des services de basculement, tandis que les RTO de quatre heures permettent une reprise sur site commençant par des restaurations bare metal et s’achevant par la disponibilité complète de l’application et des données.

Si le service informatique a investi dans des services de basculement pour les applications hautement prioritaires, il peut exprimer le RTO en secondes en toute sécurité. Les services de basculement passent automatiquement à un autre serveur ou une autre plateforme lorsqu’un système tombe en panne. Le service informatique doit tout de même restaurer un environnement sur site, mais comme l’application est traitée dans le cloud, il dispose de davantage de temps pour le remettre en service.

Questions à se poser lors du calcul du RTO

Le RTO diffère généralement selon l’application et sa fonction. De nombreux décideurs trouvent plus facile d’effectuer les calculs critiques du RTO en se posant les questions suivantes :

  • Quelles applications destinées aux utilisateurs nécessitent une disponibilité permanente pour les clients ?
  • Quelles applications doivent être disponibles pour assurer le fonctionnement des activités génératrices de revenus de l’entreprise ?
  • L’entreprise dispose-t-elle d’applications assurant la sécurité de première ligne ?
  • Quels magasins de données hébergent les applications critiques de l’entreprise ?
  • Combien de temps une application peut-elle rester indisponible avant de nuire à l’expérience utilisateur ?
  • Quel est le délai habituel pour rétablir les fonctionnalités d’une application nécessaire après une panne ?
  • L’entreprise peut-elle restaurer les données perdues d’une application à partir des sauvegardes existantes ?
  • Comment cette application aide-t-elle l’entreprise à atteindre ses objectifs ?
Advertisement

Bonnes pratiques pour atteindre le RTO

Bien que le RTO dépende d’un large éventail de variables, les principes suivants peuvent aider les organisations à se rapprocher de leurs objectifs de RTO.

Rester réaliste et reconnaître les possibilités d’amélioration

Commencez par définir des attentes réalistes, mais vous constaterez peut-être malgré tout que le RTO est hors de portée. Dans ce cas, une approche pratique consiste à identifier les points de faiblesse probables.

Par exemple, une entreprise peut manquer de personnel, les équipes ayant constamment du mal à rétablir les fonctionnalités d’une application même lorsque tous les employés travaillent sur cette tâche. Recruter davantage de personnes peut alors être l’option la plus appropriée.

Examiner les technologies de sauvegarde existantes

Examinez la solution de sauvegarde actuelle de votre entreprise : si elle n’atteint pas vos objectifs, envisagez d’investir dans une meilleure alternative. C’est particulièrement vrai si l’entreprise utilise une solution de sauvegarde ancienne qui n’atteint systématiquement pas les objectifs de RTO. Investir dans une solution de sauvegarde mise à jour ou une plateforme de reprise après sinistre peut aider les entreprises à atteindre le RTO souhaité.

Mettre à jour le code des applications lorsque nécessaire

Déterminez si les problèmes d’une application sont dus à des bogues ou à un code obsolète : si c’est le cas, résoudre ces problèmes pourrait réduire le nombre de pannes et la durée des interruptions.

Advertisement

Utiliser des notifications en temps réel

Configurez des alertes en temps réel fournissant un retour immédiat lorsqu’une application présente des problèmes de performances, ou configurez les outils afin que les notifications parviennent au personnel sur les plateformes et appareils appropriés.

Déterminer quelles applications nécessitent des RTO faibles

Limitez les RTO faibles à un nombre restreint d’applications. La plupart des organisations ne peuvent pas maintenir des RTO très courts pour de nombreux systèmes, car effectuer et stocker des sauvegardes toutes les quelques heures pour chaque application de l’entreprise coûte cher.

Planifier la reprise après sinistre et la continuité d’activité

Envisagez de mettre en œuvre un plan de reprise après sinistre ou de continuité d’activité hautement performant. Pour certaines grandes entreprises capables de financer une plateforme de reprise plus avancée, cela fera une énorme différence dans l’atteinte des objectifs de RTO. Bien que ces solutions nécessitent du temps et l’approbation des parties prenantes pour être sélectionnées et déployées, elles constituent des ressources précieuses, en particulier pour les organisations disposant de nombreux systèmes critiques.

Fonctionnement de l’objectif de point de reprise

L’objectif de point de reprise d’une organisation correspond à sa tolérance à la perte, c’est-à-dire à la quantité de données qu’elle peut perdre avant de subir un préjudice important. Le RPO mesure l’intervalle entre l’événement de perte et la sauvegarde la plus récente.

Si une entreprise sauvegarde tout ou partie de ses données selon des intervalles réguliers de 24 heures, le pire scénario serait la perte de 24 heures de données. Pour certaines applications, cela est acceptable ; pour d’autres, non.

Calcul du RPO

Le RPO peut être calculé selon un processus étape par étape. Suivez ces recommandations et choisissez des plages temporelles pour tous les systèmes importants afin de déterminer la quantité de données que votre entreprise peut perdre sans subir de dommages importants :

  1. Effectuez des tests pour déterminer à quelle vitesse les données doivent être disponibles pour chaque application d’entreprise, notamment les plateformes de stockage cloud, les solutions CRM et les applications de commerce électronique.
  2. Classez toutes les principales applications d’entreprise en fonction de leurs exigences de restauration des sauvegardes : les données doivent-elles être restaurées en quelques minutes ou peuvent-elles attendre un jour, par exemple ?
  3. Calculez la situation financière de l’entreprise en matière de sauvegardes. Pour combien d’applications peut-elle se permettre de maintenir des services de basculement et de réplication ? L’entreprise doit-elle stocker certaines sauvegardes hors ligne, par exemple sur des disques durs physiques ?
  4. Choisissez les applications prioritaires à restaurer immédiatement. Cela peut se faire rapidement si les serveurs qui prennent en charge la plateforme cloud principale disposent d’une réplication continue, mais une base de données contenant d’anciens contacts commerciaux et sauvegardée sur des disques durs peut nécessiter plusieurs heures pour être récupérée. La plupart des entreprises ne peuvent pas se permettre des sauvegardes rapides pour tous leurs logiciels ; établissez donc vos priorités avec discernement.
Advertisement

Définir les objectifs de RPO

Selon la priorité de l’application, les RPO individuels vont généralement de valeurs quasi nulles (mesurées en secondes) à 24 heures. Les entreprises définissant des RPO de plus de huit heures peuvent être en mesure de les atteindre avec leurs solutions de sauvegarde existantes, à condition que cela n’ait qu’un impact minimal sur les systèmes de production.

Les RPO de quatre heures nécessitent une réplication planifiée des instantanés. Les RPO quasi nuls nécessitent une réplication continue. Lorsque le RPO et le RTO sont tous deux quasi nuls, il faut combiner la réplication continue et les services de basculement pour obtenir une disponibilité quasi totale des applications et des données, à hauteur de près de 100 %.

Définir des objectifs de RPO liés aux applications

Définissez les objectifs de RPO en fonction de la nature et de l’urgence des données stockées par les applications concernées. Par exemple, un RPO de quatre heures pour une application fournit une période maximale de quatre heures pour sauvegarder les données avant qu’elles ne soient perdues.

Un RPO de quatre heures ne signifie pas nécessairement que l’entreprise perdra quatre heures de données. Une application de traitement de texte qui tombe en panne à minuit et redémarre à 1 h 15 peut ne rien perdre. En revanche, si une application très sollicitée tombe en panne à 10 heures et est restaurée à 14 heures, l’entreprise peut perdre plusieurs heures d’informations précieuses, voire irremplaçables. Dans ce cas, planifiez des sauvegardes plus fréquentes pour atteindre un RPO adapté à l’application.

Advertisement

Bonnes pratiques pour atteindre le RPO

Comme pour les objectifs de RTO, commencez par déterminer quel RPO l’entreprise peut raisonnablement atteindre avec ses ressources actuelles. Avant de définir ces objectifs, testez les taux de sauvegarde de différents services de basculement et de réplication, disques durs et baies flash. Examinez les données historiques pour déterminer la durée des restaurations précédentes. Chercher à atteindre un RPO très différent des tendances historiques pourrait entraîner découragement et frustration, tout en indiquant que l’entreprise doit peut-être accroître ses ressources.

La formation du personnel est également essentielle. Toutes les personnes participant au processus de sauvegarde doivent réagir rapidement et promptement lorsqu’un incident ou une panne survient, afin de savoir quoi faire lorsqu’un système tombe en panne et d’agir avec assurance dans une situation urgente.

Des mises à niveau technologiques peuvent également s’avérer nécessaires. Assurez-vous que les services de réplication et de basculement sont fiables et modernes : ceux hébergés sur un serveur ancien et peu fiable risquent de ne pas fonctionner aussi rapidement. De même, optimisez les performances du réseau afin que celui de l’entreprise puisse prendre en charge les taux de sauvegarde des données. Un trafic important pourrait empêcher l’organisation de respecter ses délais de sauvegarde.

Similarités et différences entre le RPO et le RTO

Le RPO et le RTO sont des considérations importantes pour les plans de reprise après sinistre ou de continuité d’activité. L’analyse d’impact sur l’activité peut être utilisée aux premières étapes du calcul du RPO et du RTO.

Le RTO concerne la durée des interruptions. Le RPO est associé à la perte de données et à la fréquence des sauvegardes. Certaines causes d’interruption échappent au contrôle de l’entreprise, mais les dirigeants peuvent décider de la fréquence des sauvegardes afin de limiter les dommages potentiels.

Le RTO est une mesure prospective qui permet de déterminer le temps nécessaire à une organisation touchée pour reprendre ses activités. À l’inverse, le RPO consiste à regarder en arrière pour déterminer quand la dernière sauvegarde des données a été effectuée et quelle quantité d’informations l’entreprise perdra en raison du problème.

Quand utiliser le RPO et le RTO

Utilisez l’objectif de point de reprise lorsque vous gérez des données essentielles aux activités de l’entreprise, que celle-ci ne peut pas se permettre de perdre. Le RPO est également le choix approprié lorsqu’une entreprise doit respecter des exigences précises en matière de données pour se conformer aux autorités de réglementation.

On observe également une tendance émergente : certaines personnes définissent des objectifs de point de reprise lorsqu’elles stockent des informations à plusieurs endroits, par exemple dans le cloud et dans un emplacement physique. De tels arrangements sont plus complexes, ce qui nécessite des précautions supplémentaires.

La multiplication des attaques par rançongiciel a également poussé les dirigeants d’entreprise à prendre le RPO plus au sérieux. Cela peut réduire les effets d’un incident et limiter la pression les incitant à payer la rançon. Les entreprises qui effectuent des sauvegardes fréquentes et disposent de plans de reprise robustes sont beaucoup moins susceptibles de subir d’importantes répercussions financières et perturbations opérationnelles.

Les cas d’utilisation les plus appropriés des objectifs de temps de reprise sont ceux où même de brèves interruptions pourraient être catastrophiques. Les systèmes de répartition des urgences et les outils de surveillance des systèmes industriels critiques en sont de bons exemples.

Tenez compte des conséquences des interruptions pour les clients. Par exemple, en 2022, Ticketmaster est tombé en panne alors que les fans tentaient d’obtenir des billets de Taylor Swift. L’incident a été largement relayé et critiqué dans les articles de presse et sur les réseaux sociaux, fournissant à d’autres entreprises un exemple de ce qu’il ne faut pas faire.

Cas d’utilisation de l’objectif de temps de reprise

Les exemples suivants montrent différentes applications du RTO pour aider les entreprises à éviter des conséquences désastreuses.

Restauration d’un e-mail important

L’avocat d’une entreprise supprime accidentellement un e-mail urgent, puis vide le contenu de la corbeille. Mais le service informatique sauvegarde en continu les modifications de niveau delta dans Microsoft Exchange, une application critique pour cette entreprise très active. L’application de sauvegarde prend en charge la sauvegarde et la restauration granulaires, de sorte que l’entreprise peut récupérer le message individuel en cinq minutes, au lieu de restaurer une machine virtuelle entière pour un seul e-mail.

Garantir la disponibilité d’un site de commerce électronique

Le site de commerce électronique auto-hébergé d’un magasin utilise trois bases de données : une base relationnelle qui stocke le catalogue de produits, une base documentaire qui conserve l’historique des commandes et une base d’API qui se connecte à la passerelle de son prestataire de paiement.

La base de données documentaire peut reconstruire ses données à partir d’autres sources ; son RTO et son RPO sont donc de 24 heures. L’entreprise n’ajoute des produits à la base relationnelle qu’une fois par semaine : le RPO n’est donc pas critique. En revanche, le RTO l’est, car les transactions des clients s’arrêtent si la base de données tombe en panne.

L’entreprise investit dans un service de basculement, permettant à la base de données de démarrer immédiatement sur des serveurs virtuels. L’entreprise réplique les quelques modifications effectuées pendant la semaine vers la plateforme de reprise après sinistre de son fournisseur. La base de données d’API contient les informations de commande et nécessite un RPO et un RTO de quelques secondes. Le service informatique réplique en continu les données vers le site de basculement, qui prend immédiatement le relais du traitement si la base de données d’API tombe en panne.

Cas d’utilisation de l’objectif de point de reprise

Les exemples suivants montrent différentes applications du RPO pour maintenir la continuité d’activité après un événement.

Restauration d’une plateforme CRM

Le logiciel CRM hébergé dans le bureau principal d’une entreprise en Floride tombe en panne lorsqu’une violente tempête frappe la région. La salle des serveurs est endommagée, mais toutes les données CRM sont sauvegardées dans un centre de données situé dans le Missouri. Compte tenu de l’importance de la plateforme CRM, les équipes ont donné la priorité aux services de réplication et de basculement, en répliquant les sauvegardes du centre de données quelques minutes seulement avant l’arrivée de la tempête.

Les membres de l’équipe responsables de la restauration, dont beaucoup se trouvent hors de l’État et ne travaillent pas directement en Floride, suivent immédiatement le processus d’escalade prévu dans leur plan de reprise après sinistre et peuvent atteindre le RPO de 15 minutes.

Planifier des sauvegardes sur disque dur

Les sauvegardes sont plus pratiques pour toutes les personnes concernées lorsqu’elles s’effectuent automatiquement ou avec une supervision limitée. Les ordinateurs Mac d’Apple disposent d’une application Time Machine qui s’en charge : une fois qu’une personne connecte un disque externe à un Mac équipé de Time Machine et active l’application, celle-ci effectue automatiquement les sauvegardes suivantes :

  • Sauvegardes effectuées toutes les heures au cours des dernières 24 heures
  • Sauvegardes quotidiennes au cours du dernier mois
  • Sauvegardes hebdomadaires pour les périodes de plus d’un mois

Dans ce cas, le point de restauration de la sauvegarde la plus récente est utilisé lorsque les utilisateurs se rendent compte qu’ils doivent restaurer des données. La plupart des entreprises utilisent des technologies plus avancées que Time Machine. Toutefois, le concept de l’application illustre clairement pourquoi il est nécessaire de prendre des décisions cruciales concernant les données avant de définir le RPO.

En résumé : donner la priorité aux objectifs de sauvegarde et de reprise de l’entreprise

La gestion du RTO et du RPO est essentielle pour permettre aux entreprises d’atteindre stratégiquement leurs objectifs de sauvegarde des données. Ces mesures fournissent aux entreprises des indicateurs précis à prendre en compte lors de l’élaboration de stratégies de sauvegarde et de reprise. En outre, la détermination de ces indicateurs clés de performance permet de rendre plus gérables des tâches qui peuvent sembler insurmontables.

Le défi pour toutes les entreprises consiste à établir des priorités entre les applications et à déterminer lesquelles nécessitent davantage d’investissements financiers. Combien de solutions de restauration instantanée l’entreprise peut-elle se permettre ? Connaître le RTO et le RPO de chaque système peut les aider à prendre une décision.

Les dirigeants d’entreprise devraient considérer le RTO et le RPO comme tout aussi essentiels, plutôt que de mesurer l’un sans mesurer l’autre. Ces deux mesures révèlent les applications et les données les plus critiques de l’entreprise, ainsi que ce qui est nécessaire pour les maintenir en fonctionnement et assurer la réussite des opérations.

Découvrez 11 bonnes pratiques pour la sauvegarde des données pour découvrir d’autres principes de gestion des données d’entreprise.

Zac Amos

Zac Amos is a contributor to Enterprise Storage Forum with a wide range of experience writing about cybersecurity, data management, automation, and storage. He has been featured in Datamation, ISAGCA, DZone, CyberTalk, and other publications.

Enterprise Storage Forum Logo

Enterprise Storage Forum offers practical information on data storage and protection from several different perspectives: hardware, software, on-premises services and cloud services. It also includes storage security and deep looks into various storage technologies, including object storage and modern parallel file systems. ESF is an ideal website for enterprise storage admins, CTOs and storage architects to reference in order to stay informed about the latest products, services and trends in the storage industry.

Property of TechnologyAdvice. © 2026 TechnologyAdvice. All Rights Reserved

Advertiser Disclosure: Some of the products that appear on this site are from companies from which TechnologyAdvice receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. TechnologyAdvice does not include all companies or all types of products available in the marketplace.