RPO et RTO - objectif du point de récupération et objectif de temps de récupération - sont des mesures vitales lors du développement de plans et de stratégie de reprise après sinistre (DR).
Ils sont fondamentaux pour déterminer les détails de la façon dont vous vous remettrez d'une panne imprévue, que ce soit technique ou, de plus en plus, en raison d'une intention malveillante, comme le ransomware.
En effet.
Cet article examinera comment nous définissons le RPO et le RTO, pourquoi ils sont importants, et comment les calculer pour votre organisation et les fonctions en son sein.
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: «La période de temps dans laquelle les niveaux minimum de services et / ou de produits et les systèmes de support, applications ou fonctions doivent être récupérés après une perturbations'est produit."
Le RPO, quant à lui, est défini comme: «Le moment où les données doivent être récupérées après une perturbation s'est produite."
En anglais simple, RTO est le temps que vous pouvez vous permettre les systèmes et les données pour être indisponibles.Il est mesuré dans le temps et est la période dans laquelle vous avez besoin que les systèmes soient restaurés après une panne.
RPO est la quantité de données que vous pouvez vous permettre de perdre.Il est également mesuré dans le temps, mais vu à travers l'objectif de la quantité de données que vous pouvez vous permettre de perdre.Ainsi, il sera régi par combien de temps il était à la dernière sauvegarde et / ou instantané ou à quel point les données sont récentes sur un site auquel vous basculez.
Ainsi, par exemple, une organisation peut déterminer qu'elle peut fonctionner avec un RTO d'une heure et un RPO de deux heures de données.
L'image est susceptible d'être moins simple que cela, cependant.
Différents RTO et RPO pour différentes applications?
Mais le paysage d'application au sein d'une organisation ne se prête pas à des métriques couvertes qui couvrent tout.
La réalité est que les RTO et RPO granulaires sont probablement ce qui est nécessaire pour répondre aux situations du monde réel.
Ainsi, par exemple, si tous vos systèmes baissaient, la priorité serait de restaurer celles qui sont destinées au public et productrices de revenus, qui peuvent inclure des applications transactionnelles très critiques.
Celles-ci seraient de la plus haute priorité et occuperaient l'extrémité opposée du continuum de, disons, des données archivées à longue et inutilisées ou des données non structurées sans contraintes de temps critique.
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 de RTO et RPO
Le point de départ est de déterminer le niveau de risque pour l'organisation des systèmes indisponible et pendant quelle durée qui peut être tolérée.
Il est logique de classer et de hiérarchiser les systèmes et de poser des questions telles que:
Exemples RPO et RTO
Les RPO et RTO idéaux seraient nuls.Mais plus vous vous rapprochez de zéro, plus il en coûte.
Ainsi, Zero n'est pas une option pour la plupart.
Plus réaliste, vous classeriez probablement les applications et les systèmes par niveau.Ainsi, par exemple:
Méthode de niveau RTO / RPO et 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'écrits doubles et / ou de réplication fréquente des données pour protéger contre les problèmes localisés.Il aura probablement besoin de la capacité de basculer rapidement vers un emplacement éloigné en cas de menaces au niveau du site.
Les systèmes de niveau 2 auraient besoin d'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 soutenus par des sauvegardes quotidiennes, ainsi que par la mise en scène des archives des nuages et / ou des bandes à mesure que les données vieillissent.
La capacité de votre organisation à respecter les accords de niveau de service RTO et RPO (SLAS) sera déterminée par la portée de la panne, il faut donc être élaboré en conjonction avec une évaluation des risques et une analyse d'impact commercial qui examine la gamme probable des causes potentiellesdes temps d'arrêt et les classe en termes de probabilité et d'effet.Une défaillance du disque est évidemment moins percutante qu'un site inondé, par exemple.
Stockage cloud et RTO / RPO
Lorsque vous élaborez les types de stockage et de protection des données adaptés à votre organisation et aux différents systèmes qu'il doit opérer et protéger, vous devez de plus en plus tenir compte du stockage du cloud.
L'utilisation du cloud aux côtés du centre de données est à peu près courant, les enquêtes trouvant près de la moitié des clients utilisant le cloud pour la reprise après sinistre d'une manière ou d'une autre.
La difficulté qui apporte aux exigences et calculs RPO et RTO est que vous dépendez maintenant d'un fournisseur externe.Alors, assurez-vous de discuter en profondeur de vos exigences RPO et RTO pour différentes classes de données et liez le fournisseur autant que possible avec des SLA clairs.Il peut y avoir d'autres complexités travaillant 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 être laissés à être régis par SLAS avec un tiers et constater que vous voulez les ramener en interne.
