AZ-305

Deep Dive

Volver a guías
D1Identidad, Gobernanza y Monitoreo
0/7
Diseño de Identidad (Entra ID)Autenticacion y AutorizacionGobernanza y Landing ZonesDiseño con Azure PolicyRBAC y Roles PersonalizadosDiseño de MonitoreoKey Vault, Secretos y Claves
D2Almacenamiento de Datos
0/5
Diseño de Datos RelacionalesDiseño de Datos No RelacionalesDiseño de Storage AccountsIntegracion y Analitica de DatosProteccion y Cifrado de Datos
D3Continuidad de Negocio
0/5
Diseño de Alta DisponibilidadDiseño de BackupRecuperacion ante DesastresBCDR de Bases de DatosEstrategia RTO y RPO
D4Infraestructura
0/9
Seleccion de ComputoArquitectura de AplicacionesDiseño de Contenedores y AKSMensajeria y EventosAPIs e IntegracionDiseño de Red (Hub-Spoke)Conectividad Hibrida y DNSSeguridad y Entrega de RedDiseño de Migraciones
Todas las guías
Practicar ahora
D3 · Continuidad de Negocio

BCDR de Bases de Datos

Las bases de datos tienen su propia continuidad: failover groups, geo-replication, PITR y LTR en SQL; réplicas multi-región en Cosmos. El AZ-305 exige distinguir qué mecanismo cumple cada combinación de RTO, RPO y requisito de aplicación.

Contenido

Icon-databases-130

HA integrada de Azure SQL (intra-región)

Lo que ya viene de serie

  • • General Purpose: compute stateless + storage replicado — re-aprovisiona ante fallo (SLA 99.99%)
  • • Business Critical: cluster Always On de 4 nodos (1 primario + 3 réplicas HA), failover en segundos
  • • Zone redundancy: réplicas repartidas en availability zones (BC/GP/Hyperscale) → resiste caída de zona, SLA hasta 99.995%

Diseño

  • • "La DB debe sobrevivir caída de datacenter en la región" → habilitar zone redundancy (NO necesita geo-replication)
  • • La HA intra-región es automática — el arquitecto solo decide tier y zonas
Icon-databases-130

Active Geo-Replication vs Failover Groups

AspectoActive Geo-ReplicationFailover Groups
UnidadBase de datos individualGRUPO de bases de datos (failover conjunto)
RéplicasHasta 4 secundarias legibles, en cualquier región1 secundaria (en otro servidor lógico)
Connection stringCAMBIA al hacer failover (la app debe re-apuntar)NO cambia: listener endpoints (read-write / read-only) redirigen automáticamente
Failover automáticoNo — manual o por tu toolingSí — política de failover automático opcional
Soporte MINo (solo SQL Database)Sí — failover groups es EL mecanismo de Managed Instance
CuándoRead scale-out geo + control fino por DBDR de aplicación completa sin tocar connection strings — la respuesta típica del examen

Regla rápida

"Sin cambiar connection strings" o "failover automático de varias DBs juntas" → failover group. "Réplicas legibles en varias regiones" → active geo-replication. Replicación asíncrona en ambos → RPO segundos (no cero).

Icon-databases-130

PITR y Long-Term Retention

Point-in-Time Restore (PITR)

  • • Backups automáticos del servicio: full semanal + diff + logs (5-10 min)
  • • Restaurar a CUALQUIER instante en 1-35 días (configurable)
  • • Restaura como una DB NUEVA (recuperar la tabla y migrar lo necesario)
  • • Por defecto los backups van a storage geo-redundante → geo-restore en otra región (RPO hasta 1h)

Long-Term Retention (LTR)

  • • Fulls semanales/mensuales/anuales hasta 10 años
  • • Para cumplimiento normativo — no para DR operacional
  • • Señal: "retener backups de la DB 7 años" → LTR (no Azure Backup, no PITR)

Distinción que cae siempre

Geo-restore (desde backup geo-replicado): DR barato, RPO ≤ 1h, RTO de restauración — sin infraestructura previa. Failover group: RPO de segundos, RTO de segundos-minutos — réplica activa pagada. El requisito de RPO/RTO decide.

Icon-databases-121

BCDR en Cosmos DB

Disponibilidad

  • • Réplicas en N regiones con un clic; service-managed failover automático de la región de escritura
  • • Multi-region writes: cada región acepta escrituras — RTO≈0 ante fallo regional
  • • Availability zones dentro de cada región soportada

Recuperación de datos

  • • Continuous backup: point-in-time restore de 7/30 días (self-service)
  • • Periodic backup: el modo clásico, restore vía ticket de soporte
  • • La replicación multi-región NO protege de borrados lógicos (se replican) — el backup sí
Icon-databases-136

MI, PostgreSQL y MySQL

ServicioHADR
SQL Managed InstanceGP/BC igual que SQL DB; zone redundancyFailover groups (con Link feature también DR hacia/desde SQL Server on-prem)
PostgreSQL FlexibleHA zone-redundant: standby SÍNCRONO en otra zona (RPO 0 intra-región)Read replicas (asíncronas) en otra región + promoción manual; geo-backup
MySQL FlexibleHA zonal igual (standby síncrono)Read replicas cross-region + promoción
SQL Server en VMAlways On Availability Groups entre zonasAG asíncrono a otra región, o ASR

Tabla de decisión

RequisitoDiseño
DB sobrevive caída de zona sin geo-réplicaZone redundancy del tier
Failover regional sin cambiar connection stringsFailover group (listener endpoints)
5 DBs de una app hacen failover JUNTASFailover group con las 5
Réplicas legibles en 3 regiones para usuarios globalesActive geo-replication (hasta 4 secundarias)
Recuperar una tabla borrada hace 3 díasPITR (restaurar como DB nueva)
Backups de la DB retenidos 7 años (compliance)Long-Term Retention
DR de SQL al menor costo, RPO 1h y RTO de horas OKGeo-restore desde backup geo-redundante
DR de Managed InstanceFailover group (geo-replication no aplica a MI)
Cosmos sigue escribiendo si cae una regiónMulti-region writes (o service-managed failover)
PostgreSQL con RPO 0 intra-regiónFlexible Server HA zone-redundant (standby síncrono)

¿Entendiste este tema?

Pon a prueba lo que acabas de aprender

Una aplicación usa 4 bases de datos en Azure SQL Database que deben hacer failover a West US como grupo si East US falla, de forma automática y sin que la aplicación cambie sus connection strings. ¿Qué mecanismo diseñas?

Inicia sesión para llevar tu progreso.

AnteriorRecuperacion ante DesastresContinuidad de NegocioSiguienteEstrategia RTO y RPOContinuidad de Negocio