Conceptos clave: RTO, RPO y la diferencia entre DR y HA

RTO (Recovery Time Objective) es el tiempo máximo de inactividad que el negocio puede tolerar desde que ocurre un desastre hasta que el sistema está operativo nuevamente. Si el negocio dice "no podemos estar más de 2 horas caídos", el RTO es 2 horas.

RPO (Recovery Point Objective) es la cantidad máxima de datos que el negocio puede perder. Si el RPO es 1 hora, el sistema debe poder recuperar datos hasta hace menos de 1 hora antes del desastre.

La diferencia entre RTO y RPO define la tecnología necesaria: un RTO de 30 minutos y RPO de 5 minutos exige una réplica activa en tiempo real, no backups diarios.

HA vs DR: Alta Disponibilidad maneja fallos de nodos individuales dentro del mismo datacenter (segundos de interrupción, automático). Disaster Recovery maneja la pérdida completa de un datacenter o región (minutos u horas, generalmente manual). Son complementarios y deben planificarse juntos.

Señales de que el DR no está listo

  • No existe un runbook escrito con pasos numerados que el equipo pueda ejecutar sin improvizar
  • El RTO y RPO nunca han sido definidos ni aprobados formalmente por el negocio
  • El backup de producción está en el mismo servidor o datacenter que la base de datos
  • Nadie ha probado que la restauración del backup funciona en el entorno de DR
  • Solo una persona conoce el procedimiento de failover
  • Los secretos (contraseñas, claves) necesarios para ejecutar el DR están almacenados solo en el servidor primario

Riesgos para el negocio

  • Un desastre real con un DR sin probar puede resultar en semanas de recuperación en vez de horas
  • La pérdida de datos puede superar el RPO aprobado si los backups no se actualizan con la frecuencia correcta
  • Empresas reguladas (sector financiero, salud) pueden enfrentar sanciones si no pueden demostrar capacidad de recuperación
  • La dependencia en una sola persona es un riesgo operacional que puede colapsar el DR si esa persona no está disponible

Componentes de un plan de DR para bases de datos

  • 1. RTO y RPO definidos y aprobados por el negocio Sin estos números firmados por un responsable del negocio, el equipo técnico no puede diseñar la arquitectura correcta. Cada base de datos crítica debe tener su propio RTO y RPO.
  • 2. Estrategia de backup alineada con el RPO Si el RPO es 1 hora, los backups deben ser frecuentes (logs de transacciones cada 15 minutos, backup completo diario). Si el RPO es 24 horas, un backup diario puede ser suficiente.
  • 3. Réplica de DR en zona/región diferente al primario Un backup en el mismo datacenter que el servidor no es DR; es un backup local. El entorno de DR debe estar en una ubicación física diferente que pueda sobrevivir al mismo desastre que afectó al primario.
  • 4. Runbook de DR con pasos numerados y verificables El runbook debe poder ejecutarse por alguien que no diseñó el sistema. Incluir: acceso al entorno de DR, verificación de que los backups/réplica están disponibles, pasos de failover, validación post-failover, y criterios de éxito.
  • 5. Secretos y credenciales disponibles fuera del sitio primario Las contraseñas de las bases de datos de DR, las claves de cifrado de backups y los tokens de API necesarios para el failover deben estar en un gestor de secretos accesible sin depender del sitio primario (ej. Vault con backend en nube, o un archivo cifrado en un segundo sitio).
  • 6. Monitoreo de lag de replicación en el DR El lag de la réplica DR debe monitorearse continuamente. Un lag que supera el RPO implica que no podrías cumplir el objetivo si ocurre un desastre en ese momento.
  • 7. Automatización de la verificación de backups Verificar diariamente que el último backup está completo, su tamaño es razonable y puede al menos listarse o restaurarse en un entorno de prueba.
  • 8. Proceso de failover de DNS o balanceadores documentado Si las aplicaciones conectan por nombre de host o por un VIP, el proceso para redirigir ese nombre o IP al servidor de DR debe estar documentado y probado.
  • 9. Criterios de activación del DR definidos ¿Quién decide activar el DR? ¿Cuánto tiempo de downtime es necesario para escalar a DR? ¿Cuál es el proceso de aprobación? Tener estas decisiones tomadas de antemano evita perder tiempo durante la emergencia.
  • 10. Drill documentado y ejecutado al menos una vez al año Un drill real implica: cortar el acceso al primario, ejecutar el failover según el runbook, medir el tiempo real, validar que las aplicaciones funcionan en DR, y documentar los hallazgos.

Validación post-failover: qué verificar antes de declarar que el DR está operativo

  • La base de datos en DR responde a consultas de las aplicaciones críticas
  • Las transacciones recientes están presentes y los conteos de registros son razonables
  • Los jobs de base de datos (ETL, reportes, backups) están activos en el nuevo entorno
  • Las integraciones externas (APIs, conectores) están apuntando al nuevo endpoint
  • El monitoreo está configurado para el nuevo primario (DR) — no sigue apuntando al servidor fallido
  • Se inició el proceso de recuperación del sitio primario para preparar el failback

Cuándo escalar a un DBA especialista

  • El plan de DR nunca ha sido probado y hay un desastre real en curso
  • El lag de la réplica DR supera el RPO antes de que ocurra el desastre
  • El runbook contiene pasos que el equipo no puede ejecutar sin el autor original
  • La empresa no tiene definidos RTO y RPO y necesita diseñar la estrategia de DR desde cero
  • Un drill revela que el tiempo real de recuperación supera significativamente el RTO aprobado

Preguntas frecuentes

¿Cuál es la diferencia entre HA y DR?

HA (Alta Disponibilidad) previene downtime por fallos de nodos individuales dentro del mismo datacenter. Un failover automático (Patroni, Always On, Data Guard) ocurre en segundos y es transparente para la aplicación. DR (Disaster Recovery) maneja la pérdida completa de un datacenter o región. La recuperación puede tomar minutos u horas y generalmente requiere intervención manual. Son complementarios: puedes tener HA dentro de un datacenter y DR hacia otro datacenter, y necesitas ambos para una arquitectura robusta.

¿Cada cuánto se debe hacer un drill de DR?

Como mínimo una vez al año para sistemas críticos; idealmente cada trimestre para sistemas de alta criticidad. Un drill debe reproducir condiciones reales: cortar el acceso al primario, ejecutar el runbook completo, medir el RTO y RPO reales obtenidos, y documentar los hallazgos. Un plan que solo existe en un documento nunca probado no es un plan de DR confiable.

¿Un backup en la nube es suficiente como DR?

Depende del RTO y RPO del negocio. Si el RTO es 4 horas y el RPO es 24 horas, backups diarios en S3 o Azure Blob pueden ser suficientes si puedes restaurar en una instancia cloud en ese tiempo. Si el RTO es 15 minutos y el RPO es 1 hora, necesitas una réplica activa sincronizada en tiempo real hacia la nube, no solo backups. La decisión debe basarse en cuánto cuesta el downtime al negocio vs cuánto cuesta el DR.

¿Qué información crítica debe estar disponible fuera del sitio primario?

El runbook de DR con pasos detallados, las credenciales de acceso al entorno de DR (contraseñas de bases de datos, claves de cifrado de backups, tokens de API), la lista de contactos de escalada del equipo con teléfonos directos, la documentación de la arquitectura del entorno de DR, y los scripts de validación post-failover. Si cualquiera de estas piezas está solo en el servidor que falló, el DR se vuelve mucho más lento y riesgoso.

Recursos relacionados