Définir les niveaux RPO et RTO pour la stratégie de stockage et de protection des données

Définir RTO et RPO

Le RTO est défini par la norme mondiale des TIC pour la reprise après sinistre, ISO/IEC 27031:2011, comme suit : « La période de temps au cours de laquelle les niveaux minimaux de services et/ou de produits et les systèmes, applications ou fonctions de support doivent être récupérés après qu’une perturbation s’est produite. »

Le RPO, quant à lui, est défini comme suit : « Le moment où les données doivent être récupérées après qu’une perturbation s’est produite. »

En clair, RTO est la durée pendant laquelle vous pouvez vous permettre que les systèmes et les données ne soient pas disponibles. Il est mesuré dans le temps et est la période pendant laquelle vous avez besoin que les systèmes soient restaurés après une panne.

Le RPO est la quantité de données que vous pouvez vous permettre de perdre. Il est également mesuré dans le temps, mais vu à travers le prisme de la quantité de données que vous pouvez vous permettre de perdre. Ainsi, il sera régi par le temps écoulé depuis la dernière sauvegarde et/ou instantané ou par la date à laquelle les données sont récentes sur un site vers lequel vous basculez.

Ainsi, par exemple, une organisation peut déterminer qu’elle peut travailler avec un RTO d’une heure et un RPO de deux heures de données.

Le tableau est susceptible d’être moins simple que cela, cependant.

Différents RTO et RPO pour différentes applications ?

Mais le paysage applicatif au sein d’une organisation ne se prête pas à des métriques générales qui couvrent tout.

La réalité est que les RTO granulaires et les RPO sont probablement ce qui est nécessaire pour répondre à des situations réelles.

Ainsi, par exemple, si tous vos systèmes tombaient en panne, la priorité serait de restaurer ceux qui sont destinés au public et générateurs de revenus, ce qui peut inclure des applications transactionnelles très urgentes.

Ceux-ci seraient de la plus haute priorité et occuperaient l’extrémité opposée du continuum, par exemple, des données archivées stockées et inutilisées depuis longtemps ou des données non structurées sans contraintes de temps critiques pour l’entreprise.

En ce qui concerne les conséquences pratiques, ces différences se refléteront dans l’utilisation de différentes classes de stockage et de protection des données.

Calcul du RTO et du RPO

Le point de départ consiste à déterminer le niveau de risque d’indisponibilité des systèmes pour l’organisation des systèmes et la durée pendant laquelle cela peut être toléré.

Il est logique de catégoriser et de hiérarchiser les systèmes et de poser des questions telles que:

• S’agit-il d’un système orienté client ?
• Est-il transactionnel ou fournit-il uniquement des informations?
• Quels systèmes auront le plus d’impact sur les revenus et/ou la réputation des clients ?
• Combien de données seraient perdues – par minute ou par heure, par exemple – si elles devenaient indisponibles ?
• Combien coûtent les données perdues en termes de revenus, à la minute ou à l’heure?
• Quelle est la quantité maximale de perte de données qui peut être tolérée?
• Quel est le plus long délai que nous pouvons nous permettre que les systèmes – classés par criticité – soient indisponibles ?
• Existe-t-il des systèmes avec des dépendances par rapport aux autres et quels sont leurs RPO/RTO ?
• Combien d’employés seraient touchés par la panne du système?

Exemples RPO et RTO

Les RPO et RTO idéaux seraient nuls. Mais plus vous vous rapprochez de zéro, plus cela coûte cher.

Ainsi, zéro n’est pas une option pour la plupart des systèmes, mais certains en auront besoin , à savoir, les systèmes transactionnels bancaires qui ne peuvent supporter presque aucune perte de données ou indisponibilité du système.

De manière plus réaliste, vous classeriez probablement les applications et les systèmes par niveau. Ainsi, par exemple :

• Le niveau 1 serait les applications critiques – telles que les systèmes de vente au détail, transactionnels et orientés client – qui recevraient un RPO et un RTO inférieurs, disons, à 10 minutes.
• Les systèmes de niveau 2 seraient importants pour l’entreprise, mais d’une criticité moindre que les systèmes de niveau 1, de sorte que le RPO et le RTO d’une heure à trois ou quatre heures seraient appropriés.
• Le niveau 3 serait tous ces systèmes qui peuvent être remis en ligne pendant des heures et des jours.

Niveau RTO/RPO et méthode de protection des données

Le niveau, en grande partie, détermine le niveau de protection des données. Ainsi, par exemple, les systèmes de niveau 1 ont besoin d’écritures doubles et/ou d’une réplication fréquente des données pour se protéger contre les problèmes localisés. Il aura probablement également besoin de la possibilité de basculer rapidement vers un emplacement distant en cas de menaces au niveau du site.

Les systèmes de niveau 2 nécessiteraient une copie moins fréquente des données, mais devraient également être en mesure de basculer vers des systèmes distants. Tous les niveaux seraient étayés par des sauvegardes quotidiennes, ainsi que par une mise en scène vers des archives cloud et/ou sur bande à mesure que les données vieillissent.

La capacité de votre organisation à respecter les accords de niveau de service (SLA) RTO et RPO sera déterminée par l’ampleur de la panne, elle doit donc être élaborée conjointement avec une évaluation des risques et une analyse de l’impact sur l’entreprise qui examinent la gamme probable des causes potentielles de temps d’arrêt et les classent en termes de probabilité et d’effet. Une panne de disque est évidemment moins impactante qu’un site inondé, par exemple.

Stockage cloud et RTO/RPO

Lorsque vous déterminez les types de stockage et de protection des données adaptés à votre organisation et les différents systèmes qu’elle doit exploiter et protéger, vous êtes de plus en plus susceptible de devoir prendre en compte le stockage dans le cloud.

L’utilisation du cloud à côté du centre de données est à peu près courante, avec des enquêtes montrant que près de la moitié des clients utilisent le cloud pour la reprise après sinistre d’une manière ou d’une autre.

La difficulté qui apporte aux exigences et aux calculs RPO et RTO est que vous dépendez désormais d’un fournisseur externe. Assurez-vous donc de discuter en détail de vos exigences RPO et RTO pour différentes classes de données et de lier le fournisseur autant que possible avec des SLA clairs. Il peut y avoir d’autres complexités à travailler avec un fournisseur de cloud et des sites distants.

Ainsi, vous pouvez même considérer que certains systèmes et données ne peuvent pas être laissés à être régis par des SLA avec un tiers et constater que vous souhaitez les ramener en interne.