RTO vs RPO : comprendre les principales différences pour la reprise après sinistre

Les organisations s’appuient de plus en plus sur les sauvegardes pour protéger leurs données et assurer la continuité de leurs activités en cas de sinistre. Cependant, on estime que plus de 72 % des entreprises ne sont pas en mesure de répondre à leurs attentes en matière de reprise informatique liées à leurs objectifs de point de récupération (RPO) et à leurs objectifs de temps de récupération (RTO).

Pour vous aider à créer un plan de reprise efficace, il est essentiel que vous acquériez une compréhension complète des RTO et RPO et que vous appreniez à distinguer leurs différences. Cet article explique tout ce que vous devez savoir sur ces deux paramètres pour mettre en place une stratégie de reprise après sinistre fiable. Poursuivez votre lecture pour découvrir comment vous pouvez réduire vos RPO et RTO afin de minimiser les pertes de données et reprendre vos activités normales le plus rapidement possible après une catastrophe.

Qu’est-ce que le RTO ?

Les objectifs de temps de récupération (RTO) font référence à la durée maximale d’indisponibilité qu’une organisation peut tolérer après un événement perturbateur. En d’autres termes, le RTO correspond à la durée entre la survenue d’une catastrophe et la récupération des Workloads critiques affectés.

Le calcul du RTO dépend généralement de votre plan de reprise après sinistre, des ressources disponibles et du budget. Lorsque votre infrastructure informatique est indisponible, vous avez besoin d’un certain temps pour identifier la ou les raisons de la panne et prendre les actions nécessaires pour résoudre le problème. Cependant, des mesures de reprise après sinistre doivent être mises en place pour garantir que les systèmes et les Workloads critiques restent accessibles et disponibles pendant la résolution du problème de production. Votre RTO correspond au temps écoulé entre la panne et la disponibilité des systèmes grâce aux sauvegardes ou aux réplicas des Workloads.

Qu’est-ce que le RPO ?

L’objectif de point de récupération (RPO) représente la quantité maximale de données qu’une organisation peut se permettre de perdre en cas de sinistre sans conséquences critiques. Cet indicateur est mesuré en heures/minutes depuis le dernier processus de sauvegarde/réplication. Utilisez-le pour déterminer la fréquence à laquelle vous devez créer des sauvegardes et des réplicas de données afin de réduire les pertes de données à la suite d’un événement perturbateur.

Dans une situation idéale, une tâche de sauvegarde ou de réplication est terminée juste avant que la machine d’origine ne tombe en panne. Cependant, cela est rare dans la réalité, il y a donc un écart entre le moment où la dernière sauvegarde réussie a été créée et le moment où la machine d’origine tombe en panne. Pendant ce temps, la machine virtuelle effectuait des opérations et stockait des données, et il est fort probable que ces données soient perdues.

Que sont le RTO et le RPO dans la reprise après sinistre ?

L’objectif ultime de la protection des données est clair : vous voulez être sûr que les données critiques ne seront pas perdues en cas de problème et que vous pourrez respecter les accords de niveau de service (SLA) de votre organisation en termes de disponibilité et de temps de fonctionnement. Cependant, il est assez coûteux de répercuter en temps réel toutes les modifications de votre environnement virtuel sur un site de reprise après sinistre (DR). C’est pourquoi vous devez accepter l’idée que vous perdrez certaines données et que vos services informatiques seront interrompus en cas de panne. Votre tâche consiste donc à minimiser ces pertes et ces interruptions.

Illustrons les concepts de RPO et de RTO à l’aide d’un diagramme simple :

rpo and rto in disaster recovery

Le diagramme montre un scénario courant : une machine virtuelle tombe en panne pour une raison quelconque. La ligne jaune représente le RPO, qui correspond au temps écoulé entre la dernière sauvegarde et la panne. La ligne orange représente le RTO et correspond au temps nécessaire pour restaurer la machine virtuelle.

Différences entre RTO et RPO

Pour comprendre comment déterminer le RTO et le RPO, il convient d’examiner leurs différences et leur rôle dans le processus de reprise après sinistre.

Évaluation

  • Le RTO concerne principalement le délai dans lequel les opérations commerciales doivent être reprises en cas de sinistre. Les points à prendre en considération sont les suivants :
    • Évaluez les besoins et les priorités de votre organisation, car ils sont propres à chaque organisation.
    • Déterminez quelles sont les applications les plus critiques pour les services et les applications essentiels à la survie de l’organisation, ainsi que les répercussions possibles en cas de défaillance de ces applications.
    • Déterminez l’ordre dans lequel chaque système/application doit être restauré afin de garantir une reprise après sinistre réussie avec un minimum de pertes liées aux temps d’arrêt.
  • Le RPO se concentre davantage sur la quantité de données pouvant être perdues pendant le temps d’indisponibilité sans causer de dommages graves aux résultats financiers d’une organisation. Les points à prendre en considération sont les suivants :
    • Déterminez la fréquence des sauvegardes/réplications et la quantité de données qui pourrait être perdue entre la dernière sauvegarde de la machine virtuelle et une catastrophe réelle.
    • Évaluez la quantité de données que votre organisation peut se permettre de perdre pour chaque type de Workload.

