Cuando ocurre una contingencia, la operación no se detiene para darle tiempo al equipo de TI de diseñar un plan. Servidores pueden dejar de responder, una aplicación puede quedar inaccesible, una base de datos puede corromperse o una falla de red puede afectar procesos completos.
El problema es que muchas organizaciones creen estar preparadas porque tienen respaldos, documentación y algún procedimiento de recuperación guardado.
Pero tener un backup no significa necesariamente poder recuperar la operación.
Un verdadero plan de Disaster Recovery debe responder algo mucho más importante: ¿qué necesitamos recuperar, en qué orden, cuánto tiempo tenemos para hacerlo y quién sabe cómo hacerlo?
Por eso, el verdadero valor de un Disaster Recovery Plan no está en el documento. Está en haberlo probado antes de necesitarlo.
Uno de los errores más comunes al hablar de recuperación ante desastres es asumir que un respaldo equivale a tener la operación protegida.
No necesariamente.
Un backup permite conservar una copia de determinados datos. La recuperación implica utilizar esos datos, infraestructura, aplicaciones y configuraciones para volver a poner en funcionamiento un servicio.
Y la continuidad operativa va todavía más allá: busca que el negocio pueda mantener sus procesos críticos durante una interrupción o recuperarlos dentro de los tiempos que necesita.
En otras palabras:
Backup → protege los datos.
Recovery → recupera los servicios.
Continuidad → mantiene funcionando el negocio.
Una empresa puede tener múltiples copias de seguridad y, aun así, descubrir durante una contingencia que una aplicación depende de una base de datos que no está contemplada, que una credencial no está disponible o que el procedimiento de recuperación nunca fue probado.
Ahí es donde aparece la verdadera brecha.
RTO y RPO suelen explicarse como conceptos técnicos, pero para el negocio representan algo mucho más sencillo:
¿Cuánto podemos perder y cuánto tiempo podemos estar detenidos?
El Recovery Point Objective determina hasta qué momento anterior a una interrupción necesitamos poder recuperar la información.
Por ejemplo, si un proceso puede tolerar perder hasta una hora de información, su RPO será diferente al de una operación que necesita recuperar prácticamente los últimos minutos de actividad.
La velocidad nunca debería estar separada del control.
Automatizar más rápido no significa necesariamente operar mejor.
La madurez aparece cuando una organización puede automatizar manteniendo visibilidad sobre quién ejecuta una acción, qué acción se realiza y sobre qué infraestructura.
El Recovery Time Objective establece cuánto tiempo puede pasar antes de recuperar un servicio.
Pero aquí la pregunta importante no es solamente técnica.
Es de negocio:
¿Cuánto cuesta que este proceso esté detenido durante una hora, cuatro horas o un día?
No todos los sistemas tienen la misma prioridad. Una plataforma que soporta una operación crítica puede necesitar recuperarse mucho antes que un sistema secundario.
Por eso, definir RTO y RPO debería comenzar entendiendo qué procesos son críticos para la organización, no solamente qué servidores existen.
Una operación tecnológica rara vez depende de un único sistema.
Detrás de una aplicación pueden existir múltiples componentes conectados:
Aplicaciones
Sistemas empresariales, aplicaciones internas, plataformas de atención o herramientas utilizadas por los usuarios.
Bases de datos
Información que las aplicaciones necesitan para funcionar correctamente.
Redes
Conectividad, segmentación, DNS, balanceadores, VPN y otros componentes necesarios para acceder a los servicios.
Identidad
Directorio activo, servicios de autenticación, permisos y credenciales.
Integraciones
APIs, servicios externos, plataformas de terceros y conexiones entre sistemas.
Servidores físicos o virtuales, almacenamiento, nube, hipervisores y configuraciones.
El reto aparece cuando una de estas dependencias queda fuera del plan.
Puedes recuperar una aplicación, pero si no puedes autenticar usuarios, acceder a la base de datos o restablecer una integración crítica, la operación sigue sin estar disponible.
Por eso, antes de probar un Disaster Recovery, es necesario conocer las dependencias que existen entre los componentes.
Un Disaster Recovery Plan puede estar perfectamente documentado y, aun así, no funcionar cuando más se necesita.
¿Por qué?
Porque existe una diferencia enorme entre tener un procedimiento escrito y haber demostrado que funciona.
Un documento puede indicar:
En papel parece sencillo.
Pero durante una prueba pueden aparecer problemas que nadie había contemplado:
El problema no es que el documento exista.
El problema es que nadie sabe si el documento funciona en la práctica.
Un Disaster Recovery Plan debería someterse a pruebas controladas.
No necesariamente hay que comenzar provocando una interrupción real de la operación. Existen diferentes escenarios de simulación que permiten validar la capacidad de recuperación.
Por ejemplo:
¿Qué ocurre si un servidor crítico deja de estar disponible?
¿Cuánto tarda realmente cada etapa de recuperación?
No cuánto dice el documento que debería tardar.
¿Quién toma decisiones?
¿Quién ejecuta la recuperación?
¿Quién valida que el servicio vuelva a funcionar?
¿Qué sucede si el componente principal no puede recuperarse?
¿Existe una alternativa?
¿Todos los sistemas necesarios están contemplados?
La prueba convierte un documento teórico en un mecanismo que puede ser evaluado, corregido y mejorado.
Y cada prueba debería dejar algo más que la tranquilidad de haberla realizado: debería generar hallazgos.
Disaster Recovery es el conjunto de estrategias, procesos y tecnologías que permiten recuperar sistemas, datos e infraestructura después de una interrupción o desastre, con el objetivo de restablecer los servicios necesarios para la operación.
El backup consiste en crear y conservar copias de información. Disaster Recovery contempla cómo recuperar sistemas, aplicaciones, infraestructura y servicios utilizando esos respaldos y otros mecanismos necesarios para restablecer la operación.
Un Disaster Recovery Plan es un conjunto documentado de procedimientos, responsabilidades y prioridades para recuperar los servicios tecnológicos de una organización ante una interrupción.
pruebas cuando existen cambios importantes en aplicaciones, infraestructura, proveedores o procesos de recuperación.
Una prueba debería contemplar escenarios de falla, sistemas y dependencias involucradas, responsables, procedimientos de recuperación, tiempos, validación de los servicios recuperados y registro de hallazgos para mejorar el plan.
Un Disaster Recovery Plan no debería medirse por la cantidad de páginas que tiene, sino por la capacidad de la organización para utilizarlo cuando una operación crítica deja de funcionar.
Tener respaldos es importante. Documentar procedimientos también. Pero ninguna de las dos cosas demuestra, por sí sola, que una operación pueda recuperarse dentro de los tiempos que necesita el negocio.
Porque el mejor momento para descubrir que una estrategia de recuperación tiene una brecha es durante una prueba controlada, no durante una contingencia real.
