Introducing G2.ai, the future of software buying.Try now

Pourquoi votre entreprise a besoin d'un objectif de temps de récupération pour survivre

14 Juillet 2022
par Keerthi Rangan

Parfois, les choses tournent mal. Malgré toute la planification du monde, les choses peuvent, et vont, mal tourner.

La clé est de se préparer à l'échec. Cela signifie prédire les catastrophes et planifier à l'avance pour « que se passera-t-il quand cela arrivera ? ». Mais vos meilleures stratégies et mécanismes de basculement pendant une panne peuvent être vains si vous ne savez pas combien de temps vos systèmes seront hors service ou quelles applications sont les plus critiques pour les opérations commerciales continues.

Les objectifs de temps de récupération (RTO) sont une étape essentielle dans la définition de votre plan de continuité des activités et de reprise après sinistre (BCDR). Les RTO vous obligent à analyser soigneusement vos applications et leur importance relative pour votre entreprise.

Choisir un logiciel de reprise après sinistre en tant que service (DRaaS) permet aux entreprises de mettre en œuvre une solution simple mais puissante avec un RTO faible pour minimiser la perte de données critiques et l'impact financier.

Le RTO est une métrique importante pour savoir à quelle vitesse et avec quelle efficacité vous pouvez récupérer des informations en cas de catastrophe. Savoir combien de temps vos données doivent survivre peut vous aider à établir une stratégie de sauvegarde efficace et un plan d'achat de matériel informatique global.

Pour garantir un RTO approprié, les départements informatiques utilisent le basculement pour éviter les temps d'arrêt et faciliter une transition en douceur entre les systèmes. Lorsqu'une catastrophe survient, votre entreprise doit être prête pour une récupération rapide. De plus, votre équipe informatique doit développer des plans de contingence pour savoir quelles applications récupérer et à quelle vitesse.

Chronologie RTO

Les équipes informatiques s'assurent également que les applications disposent d'une sauvegarde fiable prête à minimiser les temps d'arrêt. De cette façon, d'autres serveurs peuvent prendre le relais et faire fonctionner votre application en quelques secondes en cas de catastrophe.

Vous pouvez mesurer les RTO en secondes, minutes, heures et jours. Gardez ces unités à l'esprit lors de l'élaboration d'un plan de reprise après sinistre (DRP).

Pour faciliter un DRP efficace, les administrateurs peuvent choisir les solutions de reprise après sinistre (DR) les mieux adaptées à un RTO défini. Par exemple, si le RTO d'une application est d'une heure, une sauvegarde de base de données redondante sur des systèmes distants pourrait être la solution idéale. Le stockage sur bande ou dans le cloud hors site est plus envisageable si le RTO est de cinq jours.

Pourquoi l'objectif de temps de récupération est-il important ?

Les temps d'arrêt sont coûteux. Quarante-quatre pour cent des entreprises rapportent que le coût horaire des temps d'arrêt, y compris le temps du personnel informatique interne et externe, la perte de productivité et le remplacement du système informatique, dépasse facilement 1 million de dollars. Avec tant de choses dépendant de votre infrastructure informatique et de votre disponibilité, les objectifs de temps de récupération garantissent que les entreprises sont bien préparées aux temps d'arrêt et à la récupération.

Les RTO vous permettent de planifier la rapidité avec laquelle vous pouvez récupérer une application critique si elle échoue. Les RTO sont généralement mesurés en secondes. Si une application n'est pas disponible pendant cinq secondes, payer des développeurs pour restaurer les données à la volée n'a pas de sens. Au lieu de cela, les applications prioritaires devraient avoir des systèmes de basculement qui commencent le processus de restauration avant qu'elles ne deviennent inopérantes.

Dans le cas peu probable d'une panne prolongée de serveur ou d'un événement de corruption de données prolongé, vous ne voudriez pas que les efforts de récupération coûteux soient gaspillés en essayant de récupérer des données avant d'épuiser toutes les sauvegardes disponibles. Les RTO permettent aux organisations de prioriser leurs investissements et d'allouer des budgets en conséquence.

