Comment calculer le RTO ?

Partager sur linkedin
LinkedIn

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.

Table des matières

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.

Envie d'en savoir plus sur le PRA ?

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 ?

antivirus anti-spam

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 :

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 :

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

expert axido chihah

Envie de limiter votre 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 :

RTO, RPO et PRA : quel est le lien ?

prestataire virtualisation

Les RTO et RPO sont des mesures pertinentes. Ils aident les entreprises à développer un plan de reprise 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. 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 :

Vous souhaitez en savoir plus ? 
Contactez-nous !


contact axido
Retour vers le haut

Découvrir la fiche produit PRA Informatique

Découvrir les fonctionnalités