Recovery Point Objective

Recovery Point Objective : Qu’est-ce que c’est ?

Le Recovery Point Objective (RPO) fait référence à la quantité de données susceptibles d’être perdues au cours de la période la plus opportune pour une entreprise ou une structure donnée, avant que de graves conséquences ne surviennent.
Les Recovery Point Objective se préoccupent donc exclusivement de la quantité de données perdues à la suite des défaillances, des incidents ou des sinistres informatiques.
En d’autres termes, on peut définir le Recovery Point Objective comme la durée maximum d’enregistrement des données susceptibles d’être perdues à la survenance d’une panne ou d’un bug informatique. Ce n’est qu’en quantifiant le RPO que l’on peut déterminer les objectifs de sauvegarde. Cela passe par une parfaite maitrise de la volumétrie et des fenêtres de sauvegarde.

Exemple de mise en œuvre du RPO

Supposons par exemple que le RPO soit défini à 24 heures et que la volumétrie soit faible. Dans ce cas, une sauvegarde en fin de journée est acceptable.
Cependant, avec un RPO très faible, une seule sauvegarde en fin de journée n’est pas suffisante. Il faudrait donc envisager plusieurs sauvegardes par jour. En effet, en fonction de la volumétrie, on pourra recourir à plusieurs techniques de sauvegarde. C’est souvent le cas lorsqu’il s’agit de secteurs particuliers comme la banque ou les télécommunications.

À y voir de près, l’objectif de la mise en place d’un Recovery Point Objective est tout à fait compréhensible. En effet, en cas de problème avec les services ou le serveur de collecte et de stockage des données dans une entreprise donnée, pour ne pas tout perdre, la solution qui s’impose est la réplication ou la copie des informations enregistrées.
Pour limiter les dégâts, l’entreprise met alors en place un système de récupération des données sous forme d’un processus de sauvegarde automatisé sur un serveur sécurisé. En général, pour des mesures sécuritaires, la sauvegarde des données ou la récupération des données se fait en dehors du serveur principal.

Différences entre RTO et RPO

Le Recovery Time Objective (RTO) et le Recovery Point Objective (RPO) sont deux indicateurs essentiels dans la mise en place du processus de reprise ou de continuité des affaires.
Il existe certes des points communs entre ces deux termes. Mais ce n’est pas une raison pour les confondre. En effet, au cours de la mise en place d’un dispositif de sauvegarde des données, on distingue deux indicateurs ou deux laps de temps assez critiques : Le délai acceptable et la durée supportable maximale de l’incident jusqu’à la cessation du bug informatique ou de la panne.

Le Recovery Point Objective (RPO) s’intéresse au laps de temps ou délai acceptable où certaines données risquent d’être perdues. Quant au Recovery Time Objective (RTO), il détermine la durée supportable maximale de la panne jusqu’à rétablissement de la situation.
Toutes les entreprises ayant un environnement informatique conséquent, doivent en effet intégrer le RTO et le RPO à leur plan de reprise d’activités. Cependant, le résultat ne sera jamais le même, étant donné que la fixation de ces indices dépend de plusieurs facteurs tels que l’importance des données, l’envergure du logiciel pour la structure concernée ou encore la quantité de données saisies.

En somme, la différence entre le RTO et le RPO se situe à 5 niveaux :

• Le but
• La priorité
• Le coût
• L’automatisation
• Les variables de calcul

Pour ce qui est de l’utilité, le RPO s’attaque aux problèmes de pertes de données. Il contribue donc à l’élaboration d’une stratégie de sauvegarde. Par contre, le RTO prend en compte les délais de restauration. On se sert du RTO pour élaborer une stratégie de reprise d’activité consécutive à un sinistre.

Sur l’aspect de la priorité, il faut dire que le RPO s’occupe exclusivement de la quantité de données perdues à la survenance d’une panne. Il s’intéresse donc au risque et à l’impact sur la globalité des transactions des clients et non au temps d’arrêt de productivité. Quant au RTO, il s’intéresse à la restauration des applications et des systèmes.
Pour ce qui concerne les coûts, cela dépend de plusieurs facteurs. C’est tentant en effet de penser que les dépenses à engager pour le maintien d’un RPO seraient plus élevés que celles d’un RTO. Mais en réalité, le coût d’un RTO exigeant peut être plus élevé que celui d’un RPO granulaire par exemple.

Par ailleurs, du point de vue automatisation, on peut dire que ce mécanisme est le propre du Recovery Point Objective. Comme vous le savez, les RPO obligent à opérer des sauvegardes de données à intervalles réguliers. C’est ce qui explique que l’automatisation soit compatible au RPO. Parlant des RTO, cette automatisation est quasi impossible. En effet, le RTO induit la restauration de toutes les opérations informatiques.

En outre, vu sous l’angle des calculs, on constate que les RPO prennent en compte un petit nombre de variables. De fait, ils se révèlent plus pratiques à calculer. Quant aux RTO, on remarque qu’ils impliquent par contre un grand nombre de facteurs. Cela s’explique par le fait que les délais de restauration sont soumis à plusieurs indices dont les délais analogiques ou en encore le jour de la survenance du sinistre.
Il faut également rappeler que lorsque le RPO est plus court, cela suppose que la perte de données sera moindre. Toutefois, cela va nécessiter plus de sauvegardes et plus de capacité de stockage et de ressources informatiques. Par contre, un RPO plus long est plus abordable, quand bien même il fait courir le risque de perdre plus de données.

Quelle est l’utilité du Recovery Point Objective ?

Aucune solution informatique n’est fiable à 100%. Il peut donc arriver que les serveurs physiques, les applications critiques, les périphériques, les espaces disques, les logiciels Microsoft Windows ou ERP ou encore les serveurs connaissent une interruption ou indisponibilité. L’analyse de ces différents risques révèle en effet une criticité variable d’une entreprise à une autre.
Puisque la panne est imprévisible, il est donc important de réduire les dégâts causés par le sinistre informatique pour assurer la continuité informatique. Cela passe par la mise en place d’un plan de secours informatique encore appelé plan de reprise après sinistre. Ce processus permet d’assurer la continuité des activités et le processus de reprise.

Le RPO permet donc de déterminer les actions à planifier en cas de sinistre. Il vise également à adopter une stratégie d’investissement informatique afin de mieux gérer les cas de sinistres.