Test de reprise après sinistre
Testez votre procédure de reprise après sinistre pour la valider et testez régulièrement le basculement vers la région de reprise après sinistre de votre charge de travail pour vous assurer que les objectifs RTO et RPO sont bien atteints.
Il convient d'éviter de développer des chemins de récupération rarement exécutés. Par exemple, vous pouvez avoir un magasin de données secondaire qui est utilisé pour les requêtes en lecture seule. Lorsque vous écrivez dans un magasin de données et que l'instance principale connaît une défaillance, vous pouvez basculer vers le magasin de données secondaire. Si vous ne testez pas fréquemment ce basculement, vous constaterez peut-être que vos hypothèses sur les capacités du magasin de données secondaire sont incorrectes. La capacité de l'instance secondaire, qui peut avoir été suffisante lors de votre dernier test, peut ne plus être en mesure de tolérer la charge dans le cadre de ce scénario, ou les quotas de service de la région secondaire peuvent ne pas être suffisants.
Notre expérience nous a montré que seul un chemin de reprise après erreur testé fréquemment fonctionne réellement. C'est pourquoi l'idéal est de n'avoir qu'un petit nombre de chemins de reprise.
Vous pouvez établir des modèles de reprise et tester ceux-ci régulièrement. Si vous avez un chemin de reprise complexe ou critique, vous devez toujours exécuter régulièrement cette panne en production pour vous assurer du bon fonctionnement de ce chemin de reprise.
Gestion de l'écart de configuration au niveau de la région de reprise après sinistre Assurez-vous que votre infrastructure, vos données et votre configuration sont conformes aux besoins de la région de reprise après sinistre. Par exemple, vérifiez que les AMI et les quotas de service sont à jour.
Vous pouvez utiliser AWS Config
