Una base de datos crítica necesita algo más que backups. Alta disponibilidad y recuperación ante desastres (Disaster Recovery) responden a problemas diferentes y deben diseñarse según cuánto tiempo y cuánta información puede permitirse perder el negocio.
Alta disponibilidad y recuperación no son lo mismo
Las expresiones alta disponibilidad y Disaster Recovery suelen utilizarse como si fueran equivalentes, pero resuelven escenarios diferentes.
La alta disponibilidad busca que el servicio continúe funcionando o se recupere rápidamente ante fallas de componentes, instancias, nodos o servidores. Su foco está en reducir el tiempo de interrupción dentro de la operación habitual.
Disaster Recovery, en cambio, contempla eventos de mayor alcance: pérdida total de infraestructura, fallas de un centro de datos, incidentes de seguridad, errores graves de configuración o situaciones que obligan a reconstruir la operación en otro entorno.
Una empresa puede tener una solución de alta disponibilidad y, aun así, no estar preparada para un desastre. También puede contar con backups externos, pero tardar demasiadas horas o días en restablecer sus servicios.
La arquitectura debe responder a las necesidades reales del negocio, no únicamente a las herramientas disponibles.
¿Cuánto tiempo puede estar detenida la operación?
Antes de definir tecnología, es necesario responder dos preguntas.
La primera es cuánto tiempo puede permanecer indisponible un proceso. La segunda es cuánta información puede perderse sin producir un daño inaceptable.
Estas preguntas se traducen habitualmente en dos objetivos:
- RTO: tiempo máximo esperado para restablecer el servicio.
- RPO: cantidad máxima de información que podría perderse, expresada como un período de tiempo.
Una operación que puede permanecer detenida durante varias horas no necesita la misma arquitectura que un sistema transaccional que debe recuperarse en pocos minutos. Del mismo modo, una base actualizada una vez por día tiene requerimientos diferentes de otra que recibe operaciones permanentemente.
Sin estas definiciones, la empresa puede sobredimensionar su infraestructura o, por el contrario, invertir en una solución que no alcanza para sostener sus procesos críticos.
Los componentes de una estrategia robusta
Una estrategia de continuidad no depende de una única tecnología. Debe combinar arquitectura, respaldos, replicación, monitoreo, documentación y capacidad operativa.
Redundancia
La redundancia reduce la dependencia de un único componente. Puede aplicarse a servidores, almacenamiento, redes, instancias y ubicaciones. Sin embargo, duplicar infraestructura no garantiza continuidad si ambas copias comparten el mismo punto de falla.
Backups
Los backups siguen siendo indispensables, incluso cuando existe alta disponibilidad. Una réplica puede reproducir errores, eliminaciones accidentales o corrupción lógica. El respaldo permite regresar a un estado anterior.
La estrategia debe definir frecuencia, retención, cifrado, ubicación y pruebas de restauración.
Replicación y conmutación
Según la edición, la arquitectura y los objetivos del negocio, pueden utilizarse diferentes mecanismos de replicación o disponibilidad. La decisión debe considerar latencia, complejidad, costos, automatización y procedimiento de conmutación.
Monitoreo y alertas
Una plataforma redundante que nadie supervisa puede permanecer degradada durante semanas. El monitoreo debe informar el estado de sincronización, retrasos, fallas de jobs, crecimiento de logs y pérdida de conectividad.
Procedimientos documentados
Durante una contingencia no debería improvisarse. La organización necesita conocer responsables, orden de acciones, criterios para activar el plan y pasos para regresar al entorno principal.
Errores frecuentes en los planes de continuidad
Un error habitual es asumir que tener backups equivale a contar con Disaster Recovery. Los respaldos son una parte de la estrategia, pero no resuelven por sí solos infraestructura, conectividad, dependencias, accesos ni tiempos de recuperación.
También es frecuente implementar una réplica y nunca probar una conmutación. En ese caso, la empresa descubre durante el incidente que existen usuarios faltantes, jobs no replicados, conexiones incorrectas o aplicaciones que no pueden acceder al servidor alternativo.
Otros errores comunes son:
- almacenar los backups en la misma infraestructura;
- no documentar dependencias de aplicaciones;
- olvidar credenciales, certificados o claves;
- no considerar procesos ETL y reportes;
- diseñar sin definir RTO y RPO;
- no capacitar a quienes deben ejecutar el plan;
- no revisar la estrategia después de cambios tecnológicos.
En resumen
Una estrategia de continuidad para SQL Server debería incluir:
- clasificación de procesos críticos;
- definición de RTO y RPO;
- arquitectura de alta disponibilidad;
- backups externos y verificables;
- infraestructura alternativa;
- monitoreo y alertas;
- procedimientos de conmutación;
- inventario de dependencias;
- responsables definidos;
- simulacros periódicos.
Aplicación en distintos sectores
En salud, la indisponibilidad puede afectar turnos, atención, facturación o acceso a información operativa. En entidades financieras, puede interrumpir transacciones y controles. En seguros, puede afectar pólizas, siniestros y canales de atención. En retail, puede comprometer ventas, stock, precios o logística.
La criticidad no depende solamente del tamaño de la empresa. Una organización mediana puede tener una base central que concentra casi toda su operación. Si esa plataforma se detiene, el impacto puede ser total.
Cómo puede ayudar BigTelligent
En BigTelligent diseñamos y revisamos estrategias de alta disponibilidad y Disaster Recovery para plataformas SQL Server en entornos locales, cloud e híbridos.
El trabajo comienza con el relevamiento de procesos, criticidad, dependencias y objetivos de recuperación. A partir de allí, se define una arquitectura acorde con el nivel de riesgo y con la capacidad real de la organización para administrarla.
También acompañamos la configuración, documentación, monitoreo y realización de pruebas. Una solución de continuidad no está completa hasta que la empresa puede demostrar que sabe activarla y recuperar la operación.
Preguntas frecuentes
¿Tener backups alcanza para garantizar continuidad?
No. Los backups permiten recuperar información, pero no garantizan que existan infraestructura, accesos y procedimientos para restablecer rápidamente el servicio.
¿Alta disponibilidad evita todas las caídas?
No. Reduce el impacto de determinadas fallas, pero no reemplaza una estrategia integral de recuperación.
¿Es necesario probar el plan?
Sí. Las pruebas permiten detectar dependencias, errores de documentación y configuraciones faltantes antes de una contingencia real.
¿Una empresa mediana necesita Disaster Recovery?
Depende de la criticidad de sus procesos, no solo de su tamaño. Si una base sostiene la operación principal, necesita una estrategia de recuperación proporcional al impacto de una interrupción.
Documentación oficial de Microsoft sobre Always On Availability Groups: https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server
También te podría interesar: SQL Server Health Check: qué revisar antes de que una falla afecte al negocio
