Qu’est-ce que le RTO et le RPO dans la reprise après sinistre ?
Dans la reprise après sinistre, ces chiffres déterminent la durée d’indisponibilité de votre organisation et la quantité de données qui pourraient être perdues. Dans ce contexte important, qu’est-ce qu’un » bon » objectif de point de récupération ou un » bon » objectif de temps de récupération ? La réponse n’est pas simple. Un bon RPO/RTO standard dépend du type de catastrophe ainsi que de la période maximale tolérable de perturbation.
D’abord, il est important de définir l’ensemble potentiel de catastrophes contre lesquelles vous souhaitez protéger votre organisation. Voici quelques catastrophes qui nécessitent une récupération et une sauvegarde des données :
- La perte de données : Cela peut être aussi simple qu’une personne supprimant un dossier, ou aussi complexe qu’un cas de ransomware ou une base de données infectée.
- Perte d’une application : Il s’agit du cas où des modifications de la sécurité, une mise à jour ou des configurations du système ont un impact négatif sur les services.
- Perte d’un système : Cela inclut lorsque le matériel tombe en panne, ou, si vous avez un serveur virtuel, lorsque le système d’exploitation tombe en panne.
- Perte de l’emplacement de l’entreprise : Dans ce cas, une catastrophe peut inclure une panne électrique, un incendie, une inondation ou même un déversement de produits chimiques à l’extérieur du bâtiment. Les installations de l’entreprise nécessitent une récupération vers un autre emplacement.
- Perte des opérations : Il s’agit d’un arrêt complet des activités de l’entreprise – c’est-à-dire le pire des scénarios.
Chacun de ces scénarios potentiels illustre à quel point il est important de prendre en compte vos données, vos systèmes, vos applications et votre emplacement physique dans votre stratégie de reprise après sinistre. Ces facteurs jouent un rôle dans les valeurs RTO et RPO. Une fois que vous avez défini les scénarios de catastrophe particuliers contre lesquels vous espérez vous protéger, vous pouvez hiérarchiser les scénarios que votre client souhaite le plus prévenir, puis mettre en œuvre des fonctionnalités de protection des données qui correspondent à ses exigences en matière de RTO et de RPO.
Un troisième chiffre entre en ligne de compte dans votre stratégie RTO/RPO : la période maximale tolérable de perturbation (MTPD). Cela représente la durée pendant laquelle votre client est capable de gérer une panne de système en situation de crise, et varie pour chaque application et service que vous gérez. Les facteurs qui entrent en ligne de compte sont les coûts tangibles tels que les salaires des employés, les ventes perdues, l’affaiblissement du cours des actions et les frais de recouvrement, ainsi que les coûts intangibles tels que le risque de réputation. Il est important de discuter du DMPT avec votre client, puis d’appliquer ce chiffre à votre stratégie de réduction des RTO/RPO.
Par exemple, pour une application donnée, la période maximale de tolérance de votre client peut être de deux heures. Cela signifie que votre objectif de temps de récupération doit être égal à moins de deux heures, et que vos données doivent être sauvegardées moins d’une fois toutes les deux heures pour respecter le RPO idéal. Cela vous donne la ligne directrice dont vous avez besoin pour créer un système physique et virtuel qui répond aux besoins de votre client en cas de catastrophe.
Si votre client ne sait pas exactement quelle est sa période maximale de perturbation tolérable, il existe quelques questions clés qui peuvent l’aider à définir de meilleures attentes. Posez ces questions pour comprendre le RTO et le RPO d’un client à un niveau plus granulaire.
- Combien de fois ce type de données change-t-il ?
- Que coûte chaque minute d’interruption de ce service, soit en perte de revenus, soit en perte de productivité ?
- Pourriez-vous effectuer des transactions avec un crayon et du papier, si nécessaire, pendant que ce service est en panne ?
- Si vous subissez un temps d’arrêt, quel en est l’impact sur vos clients ?
Passer en revue ces questions avec votre client peut vous aider à travailler à rebours sur ce que vous devez sauvegarder et comment ces données doivent être sauvegardées pour minimiser les risques dans un scénario de catastrophe.
Qu’est-ce que le RTO et le RPO dans SQL Server ?
SQL Server est un système de gestion de base de données relationnelle spécifique à Microsoft qui stocke et récupère des données à la demande d’autres applications. Le serveur permet aux utilisateurs de configurer des sauvegardes automatisées de journaux à restaurer à partir d’un serveur de secours. Grâce à cette expédition de journaux, les utilisateurs peuvent récupérer une copie assez récente de la base de données – en fonction du RTO et du RPO de ce processus. Ces exigences de RTO et de RPO sont fixées par les utilisateurs, en fonction de leurs besoins, de leur budget et des éventuelles limitations technologiques du réseau.
Cependant, le RTO et le RPO de SQL Server ne sont pas nécessairement simples. Dans de nombreux cas, le processus n’est pas aussi rapide qu’un client peut l’imaginer. Ils peuvent avoir un RPO idéal en tête, mais des vitesses de réseau lentes ou une sauvegarde mal configurée peuvent étrangler ce processus. En outre, la restauration d’une sauvegarde de journal de cette manière peut impliquer le transfert de grandes quantités de données, et ce processus peut facilement dépasser le RTO acceptable déterminé.