Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Définition de votre stratégie de reprise après sinistre
Selon le degré d'importance des applications de votre organisation pour votre activité, vous pouvez choisir une stratégie uniforme pour toutes les applications ou développer une stratégie de reprise après sinistre plus complexe en fonction de la criticité de chaque application. Votre entreprise peut tolérer un temps d'arrêt de plusieurs heures avant que toutes les applications ne soient affichées sur le site de reprise après sinistre. Dans ce cas, vous pouvez opter pour une stratégie de reprise après sinistre rentable basée sur la sauvegarde et la restauration de toutes les bases de données. D'un autre côté, les activités de votre organisation peuvent dépendre de la disponibilité rapide de certains services ou applications critiques, avec des exigences de RPO et de RTO plus strictes, tandis que d'autres applications peuvent tolérer des exigences de RPO et de RTO moins strictes. Dans ce cas, vous devez affecter la bonne stratégie de reprise après sinistre pour chaque niveau d'applications et de bases de données.
Le tableau suivant décrit quatre options de reprise après sinistre pour les charges de travail exécutées dans le AWS Cloud, pour vous aider à déterminer et à définir la stratégie de reprise après sinistre de votre entreprise. Le RPO et le RTO documentés dans ce tableau concernent une pile complète qui inclut à la fois des composants d'application et de base de données. Pour plus d'informations, veuillez consulter Options de reprise après sinistre dans le cloud dans la documentation du cadre AWS Well-Architected. La section suivante traite des options RPO et RTO propres aux bases de données.
Option de récupération | RPO | RTO | Tâches d'infrastructure dans la région DR | Coût |
---|---|---|---|---|
Sauvegarde et restauration | Heures | Moins de 24 heures | Allouez toutes les ressources d'application requises dans la région DR et restaurez la base de données à partir d'un instantané copié. |
Faible |
Veilleuse | Dizaines de minutes | Dizaines de minutes | Allouez une copie de votre infrastructure d'applications et désactivez les ressources de la pile d'applications. Répliquez vos données d'une région à l'autre. Maintenez les bases de données toujours actives et synchronisées avec les bases de données principales. Allouez les ressources à la demande lors du basculement et de l'événement de test. Vous devez également déployer simultanément les modifications d'infrastructure et les modifications d'application dans les deux régions. Vous pouvez simplifier cette opération en générant des pipelines d'automatisation capables de synchroniser le code et l'infrastructure dans les régions principales et DR. |
Medium |
Secours semi-automatique | Minutes | Minutes | Allouez une copie de l'ensemble de l'infrastructure d'applications dans la région DR, mais réduisez la copie par rapport à la région principale. La région DR sera en mesure d'accepter du trafic à un volume inférieur à celui de la région principale. |
Élevée |
Multisite ou actif/actif | Proche de zéro | Zéro ou proche de zéro | Allouez une copie complète de votre infrastructure dans la région DR. Toutes les ressources de la région DR seront équivalentes aux ressources de la région principale et seront en mesure de desservir le trafic à la même échelle que la région principale. En l'absence d'interruption du trafic, cette option ne nécessite pas de tâche de basculement dans le cadre de votre plan de reprise après sinistre. |
Supérieur |