Sauvegarde, restauration et reprise après sinistre
Tolérance aux pannes Multi-AZ, AWS Backup et snapshots, restauration à un instant donné, versioning du stockage et les quatre stratégies de reprise.
Une charge de travail s'éteint de deux façons. Soit quelque chose casse, soit quelque chose est faux. Multi-AZ, les health checks et Auto Scaling traitent le premier cas et ne servent à rien contre le second, parce qu'ils recopient fidèlement un mauvais DELETE vers chaque copie en quelques millisecondes. Ce sujet couvre la seconde moitié : garder des copies des données d'avant l'erreur, les restaurer sous pression, et décider à l'avance combien d'interruption et combien de perte de données l'entreprise accepte de payer pour les éviter.
Ce que couvre ce sujet
- Ce qu'est physiquement une zone de disponibilité, et la classification zonale, régionale et globale qui prédit exactement ce qu'une panne de zone emporte
- Dimensionner un étage de calcul pour la perte d'une zone, la stabilité statique, et les dépendances mono-zone (NAT gateways, EFS One Zone, load balancers sur un seul subnet) qui défont discrètement une conception multi-zones
- Multi-AZ DB instance face à Multi-AZ DB cluster face à Aurora : méthode de réplication, lecture possible ou non sur le standby, et temps de failover
- Comment un snapshot EBS stocke de façon incrémentale tout en restaurant intégralement, et pourquoi en supprimer un libère moins que prévu
- Crash-consistent face à application-consistent, et le moment où la différence compte
- Choisir entre Amazon Data Lifecycle Manager et AWS Backup, et bâtir des plans avec lifecycle, copie inter-Régions et copie inter-comptes
- Vault Lock en mode governance face au mode compliance, et le restore testing qui mesure un RTO au lieu de le supposer
- La mécanique de la restauration point-in-time RDS, l'intervalle de 5 minutes des logs de transactions, sauvegardes automatiques face à snapshots manuels, et les réglages que chaque restauration laisse tomber
- Le cloning et Backtrack sur Aurora, le PITR DynamoDB, et la checklist post-restauration qu'exige une récupération DynamoDB
- Les états du versioning S3, delete markers face aux suppressions versionnées, Object Lock, et ce que la réplication refuse de copier
- Le RTO et le RPO comme définitions et comme décisions, les quatre stratégies de reprise, et la règle du data plane qui décide de la façon de basculer
Pourquoi c'est important
La compétence 2.2 du SOA-C03 est l'endroit où l'examen cesse de demander ce que fait une fonctionnalité et commence à demander ce qu'elle vous coûte. Un énoncé vous donne un RPO de 15 minutes et un budget qui exclut une seconde flotte en marche, avec quatre options qui fonctionnent toutes techniquement. Choisir juste demande de savoir que la réplication achète du RPO, que l'infrastructure pré-provisionnée achète du RTO, et que seules les sauvegardes protègent contre des données fausses plutôt que manquantes.
Le même raisonnement sépare une récupération qui tient dans le RTO d'une récupération qui découvre en plein incident que la restauration a construit un nouvel endpoint que personne n'avait prévu de basculer.