La définition de vos objectifs de temps de récupération est cruciale, en particulier lorsque les piratages réseau et les attaques de ransomware sont en augmentation. Vous ne savez jamais quand vous êtes la prochaine victime. À ce stade, si votre objectif de temps de récupération n'est pas défini, comment élaboreriez-vous un plan de sauvegarde et de récupération des données ?
Cet article vous expliquera les bases du RTO et les facteurs à garder à l'esprit lors de la définition de votre RTO.
Qu'est-ce que l'objectif de temps de récupération ?
L'objectif de temps de récupération (RTO) est défini comme la durée maximale acceptable pendant laquelle une application peut être indisponible ou la panne maximale tolérable que l'organisation endure sans causer de dommages importants à une entreprise après qu'un sinistre, une panne ou tout autre événement inacceptable se soit produit.
Le temps RTO suggère le temps nécessaire pour récupérer et terminer la restauration du système d'un système défaillant tel que défini dans l'accord de niveau de service. L'objectif de niveau de service tient compte du temps de récupération défini par l'organisation pour récupérer/restaurer ses processus/opérations informatiques critiques à la normale à partir du moment où un sinistre se produit afin d'assurer la continuité des activités.
Pro Tip: Vous devez toujours chercher à atteindre le RTO le plus bas possible afin de minimiser l'impact d'un sinistre. Pour déterminer votre RTO, vous devez d'abord identifier l'effet de la durée sur votre entreprise pendant laquelle les données ne sont pas disponibles.
Par exemple :
- Si 10% des données doivent être disponibles dans les 24 heures,
- Et après une perte complète de la base de données, 50% des données doivent être disponibles sous 2 jours,
- Les 40 % de données restantes doivent être disponibles dans les 5 prochains jours, puis,
Votre RTO total est = 8 jours.
Pour citer un autre exemple :
Supposons que le serveur Exchange est en panne. Si votre RTO est de 5 heures, le temps d'arrêt maximal tolérable auquel votre entreprise peut survivre est de 5 heures, et votre RTO pour le serveur Exchange doit être inférieur à 5 heures. Votre politique de reprise après sinistre doit inclure les mesures nécessaires prises par le service informatique pour sauvegarder et restaurer les données.
Par conséquent, tout en fixant l'objectif de temps de récupération, il n'y a pas de solution unique pour un plan de continuité des activités. Les RTO peuvent être définis pour récupérer les données après un sinistre. Cependant, en cas d'incident, les aspects pratiques de votre plan de reprise après sinistre dépendent également des outils et de la technologie spécifiques utilisés pour assurer la reprise. Ainsi, la capacité d'atteindre le RTO varie en fonction des différentes technologies et des différents outils de reprise après sinistre dans leurs capacités. Le RTO est mesuré avant même le début de la panne et inclut le temps nécessaire pour réparer les serveurs, installer les applications prioritaires et restaurer les données. Il inclut également les méthodes de récupération et les données sauvegardées qui doivent être récupérées.
Que détermine le RTO ?
L'objectif de temps de récupération est une durée ciblée pendant laquelle les applications, les systèmes et/ou les processus survivent aux temps d'arrêt et ne fonctionnent pas avant le début de l'interruption. Le RTO est d'une importance primordiale pour déterminer la durée de hiérarchisation des applications et des processus dans les paramètres RTO. Dans le plan de protection des données et la stratégie de reprise après sinistre, RTO répond à la question : "Quel est le délai cible établi pour la restauration des services après une notification d'interruption de service ?"
Les RTO peuvent déterminer :
- La durée en temps réel à définir pour récupérer un site à partir du moment où l'incident interrompt le flux normal des opérations jusqu'à sa restauration
- Quelles préparations informatiques doivent être conçues pour la mise en œuvre du plan de reprise après sinistre
- Le niveau acceptable de risque de perte de données, lorsque le système ou les applications clés sont hors ligne.
Comment calculer le RTO pour la planification de reprise après sinistre ?
Une métrique RTO définit à l'avance l'attente cible pour l'équipe informatique, car elle détermine le seuil de rapidité avec lequel le système ou l'application peut être récupéré après le temps d'arrêt et remettre votre système en ligne. Après avoir défini cette mesure en termes de quantité de « temps réel » pour restaurer le système, vous pouvez alors planifier votre stratégie de récupération pour remettre le service en service. Pour calculer le RTO, vous devez prendre en compte les pertes associées à une interruption de l'objectif de temps de récupération du plan de continuité d'activité (BCP). Incluez également une analyse d'impact qui explique les effets à court ou à long terme de l'interruption des services. Cela inclut les risques, les pertes de revenus, les dépenses, les applications destinées aux clients, les applications critiques et les applications moins prioritaires qui sont affectées ou qui deviendront indisponibles. RTO est plus préoccupé par les temps d'arrêt et les limites de temps pour le processus de récupération de données.
Pour déterminer un RTO, vous aurez peut-être besoin de plusieurs catégories de RTO, car certaines pannes peuvent ne pas nécessiter beaucoup de temps de récupération, tandis que d'autres peuvent nécessiter différentes solutions de protection à long terme. Par exemple, le RTO peut être beaucoup plus long pour les applications moins critiques (peu utilisées fréquemment). En fonction des niveaux de complexité de plusieurs systèmes de sécurité en fonctionnement, vous devrez peut-être définir le RTO en fonction de sauvegardes à intervalles courts et longs. Cela peut se produire en raison d'un événement de ransomware ou d'un autre incident catastrophique massif.
Facteurs principaux à prendre en compte lors du calcul du RTO
- Équation coût/bénéfice des solutions de récupération
- Applications prioritaires des systèmes et données individuels
- Mesures à prendre par le service informatique en fonction des processus, des techniques automatisées ou des technologies pour restaurer l'infrastructure informatique
- Coût de la panne et de l'atténuation
- La complexité de la procédure de recouvrement
Intervalles d'échantillonnage RTO
Atteindre un RTO proche de zéro est coûteux pour la plupart des entreprises informatiques, mais il est possible d'y parvenir si vous accordez la priorité aux applications et aux données. Pour les applications moins critiques pour l'entreprise, l'horloge RTO peut consommer des temps objectifs plus longs que d'habitude. Les plans RTO proches de zéro pour les applications critiques peuvent vous obliger à envisager une capacité de basculement immédiate.
En fonction de la gravité de la panne, vous pouvez définir le temps RTO cible réalisable. Cependant, le temps de restauration du RTO dépend également des limites de l'organisation informatique. Par exemple, si la restauration de toutes les fonctions et opérations informatiques prend 3 heures, le RTO doit être d'au moins 3 heures.
Notes: Du point de vue de la reprise après sinistre (DR), l'horloge RTO démarre juste au moment où les processus de récupération démarrent.
Lorsque vous calculez le RTO (Recovery Time Objective) pour vos unités commerciales, tenez compte des exemples d'intervalles suivants :
1 heure
Cet intervalle est destiné à la sauvegarde des données redondantes sur les disques durs externes.
5 Jours
Dans ce cas, la solution la plus rentable serait de sauvegarder les données à l'aide d'un disque compact, d'une bande ou d'un stockage sur disque hors site.
Atteindre le RTO, la méthode Zmanda
Objectif de temps de récupération (RTO) et Objectif de point de récupération (RPO) sont des objectifs extrêmement importants et constituent le fondement d'un plan de relance. Comment déterminez-vous la série d'étapes des objectifs pratiques de récupération ? Voilà où nous pouvons vous aider!
Avec le plan DRaaS de Zmanda et les accords de niveau de service personnalisés, quelle que soit la taille de votre entreprise, nous pouvons vous aider à réduire les temps d'arrêt et à éviter les temps d'arrêt en fonction des besoins de votre entreprise. Outre les sauvegardes hybrides pour prendre en charge la transition et atteindre des RTO relativement plus rapides, notre solution d'entreprise combine Amazon Glacier avec un coût 20 fois inférieur d'archivage de données à long terme qui déploie une haute disponibilité robuste et assure la continuité des activités.
Notre solution de sauvegarde d'entreprise unifie la sauvegarde, la reprise après sinistre et l'archivage de stockage à long terme spécifiquement adaptés aux besoins des clients. Cela offre sécurité, fiabilité, évolutivité et disponibilité tout en récupérant votre environnement même en cas de panne totale du serveur.
Voyez-le par vous-même ! Commençons par un essai gratuit pour élaborer une stratégie de sauvegarde de vos données ou demander un demo. Vous avez des questions ? Veuillez nous contacter ici.
