Respaldo, restauración y recuperación ante desastres
Tolerancia a fallos Multi-AZ, AWS Backup y snapshots, restauración a un punto en el tiempo, versionado de almacenamiento y las cuatro estrategias de DR.
Los tres temas anteriores mantienen una carga de trabajo en pie mientras las piezas siguen funcionando. Este tema empieza donde eso ya no alcanza: una zona de disponibilidad completa que se apaga, un DELETE sin WHERE, una región que deja de responder. Son 5 lecciones que recorren la skill 2.2 del SOA-C03, del fallo más chico con nombre propio hasta la decisión de cuánto vale la pena gastar para sobrevivir al más grande.
Arrancan por lo que Multi-AZ sí protege y por lo que deja pasar, siguen por el mecanismo que hay debajo de cada respaldo en AWS, después por las restauraciones específicas de bases de datos y de almacenamiento de objetos, y cierran con las cuatro estrategias de recuperación ante desastres y los dos números que eligen entre ellas.
Qué cubre este tema
- Qué es físicamente una zona de disponibilidad, y la clasificación zonal, regional y global que decide qué se pierde con ella
- La aritmética AZ+1, la estabilidad estática y las dependencias de una sola zona que quedan escondidas en arquitecturas multi-AZ
- Multi-AZ DB instance contra Multi-AZ DB cluster contra Aurora, por replicación, lectura y tiempo de failover
- Cómo los snapshots de EBS guardan bloques de forma incremental y qué libera de verdad borrar uno
- Amazon Data Lifecycle Manager contra AWS Backup, con backup plans, vaults, copias entre regiones y entre cuentas
- Vault Lock en modo governance y compliance, y el restore testing que convierte un RTO declarado en uno medido
- Point-in-time recovery en RDS, backups automatizados contra snapshots manuales, y el corte de endpoint que exige toda restauración
- Cloning y Backtrack de Aurora, PITR de DynamoDB y la lista de configuración que una restauración no arrastra
- Versionado de S3, delete markers, Object Lock, y qué se niega a copiar S3 Replication sin avisar
- RTO y RPO, las cuatro estrategias de DR, la regla del data plane y los patrones write global, write local y write partitioned
Por qué importa
Las preguntas de este tema casi siempre te dan una restricción y te piden el mecanismo: un RPO de 5 minutos, una norma que exige respaldos imposibles de borrar durante 7 años, un incidente donde los datos corruptos ya llegaron a las dos regiones. Responder bien depende de sostener una separación que es fácil de borronear: la disponibilidad protege contra que las cosas se rompan, los respaldos protegen contra que las cosas estén mal, y confundirlas hace elegir la respuesta que suena protectora en vez de la que resuelve.
En una guardia real esa misma distinción decide los primeros minutos. Ante datos que desaparecieron, alguien va a proponer un failover; saber por qué eso no ayuda, y cuál es el punto exacto al que puedes volver, es la diferencia entre recuperar y replicar el problema.