Coûts

La principale différence entre le RTO et le RPO est que le premier prend en compte tous les aspects de la structure de l’entreprise et du processus de reprise après sinistre dans son ensemble, tandis que le second ne tient compte que de la criticité des données et des applications pour la continuité des activités. Par conséquent, respecter les valeurs RTO peut s’avérer difficile et coûteux pour garantir une récupération rapide. De même, avoir des RPO plus petits signifie que vous devez effectuer davantage de sauvegardes et créer des points de récupération supplémentaires, ce qui peut augmenter vos coûts de stockage.

Automation

  • As RPO est axé sur la sauvegarde des données et la résilience de votre système face à la perte, il est recommandé de réaliser fréquemment des sauvegardes de données. De nombreuses solutions de sauvegarde modernes vous permettent d’effectuer des sauvegardes automatisées VM, ce qui signifie que vos stratégies de sauvegarde peuvent être adaptées de manière à répondre efficacement à vos objectifs RPO, avec un minimum d’intervention de votre part.
  • Atteindre RTO est un processus plus complexe à gérer, car il prend en compte tous les processus métier et composants système qui doivent faire l’objet d’une opération de récupération lors d’un événement de reprise après sinistre. Cela dit, il est recommandé d’automatiser et d’effectuer l’orchestration de l’ensemble du processus de reprise après sinistre du début à la fin afin de garantir que vos objectifs RTO puissent être atteints.

Facilité de calcul

  • La RPO métrique est facile à calculer, car elle ne couvre qu’un seul aspect du processus de récupération : les données.
  • RTO prend en compte tous les aspects de votre organisation, y compris l’importance de vos données et services, le coût des temps d’arrêt, l’investissement dans les activités de reprise après sinistre, etc. Lors du calcul du RTO, vous devez tenir compte des différents types de Workloads et d’applications, car leurs processus de récupération peuvent varier. Il est conseillé de calculer le RTO sur la base d’un plan de continuité des activités, qui décrit les risques et menaces potentiels pour l’entreprise et les mesures à prendre pour reprendre les opérations commerciales.

Pour définir le RTO applicable aux différentes Workloads de votre organisation, répondez à la question suivante :

Combien de temps une application/un système/une machine spécifique peut-il/elle être hors service sans avoir un impact significatif sur les activités principales de votre organisation ?

Après avoir répondu à cette question pour différentes machines, demandez-vous si les résultats attendus peuvent satisfaire vos besoins commerciaux actuels. Si ce n’est pas le cas, réfléchissez à la manière dont vous pourriez améliorer vos stratégies de sauvegarde et de reprise après sinistre afin de maintenir les données sauvegardées aussi à jour que possible.

Comment atteindre des RPO et RTO plus stricts avec NAKIVO

NAKIVO Backup & Replication vous permet de créer des sauvegardes de machines virtuelles et physiques plus fréquemment, améliorant ainsi le RPO. Il suffit de planifier des sauvegardes régulières à un intervalle qui ne dépasse pas votre objectif.

La solution contribue également à réduire le RTO grâce à la restauration instantanée des machines virtuelles et à la fonctionnalité de réplication pour VMware vSphere, Microsoft Hyper-V et Amazon EC2. Intégrez vos services de surveillance réseau et déclenchez un processus de restauration immédiatement après qu’une machine virtuelle est devenue indisponible. Vous pouvez également créer des répliques hors site (copies exactes) des machines virtuelles critiques. En cas de défaillance de la machine virtuelle d’origine, les répliques seraient automatiquement mises sous tension. Si la maintenance des répliques nécessite plus de ressources que vous ne pouvez vous permettre, vous pouvez choisir la fonctionnalité de démarrage instantané des machines virtuelles à partir des sauvegardes .

Pour atteindre les RTO les plus stricts, NAKIVO Backup & Replication a introduit la fonctionnalité d’orchestration de la reprise après sinistre . Automatisez entièrement le basculement et la restauration automatique des machines virtuelles pour différents scénarios de reprise après sinistre et effectuez des tests non perturbateurs pour garantir la récupération dans les délais prévus.

Try NAKIVO Backup & Replication

Try NAKIVO Backup & Replication

Get a free trial to explore all the solution’s data protection capabilities. 15 days for free. Zero feature or capacity limitations. No credit card required.

Les gens qui ont consulté cet article ont également lu