Pour déterminer un cadre RTO pratique, séparez les applications à haute priorité. Commencez par mettre en place un processus qui détermine le risque de perte de votre organisation.

Vous pouvez établir des RTO appropriés avec un processus d'évaluation des risques qui identifie les composants à valeur ajoutée et critiques de votre opération. Les applications à haute priorité traitent généralement des comptes clients, du service client et des applications critiques pour la mission, telles que les opérations de fabrication ou de logistique qui dépendent fortement de la technologie.

Vous voulez en savoir plus sur Solutions de reprise après sinistre en tant que service (DRaaS) ? Découvrez les produits Récupération après sinistre en tant que service (DRaaS).

Comment fonctionne l'objectif de temps de récupération ?

Les objectifs de temps de récupération déterminent combien de temps une entreprise peut durer après un revers avant de se rétablir complètement. Par exemple, une entreprise avait un RTO de 24 heures il y a quelques années. Dans ce cas, elle peut prospérer pendant au moins 24 heures sans accès à ses données et systèmes habituels avant de subir des dommages irréversibles.

Les RTO ne sont pas stricts car ils ne spécifient pas une date de récupération. Ils vous permettent de vous concentrer davantage sur l'approche d'un potentiel spécifique via une planification et une évaluation rigoureuses que sur l'objectif ultime.

De nombreux facteurs influencent les temps de récupération, y compris l'heure du jour et de la semaine où l'incident s'est produit. Ils impactent également à la fois les RTO et les objectifs de point de récupération (RPO). Les applications à haute priorité exigent des objectifs plus stricts. Pour de telles applications, l'équipe informatique doit organiser une réplication continue et par instantané.

Exemples d'intervalles de RTO

Le RTO est un temps d'endurance après qu'une menace a été détectée. La plupart des entreprises informatiques ne peuvent pas se permettre d'atteindre un RTO proche de zéro. Cependant, elles peuvent optimiser les applications et services pour se rapprocher le plus possible d'un objectif spécifique. Pour les applications moins critiques, la valeur RTO peut nécessiter des périodes plus longues que d'habitude. Les plans de RTO proche de zéro pour les applications critiques nécessitent une capacité de basculement instantanée.

Selon la gravité de la perturbation, vous pouvez définir un objectif RTO réaliste pour la récupération des données. Cependant, le temps de restauration dépend également des limitations d'une entreprise. Par exemple, si la restauration de tous les services et processus informatiques prend trois heures, le RTO doit être d'au moins trois heures.

Le chronomètre RTO démarre instantanément lorsque le processus de reprise après sinistre commence. Considérez la répartition suivante des catégories de RTO lors du calcul du RTO pour vos unités commerciales :

  • Une heure : Utile pour les processus nécessitant une sauvegarde de données redondantes sur des disques durs externes.
  • Cinq jours : Sauvegarder des données sur un disque compact, une bande ou un stockage de disque distant est la méthode la plus rentable en cas de catastrophe.

Exemples d'objectifs de temps de récupération

Selon l'analyse d'impact sur les affaires (BIA), l'objectif de temps de récupération pour une panne d'application ou de service peut être légèrement différent. Les applications critiques pour la mission, par exemple, ont souvent un RTO plus bas. En revanche, les services moins critiques ont un RTO plus étendu, car la durée d'une panne et la tolérance à la perte associée sont plus grandes.

Voici quelques exemples de RTO :

  • Services financiers : Ce sont des services à haute priorité, avec un RTO aussi proche de zéro que possible.
  • Email : Bien que l'email soit un service essentiel pour beaucoup, le temps de récupération peut prendre jusqu'à 4 heures. Les pannes d'email ne se traduisent pas toujours directement par une perte de revenus.
  • Services d'impression : C'est gênant et parfois coûteux lorsqu'une imprimante est en panne ou inutilisable. Ces pertes sont bien inférieures à celles encourues lors d'une panne de services financiers ou même d'une panne d'email. Le RTO pour les serveurs d'impression peut atteindre 24 heures dans des circonstances extrêmes.

