Comment migrer sans heurt vers le cloud hybride ?
En savoir plus >
Comment migrer sans heurt vers le cloud hybride ?
En savoir plus >
Comment migrer sans heurt vers le cloud hybride ?
En savoir plus >
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 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.
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.
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 :
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 :
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.
Test