El examen DP-300 se centra en elegir la opción correcta para cada escenario de alta disponibilidad y recuperación ante desastres. Azure SQL Database y SQL Managed Instance ofrecen mecanismos de copia de seguridad, replicación y conmutación por error que abordan problemas distintos: las copias de seguridad gestionan la corrupción lógica, la replicación aborda los desastres físicos y la conmutación por error automática garantiza la continuidad del servicio.
PITR — Una máquina del tiempo para deshacer errores
Imagina que un desarrollador ejecuta una instrucción UPDATE incorrecta durante el fin de semana y sobreescribe miles de registros críticos. No hay script de reversión y lo único que se conoce es la marca de tiempo exacta del error. Azure SQL Database ofrece Point-in-Time Restore (PITR) precisamente para este tipo de corrupción lógica de datos.
PITR combina tres tipos de copias de seguridad automatizadas: copias completas semanales, diferenciales cada 12 horas y de registro de transacciones cada 5 a 10 minutos. Juntas permiten restaurar a cualquier minuto dentro del período de retención con precisión de minutos. El período predeterminado es de 7 días, configurable hasta 35 días, y la plataforma gestiona todo automáticamente.
La restauración siempre crea una nueva base de datos — la original nunca se sobreescribe. Tras completarla, el administrador valida los datos y redirige manualmente las conexiones. Este paso forma parte del tiempo de recuperación y debe tenerse en cuenta en la planificación del RTO.
LTR — Una bóveda para registros de una década
Una autoridad fiscal exige siete años de historial de transacciones. Una normativa sanitaria obliga a conservar datos de pacientes durante diez años. La retención máxima de 35 días de PITR no puede cumplir estos requisitos. Long-Term Retention (LTR) fue diseñado específicamente para este tipo de cumplimiento normativo.
LTR almacena copias de seguridad completas en Azure Blob Storage durante un máximo de 10 años. Las políticas de retención semanal, mensual y anual pueden configurarse de forma independiente — por ejemplo, copias semanales durante 12 semanas, mensuales durante 36 meses y anuales durante 5 años de manera simultánea.
LTR y PITR tienen propósitos distintos. PITR es para recuperación precisa en un punto del tiempo tras una consulta incorrecta. LTR es para archivado a largo plazo — conservar una instantánea del 1 de enero del año pasado para una auditoría anual. Ambas pueden estar activas en la misma base de datos simultáneamente.
!PITR vs LTR
Active Geo-Replication — Un gemelo en guardia al otro lado del país
Cuando un centro logístico queda fuera de servicio por una tormenta, tener un centro de respaldo equivalente en otra ciudad significa que las entregas pueden continuar con una interrupción mínima. Active Geo-Replication proporciona exactamente esta estructura para Azure SQL Database.
Active Geo-Replication crea hasta cuatro réplicas secundarias legibles en distintas regiones para una sola base de datos. La replicación es asíncrona y las réplicas secundarias pueden utilizarse para cargas de trabajo de solo lectura, como informes y consultas analíticas, reduciendo la presión sobre la primaria.
Cuando se produce un error, una conmutación por error manual promueve una réplica secundaria al rol principal. Esta es la distinción clave con Auto-Failover Group: no hay conmutación automática, alguien debe iniciarla. Active Geo-Replication tampoco está disponible para SQL Managed Instance.
Auto-Failover Group — Un sistema de rociadores automáticos para su base de datos
Cuando suena la alarma de incendio, ¿alguien debería correr a buscar un extintor o los rociadores deberían activarse automáticamente? Auto-Failover Group es el sistema de rociadores para los fallos de base de datos — actúa sin intervención humana.
Auto-Failover Group admite la conmutación por error automática para un grupo de bases de datos o SQL Managed Instances. Cuando falla la región principal, el sistema cambia automáticamente a la región secundaria según una política configurada. Las aplicaciones se conectan mediante un punto de conexión de escucha, por lo que no se necesitan cambios en la cadena de conexión.
A diferencia de Active Geo-Replication, Auto-Failover Group admite tanto SQL Database como SQL Managed Instance, y gestiona varias bases de datos como un único grupo para garantizar la consistencia en el failover.
Geo-Replication vs Auto-Failover Group — Cómo elegir
| Característica | Active Geo-Replication | Auto-Failover Group | |:--|:--|:--| | Alcance | Base de datos individual | Grupo de bases de datos o MI | | Productos compatibles | Solo SQL Database | SQL Database + SQL MI | | Tipo de conmutación | Manual | Automática (basada en política) | | Secundarias legibles | Hasta 4 | Sí (escucha de solo lectura) | | Punto de conexión de escucha | No | Sí | | Gestión multibases de datos | No | Sí |
Elige Active Geo-Replication cuando necesites una sola base de datos con réplicas secundarias legibles y control manual del momento de la conmutación. Elige Auto-Failover Group cuando varias bases de datos deban conmutar por error como una unidad, se requiera conmutación automática y el endpoint de escucha deba permanecer estable tras el cambio.
Always On AG y FCI — HA para entornos IaaS (SQL en VM)
Cuando SQL Server se ejecuta en máquinas virtuales de Azure en lugar de un servicio PaaS, la alta disponibilidad se configura de manera diferente. Always On Availability Groups (AG) y Failover Cluster Instance (FCI) son las opciones principales en este entorno IaaS.
Always On AG admite configuraciones multinodo con replicación síncrona o asíncrona. Un escucha siempre enruta a los clientes hacia el nodo principal. En caso de fallo, otro nodo asume el rol automática o manualmente. La replicación síncrona acerca el RPO a cero, pero añade latencia de escritura porque las secundarias deben confirmar cada operación.
FCI proporciona disponibilidad a nivel de instancia mediante almacenamiento compartido. Si un nodo falla, otro retoma la misma instancia de SQL Server. Para SQL Managed Instance, la disponibilidad integrada se asemeja al modelo FCI y la gestiona la plataforma automáticamente.
Trampas frecuentes en el examen — Conceptos similares pero diferentes
La mayor fuente de confusión es tratar PITR y Geo-Replication como si resolvieran el mismo problema. PITR deshace la corrupción lógica — un UPDATE incorrecto que sobrescribió datos importantes. Geo-Replication mantiene una copia activa en otra región para la recuperación ante desastres físicos. Confundirlos en una pregunta del examen casi siempre lleva a una respuesta incorrecta.
Active Geo-Replication no admite SQL Managed Instance. Cuando una pregunta combine SQL MI con réplicas secundarias legibles o replicación entre regiones, la respuesta es Auto-Failover Group.
Geo-restore no es lo mismo que Geo-replication. Geo-restore recupera desde una copia de seguridad con redundancia geográfica y puede tener un RPO de varias horas — no es una solución de HA en tiempo real. Si el escenario requiere pérdida mínima de datos con replicación continua, Active Geo-Replication o Auto-Failover Group es la respuesta correcta.
Resumen para el Examen
"Corrupción lógica, recuperación de consulta incorrecta" -- PITR (Point-in-Time Restore) "Retención regulatoria de 7 o 10 años" -- LTR (Long-Term Retention) "Período de retención predeterminado de PITR" -- 7 días (hasta 35 días) "Período máximo de retención de LTR" -- 10 años "Base de datos única, secundarias legibles, conmutación manual" -- Active Geo-Replication "Grupo de bases de datos, conmutación automática, punto de escucha" -- Auto-Failover Group "SQL MI + replicación entre regiones" -- Auto-Failover Group (Geo-Replication no disponible en MI) "IaaS SQL en VM, replicación síncrona/asíncrona, multinodo" -- Always On Availability Groups "IaaS SQL en VM, HA a nivel de instancia, almacenamiento compartido" -- Failover Cluster Instance "Sin cambio en cadena de conexión tras la conmutación" -- Punto de escucha de Auto-Failover Group "Fallo de toda la región principal, restaurar desde copia de seguridad" -- Copia de seguridad con redundancia geográfica + Geo-restore
PITR = recuperación a corto plazo de corrupción lógica, LTR = archivado a largo plazo para cumplimiento normativo, Active Geo-Replication = conmutación manual de base de datos individual, Auto-Failover Group = conmutación automática de grupo