Facteurs influençant l'objectif de temps de récupération

Lors de la détermination du rythme de récupération pendant une sauvegarde à long intervalle, vous devez toujours définir le RTO en fonction des moments où l'application ou le système de sécurité est en service. Comme le RTO est "sensible au temps" pour les applications couramment utilisées, vous devez tenir compte des facteurs suivants lors du calcul du RTO :

  • Analyse coût-bénéfice pour les systèmes de récupération
  • Coûts de panne et de remédiation
  • Défis du processus de récupération
  • Efforts des équipes informatiques pour réparer l'infrastructure
  • Utilisation prioritaire de systèmes et de données spécifiques

RTO dans la planification de la reprise après sinistre

La reprise après sinistre est un plan clair qui aide une entreprise à se rétablir et à reprendre ses opérations commerciales normales. Cela rend la définition du RTO vitale pour un plan de continuité des activités (BCP). Avec un objectif de temps de récupération comme objectif principal, une entreprise peut réaligner ses stratégies de sauvegarde de données et de basculement et déployer la quantité appropriée de nouveaux services. Cela garantit une vitesse de récupération cible.

Sans RTO, une entreprise n'a aucune idée de la rapidité avec laquelle elle doit se remettre d'une menace grave ou d'une perte de données. La planification de la reprise après sinistre consiste à être équipé pour les pannes imprévues. Pour être préparé, vous avez besoin d'un indice ou d'un plan pour estimer le temps de récupération.

Les entreprises devraient établir un plan de continuité des activités solide avec des objectifs prédéfinis dans le cadre du processus de planification de la reprise après sinistre. Ces objectifs devraient inclure le RTO et le RPO pour garantir un taux de récupération attendu.

RTO vs. RPO

Bien que l'objectif de temps de récupération et l'objectif de point de récupération soient des composants essentiels de la reprise après sinistre et de la planification de la continuité des activités, ils servent des objectifs différents. Ces objectifs peuvent aider à sélectionner une stratégie de sauvegarde de données appropriée et fournir un cadre pour identifier et évaluer les solutions potentielles pour reprendre les opérations commerciales dans un délai proche ou égal au RPO et au RTO.

RTO vs. RPO

L'objectif de temps de récupération fait référence à la mise en place de politiques et de technologies pour qu'une entreprise se rétablisse dans un délai donné. En comparaison, l'objectif de point de récupération garantit que les solutions de récupération et de sauvegarde des données sont en place à l'avance pour minimiser la quantité de données perdues lors d'une urgence.

Le RTO et le RPO travaillent ensemble pour restaurer les activités régulières d'une entreprise. Ils déterminent l'impact commercial en tenant compte du temps nécessaire pour restaurer les services et de la tolérance maximale aux pertes d'une organisation.

Comment calculer l'objectif de temps de récupération

Calculer les objectifs de récupération est un processus en plusieurs étapes qui implique divers facteurs, y compris l'analyse d'impact sur les affaires, la stratégie de reprise après sinistre et les plans de continuité. L'objectif principal d'un RTO est d'évaluer combien de temps il faut pour se remettre d'une catastrophe grave et restaurer les opérations commerciales normales.

Lors du calcul du RTO, rappelez-vous que vous aurez des RTO uniques pour chaque service ou application. Par exemple, votre tolérance aux temps d'arrêt sur votre serveur de messagerie devrait être significativement inférieure à celle d'un serveur de fichiers rarement utilisé. Considérez ces facteurs pour que votre stratégie de reprise après sinistre soit aussi efficace et réussie que possible.

La première étape pour calculer un RTO est d'évaluer minutieusement tous les systèmes, applications critiques pour la mission, environnements virtuels et silos de données. Il n'y a aucun moyen d'établir correctement un RTO sans un audit complet.

