Comment calculer le RTO ?
Comment faire la maintenance d’un serveur ?
23 avril , 2022
Axido obtient le label Expert Cyber certifié par l’Etat
6 mai , 2022
Le RTO ou Recovery Time Objective est un point clé de l’opération et de la configuration de la stratégie de sauvegarde et il est essentiel de savoir comment le calculer pour garantir le temps d’arrêt le plus bas pour vos applications et services.
Les entreprises doivent tenir compte des implications des temps d’arrêt et se concentrer sur la sécurité informatique entreprise, ainsi que le maintien de la continuité des opérations commerciales. Pour ce faire, un plan approprié pour une continuité d’activités et de reprise après sinistre ou PRA doit être mis en œuvre pour leur permettre de minimiser les temps d’arrêt ou de les éviter complètement. De cette façon, les entreprises peuvent s’assurer que leur infrastructure informatique est résiliente.
Les entreprises qui demandent un RTO zéro avec des dépenses minimales se trouvent dans une situation assez courante, mais pour obtenir un tel résultat, de gros investissements et un environnement redondant et hautement sécurisé sont nécessaires. Toutes les entreprises ne peuvent se permettre de telles dépenses. Aussi, pour les rendre opérationnelles, devriez-vous tenir compte de l’équilibre entre l’abordabilité et une protection fiable des données.
Le RTO : kesako ?
Le RTO ou Recovery Time Objective est le délai dans lequel les applications et les systèmes doivent être restaurés après une panne. Il détermine la durée pendant laquelle une application ou un système est autorisé à rester inopérant sans causer de dommages importants à l’entreprise. Pour le dire simplement, le RTO mesure le temps d’arrêt toléré selon le plan de reprise d’activité (PRA) après sinistre.
En cas de pannes inattendues, un ou deux systèmes peuvent tomber en panne et vous devrez faire face à des temps d’arrêt jusqu’à ce que cela soit résolu. Cela vous met dans une situation où vous devez déterminer le délai dans lequel vous devez restaurer le système afin que vos opérations commerciales ne soient pas interrompues. C’est là que RTO entre en jeu.
Définir le RTO implique de comprendre la tolérance de temps d’arrêt de chaque système et pour chacune de vos applications, vous aurez probablement des RTO différents. Une fois que vous avez défini la métrique RTO, vous êtes prêt à planifier la récupération qui inclut la stratégie de récupération et la technologie dont vous avez besoin pour une restauration réussie et rapide après un temps d’arrêt.
Un exemple de RTO : En raison de problèmes avec le serveur Microsoft Exchange, les applications qui incluent les services de messagerie, de calendrier et de collaboration (tels que Teams) tombent en panne. Si votre RTO est fixé à huit heures, cela signifie que le temps d’arrêt maximal tolérable auquel votre entreprise peut survivre est de huit heures, et votre RTO pour le serveur Exchange doit être inférieur à huit heures pour éviter de graves dommages à l’entreprise.
Comment se calcule le RTO ?
Lors de l’établissement d’un niveau acceptable de temps d’arrêt, il peut être tentant de simplement demander des informations aux utilisateurs. Après tout, ce sont eux qui savent combien de temps ils peuvent se passer de leurs applications, non ? Eh bien, ce n’est peut-être pas le cas. En général, lorsque vous posez la question aux utilisateurs finaux, vous obtenez une réponse assez vague qui peut être trop courte.
C’est pourquoi, comme dans la plupart des cas dans la vie, la réponse doit être trouvée dans des données objectives. Voici deux étapes pour calculer le RTO :
- Dresser une liste complète de tous les systèmes et applications que l'entreprise utilise pour son activité ; après quoi il faut déterminer le rôle couvert par chacun de ces éléments.
- Calculez les pertes qui pourraient potentiellement survenir si le système ou l'application étaient indisponibles : perte de chiffre d'affaires ou de ventes, salaires versés aux employés inactifs, dépenses supplémentaires causées par le manque d'accès, atteinte à la réputation de l'entreprise... Ce calcul doit être fait individuellement pour chaque application sans oublier de tenir compte de la saisonnalité car à certaines périodes de l'année les conséquences peuvent être considérablement plus lourdes que d'autres.
Une fois ces détails définis, le vrai plaisir commence : déterminer exactement combien de temps il faudra avant que ces pertes ne deviennent inacceptables. Bien que la valeur précise dépende des caractéristiques spécifiques de l’entreprise, quelques questions peuvent vous aider à perfectionner votre RTO idéal :
- Conservez-vous des données pour le compte de vos clients ? Si oui, quels sont les accords et obligations liés à ce service ? Cela peut affecter la rapidité avec laquelle il faut récupérer ces données.
- Vous avez des clients qui ont besoin de pouvoir accéder à vos données en temps réel ? Un exemple serait celui des systèmes de point de vente.
- Quels systèmes sont liés aux addictions ? Par exemple, en cas de perte de base de données, quelles applications seraient affectées et quelles sont les exigences de disponibilité correspondantes ?
- Quels systèmes entraîneraient des pertes financières directes s'ils n'étaient pas disponibles ? Par exemple un site e-commerce.
- Quels systèmes provoqueraient l'arrêt de la production en cas d'indisponibilité ? Par exemple le contrôle qualité ou les systèmes de contrôle industriels.
Une fois que vous avez répondu à toutes ces questions et calculé les temps de récupération pour chaque application et chaque système, votre RTO global est déterminé de l’une des manières suivantes : soit il existe une application qui peut causer des dommages et des pertes beaucoup plus importants que les autres, et alors le RTO est le temps nécessaire pour restaurer cette application ; ou si toutes les applications ont un impact similaire sur l’entreprise, il suffit de calculer la moyenne mathématique et de l’utiliser comme RTO.
La dernière étape consiste à effectuer un test de récupération de tous les systèmes et applications. Le temps requis pour cette procédure est appelé RTA (Recovery Time Actual), et votre objectif est de rendre le RTO et le RTA égaux.
Bien que vous puissiez déterminer le RTO et le gérer en interne, le faire sous-traiter à un fournisseur de service d’infogérance informatique disposant des dernières technologies et capable de vous expliquer des problèmes complexes permet d’avoir un chiffre bien plus précis.
Les mesures pour limiter le RTO
Nos experts répondent à toutes vos interrogations !
Vous pouvez faire certaines choses pour limiter votre RTO et réduire le temps d’arrêt potentiel dont votre entreprise aura besoin pour récupérer des données cruciales en cas de panne de serveur :
- Assurez-vous d'avoir établi un solide plan de reprise après sinistre. Un plan de reprise après sinistre (PRA informatique) décrit les solutions pour tous les types de perturbations des opérations. Il doit être organisé par type de catastrophe et par lieux et contenir également des scripts permettant à quiconque de les exécuter en cas de besoin. La mise en place d'un PRA informatique complet vous aidera non seulement à vous préparer aux événements d'indisponibilité imprévus, mais vous de prendre les mesures appropriées en cas d’indisponibilité.
- Planification de sauvegardes régulières : L'augmentation de la fréquence de vos sauvegardes peut raccourcir votre temps de récupération et réduire votre RPO ou la quantité de données que vous risquez de perdre si votre système tombe en panne.
- Mettre en œuvre des procédures en cas d'indisponibilité du système d'une entreprise : Une étape importante dans la réduction des temps d'arrêt consiste simplement à prendre les précautions nécessaires pour garantir que votre entreprise reste productive en cas de catastrophe. Il est utile pour les entreprises de créer une liste de tâches et d'objectifs à accomplir lors de la gestion des temps d'arrêt du système. Les pannes sont imprévisibles et être proactif dans leur préparation est une stratégie simple et efficace.
- Former les employés : L'erreur humaine est l'une des principales causes de temps d'arrêt. Cependant, la fréquence des erreurs humaines peut être considérablement réduite grâce à une formation régulière des employés. Vos employés doivent être conscients des cybermenaces émergentes telles que les logiciels malveillants, les rançongiciels et les attaques de phishing, et suivre strictement les politiques et procédures informatiques standard définies par votre organisation.
- Opter pour les services externalisés : Lorsque vous confiez votre technologie à un fournisseur de services gérés, vous bénéficiez d'une équipe d'experts informatiques fiables dans votre coin, qui s'assurent que vos systèmes sont optimisés et préparés avec une surveillance, des mises à jour du système et un plan de continuité d’activités. Ne laissez pas le coût des temps d'arrêt être votre perte.
RTO, RPO et PRA : quel est le lien ?
Les RTO et RPO sont des mesures pertinentes. Ils aident les entreprises à développer un plan reprise d’activité informatique après sinistre (PRA) approprié pour maintenir la continuité des activités après un événement inattendu. Avec le support des métriques, les heures maximales tolérables pour une récupération de données peuvent être déterminées, des cycles de sauvegarde de données peuvent être configurés et les méthodes du processus de récupération peuvent être définies. RTO et RPO servent la même chose, mais ce sont deux métriques différentes.
Il s’agit du temps pendant lequel vous pouvez vous passer de certains services ou applications avant de perdre plus d’argent que vous ne pouvez vous le permettre. Le RTO dépend des besoins de l’entreprise et un plan de reprise après sinistre doit tenir compte de ce facteur. RTO est souvent utilisé avec les termes RPO (Recovery Point Objective) qui est la quantité acceptable de données qu’une société informatique peut se permettre de perdre entre la dernière sauvegarde de VM (Virtual Machine) et le moment de la panne informatique.
Ces derniers quantifient les pertes pouvant survenir en cas de défaillance des systèmes critiques et définissent des protocoles de redémarrage des services pour reprendre les opérations et respecter les accords de niveau de service (SLA). Essentiellement, ils fournissent une toile de fond réaliste dans laquelle les responsables informatiques peuvent planifier et exécuter un plan de reprise après-sinistre (PRA) réussi. Une des principales raisons pour lesquelles vous devez investir dans la compréhension et l’établissement de RPO et RTO est d’augmenter l’efficacité du PRA PCA. En cas d’interruption, aucune entreprise ne peut subir une perte de données et de réputation sans RPO et RTO. Vous n’aurez aucune idée de combien et pendant combien de temps votre entreprise peut se permettre une perte de données. Un RPO et un RTO efficaces donnent tous deux à votre PRA une couche plus pragmatique, rendant les politiques plus efficaces. Il existe, cependant, quelques différences essentielles entre les deux, notamment :
- La base d'évaluation. Le RTO reflète les besoins globaux de votre entreprise. C'est une mesure de la durée pendant laquelle votre entreprise peut survivre avec une infrastructure et des services informatiques interrompus. En revanche, le RPO concerne uniquement les données. Il détermine la fréquence de sauvegarde des données et ne reflète pas les autres besoins informatiques.
- La pertinence des coûts. Les coûts associés au maintien du RTO souhaité peuvent être supérieurs à ceux d'un RPO. En effet, le RTO implique l'ensemble de votre infrastructure commerciale, et non pas uniquement les données.
- La facilité de calcul. À certains égards, le RPO est plus facile à évaluer car l'utilisation des données est relativement cohérente et il y a moins de variables. Étant donné que le temps de récupération affecte l'ensemble de votre opération, pas seulement les données, c'est plus compliqué. Le temps de récupération peut dépendre de facteurs tels que l'heure de la journée ou le jour de la semaine où l'événement perturbateur se produit. Les administrateurs doivent avoir une bonne compréhension des vitesses auxquelles différents types de restaurations peuvent avoir lieu pour les différents types de systèmes. Ce n'est qu'alors qu'un RTO peut être correctement négocié en fonction des besoins des propriétaires d'entreprise.
Quelle différence entre le RTO et le RPO ?
Le RTO (Recovery Time Objective) et le RPO (Recovery Point Objective) sont deux concepts clés dans la gestion de la continuité des activités et la planification de la reprise après sinistre. Bien qu’ils soient tous deux liés à la récupération des systèmes informatiques, ils se concentrent sur des aspects différents. Le RTO représente le laps de temps maximal acceptable pour restaurer les systèmes après un incident. Il s’agit essentiellement de la durée pendant laquelle une organisation peut se permettre d’être hors service sans subir de conséquences graves. Par exemple, si le RTO est fixé à quatre heures, cela signifie que les systèmes doivent être opérationnels dans ce délai pour minimiser l’impact sur les opérations commerciales.
D’autre part, le RPO est une mesure de l’acceptabilité de la perte de données. Il détermine la période maximale durant laquelle les données peuvent être perdues sans compromettre l’intégrité des activités. Par exemple, si le RPO est de deux heures, cela signifie que les données doivent être sauvegardées au moins toutes les deux heures afin de minimiser les pertes potentielles en cas d’incident.
En résumé, la principale différence entre le RTO et le RPO réside dans le temps : le RTO se concentre sur la restauration des systèmes dans un délai spécifié, tandis que le RPO se concentre sur la fréquence à laquelle les données doivent être sauvegardées pour minimiser la perte potentielle. Ces deux paramètres sont essentiels pour garantir la résilience des systèmes informatiques et assurer une reprise rapide après un sinistre.
