La pregunta no es si una plataforma puede fallar, sino cuánto tiempo puede permanecer indisponible y cuánta información puede perder el negocio antes de que el impacto sea crítico.
Alta Disponibilidad (HA) busca reducir interrupciones ante fallas locales. Disaster Recovery (DR) permite recuperar la operación frente a incidentes mayores. Una estrategia efectiva necesita definir cuánto tiempo puede tolerarse una caída y cuántos datos pueden perderse.
SQL Server puede estar configurado correctamente y aun así quedar expuesto a fallas de infraestructura, errores humanos, problemas de almacenamiento, ransomware o interrupciones completas de un sitio.
Por eso, continuidad operativa no significa simplemente “tener backups”.
RTO y RPO: dos preguntas de negocio
Antes de elegir tecnología hay dos variables fundamentales.
RTO — Recovery Time Objective: cuánto tiempo puede estar detenido un servicio.
RPO — Recovery Point Objective: cuánta información puede perderse.
Una aplicación administrativa podría tolerar varias horas. Una plataforma financiera, sanitaria o transaccional puede requerir tiempos mucho menores.
La arquitectura debería diseñarse a partir de esas necesidades, no al revés.
Alta disponibilidad no es Disaster Recovery
Ambos conceptos suelen confundirse.
La alta disponibilidad busca mantener el servicio operativo ante fallas relativamente localizadas. El Disaster Recovery contempla escenarios más graves: pérdida del servidor, corrupción extensa, incidente de seguridad o indisponibilidad de una infraestructura completa.
Una organización puede tener alta disponibilidad y aun así no estar preparada para un desastre.
¿Qué componentes deberían analizarse?
Una estrategia integral puede contemplar:
- Always On Availability Groups;
- Failover Cluster Instances;
- backups y restores;
- réplicas;
- almacenamiento redundante;
- sitios alternativos;
- monitoreo;
- automatización;
- procedimientos documentados;
- pruebas periódicas de recuperación.
La tecnología concreta dependerá del entorno, presupuesto y criticidad.
En resumen
La continuidad no se valida por configuración sino por capacidad real de recuperación.
Una empresa debería poder responder:
- ¿qué servicios son críticos?;
- ¿cuánto tiempo pueden estar fuera de línea?;
- ¿cuánto dato podemos perder?;
- ¿quién decide un failover?;
- ¿cuándo fue la última prueba?;
- ¿sabemos restaurar todo el entorno?
Si estas respuestas no están claras, existe un riesgo operativo.
Cómo puede ayudar BigTelligent
BigTelligent declara experiencia en Alta Disponibilidad y Disaster Recovery, diseñando arquitecturas de datos robustas tanto on-premises como cloud e híbridas.
El objetivo no debería ser comprar más infraestructura, sino diseñar el nivel correcto de resiliencia para cada proceso.
Preguntas frecuentes
¿Tener backups es suficiente?
No. Un backup es parte del DR, pero deben validarse restauración, tiempos, infraestructura y procedimientos.
¿HA elimina todas las caídas?
No. Reduce determinados escenarios de indisponibilidad, pero no sustituye una estrategia completa.
¿Conviene probar los planes de recuperación?
Sí. Un plan que nunca se prueba es una hipótesis.