Après avoir terminé l'évaluation, la tâche suivante est de calculer la qualité de chaque service et application critique pour la mission en termes de leur impact sur les processus commerciaux. Cette valeur doit être calculée de manière granulaire et liée au temps. La valeur de l'application peut être liée à tout accord de niveau de service (SLA) actuel qui définit à quel point un service doit être accessible et peut inclure des répercussions si certains niveaux de service ne sont pas atteints.

Vous pouvez estimer le RTO en évaluant la valeur de tous les services et applications fonctionnels. Cependant, gardez à l'esprit que les exigences en matière de RTO peuvent varier en fonction de l'importance d'un service mesurée par la valeur qu'il apporte à l'entreprise.

Calculer le RTO implique de déterminer à quelle vitesse le processus pour un programme, un service, un système ou des données particuliers doit reprendre après un incident majeur. Cela est basé sur la tolérance aux pertes de l'entreprise dans le cadre de son BIA. Définir la tolérance aux pertes aide à établir combien de temps de fonctionnement une entreprise peut se permettre de perdre lors d'un événement avant que les opérations commerciales normales ne reprennent.

Impliquez également tous les parties prenantes de votre entreprise dans le processus. Bien que l'impact financier des temps d'arrêt soit probablement en tête de votre liste de priorités, il est essentiel de comprendre comment les temps d'arrêt affecteront chaque aspect de votre entreprise avant de développer un plan qui fonctionne pour tout le monde.

Défis du RTO

Il n'est souvent pas faisable pour une entreprise de reprendre immédiatement toutes les opérations après un revers. Le RTO est le point anticipé auquel une entreprise doit restaurer ses fonctions pour éviter toute complication liée aux objectifs. Les RTO diffèrent pour différentes opérations. Un processus crucial pourrait avoir un RTO échelonné pour permettre aux opérations de reprendre progressivement. Par exemple, une activité pourrait être à 40 % de capacité en trois jours et à 100 % en huit jours.

L'un des défis les plus complexes dans la définition des RTO est la possibilité de menaces ou de crises imprévues perturbant les flux de travail. Ces risques incluent l'effondrement d'une installation, des perturbations dans une zone de traitement, des pannes de connectivité dues à des catastrophes naturelles et une pénurie d'employés de traitement en raison de grèves ou de problèmes de transport.

Ces circonstances uniques qui affectent négativement les processus existent en dehors des RTO définis. Cela est dû au fait que le temps nécessaire pour les résoudre ne peut pas être estimé ou planifié. Dans de tels cas, éviter les risques est préférable à la mise en place d'un RTO.

Par exemple, une entreprise avec d'excellents processus de sécurité peut éviter de nombreuses violations de sécurité. Le taux de criminalité global dans leur région et les spécificités de l'entreprise influencent la sécurité.

Ne laissez pas les temps d'arrêt détruire votre succès

Il est crucial d'établir votre RTO et RPO et de mettre en place les services qui les soutiennent. Cependant, ces métriques sont inutiles à moins que vous ne testiez régulièrement vos systèmes et vous assuriez que les technologies de sauvegarde de données et de basculement de système sont opérationnelles. Les tests réguliers sont la clé du succès.

Planifiez les catastrophes avant qu'elles ne se produisent. Améliorez votre reprise après sinistre avec DRaaS.

Keerthi Rangan
KR

Keerthi Rangan

Keerthi Rangan is a Senior SEO Specialist with a sharp focus on the IT management software market. Formerly a Content Marketing Specialist at G2, Keerthi crafts content that not only simplifies complex IT concepts but also guides organizations toward transformative software solutions. With a background in Python development, she brings a unique blend of technical expertise and strategic insight to her work. Her interests span network automation, blockchain, infrastructure as code (IaC), SaaS, and beyond—always exploring how technology reshapes businesses and how people work. Keerthi’s approach is thoughtful and driven by a quiet curiosity, always seeking the deeper connections between technology, strategy, and growth.