Le RTO décrit le délai pour remettre un service en fonctionnement. Le RPO décrit la perte de données acceptable. Ces objectifs relient continuité d’activité, sauvegardes et budget cloud.
Relier les objectifs à l’activité
Pour chaque parcours, indiquez la durée maximale d’interruption et le volume de données que l’entreprise peut recréer. Une même application peut avoir un objectif différent pour la consultation, la commande et les rapports.
Ne fixez pas un RTO sans mesurer les étapes : accéder au compte cloud, reconstruire l’infrastructure, restaurer la base, reconfigurer les secrets, vérifier les données et rouvrir le trafic. Le temps de décision doit aussi apparaître dans le scénario.
Choisir une stratégie
Une sauvegarde périodique peut répondre à un RPO de plusieurs heures. Une réplication continue réduit le délai de perte, mais elle ne protège pas toujours d’une suppression propagée. Une seconde région, une capacité chaude ou un service managé ajoute des coûts et des procédures.
Comparez les scénarios avec le volume de données, les dépendances et les compétences disponibles. La solution la plus complexe n’est pas automatiquement la plus facile à exploiter pendant une panne.
Tester la reprise
Restaurez une sauvegarde dans un environnement isolé, puis exécutez les parcours métier. Mesurez le temps et vérifiez les relations, permissions, fichiers et événements. Un test de restauration doit également confirmer que les personnes habilitées peuvent accéder aux comptes nécessaires.
Répétez le test après un changement de schéma, de fournisseur ou de procédure. Le runbook de reprise après panne doit contenir les décisions et commandes exactes.
Surveiller les écarts
Calculez l’âge de la dernière sauvegarde, le retard de réplication et le temps du dernier test. Une alerte doit indiquer le service, l’objectif concerné et l’action à lancer. Les tableaux de bord doivent séparer une sauvegarde réussie d’une restauration validée.
Documenter les limites
Notez les dépendances externes, les opérations manuelles et les données impossibles à restaurer. Définissez une réponse dégradée lorsque le RTO complet n’est pas atteint. Après chaque exercice, transformez les blocages en actions avec un responsable.
Sources : NIST, contingency planning, AWS Well-Architected, disaster recovery.