Disaster Recovery
Disaster Recovery no es simplemente tener una copia de seguridad. Es poder levantar la plataforma en otro sitio, con procedimiento y con pruebas.
El problema
La mayoría de las organizaciones que creen tener un plan de recuperación tienen en realidad una copia de seguridad y una intención. La diferencia se descubre el día del incidente.
Tener los datos copiados es condición necesaria y no suficiente. Para volver a trabajar hace falta además infraestructura donde levantarlos, direccionamiento y publicación que funcionen desde el nuevo sitio, certificados, DNS, integraciones con terceros, credenciales accesibles y un orden de arranque que respete las dependencias entre sistemas.
Nada de eso se improvisa bien con el servicio caído y con la dirección preguntando cada quince minutos. Y hay un detalle que agrava todo lo anterior: si el incidente ha sido un cifrado, es probable que las herramientas y la documentación que se necesitan para recuperar estén también dentro del entorno comprometido.
Qué hace IT Encore
Diseñamos y mantenemos planes de recuperación que se pueden ejecutar. El punto de partida siempre es el mismo: qué servicios son críticos, cuánto tiempo puede estar la organización sin ellos (RTO) y cuánta información puede permitirse perder (RPO).
Con esas cifras se decide la arquitectura: qué se replica y con qué frecuencia, dónde está la infraestructura alternativa, si está encendida o se levanta bajo demanda, y en qué orden se recupera cada servicio.
Después se escribe el runbook —el procedimiento paso a paso, con responsables y con las credenciales accesibles desde fuera del entorno principal— y se prueba. Un plan que nunca se ha ejecutado es una hipótesis, y la hipótesis suele fallar en las dependencias que nadie había anotado.
Qué incluye el servicio
- Definición de RTO. Tiempo objetivo de recuperación por servicio, acordado con negocio y contrastado con lo que la infraestructura permite.
- Definición de RPO. Pérdida máxima de información asumible por servicio, que determina la frecuencia de replicación.
- Replicación. Réplica de máquinas y datos hacia el emplazamiento alternativo, con seguimiento del retraso.
- Infraestructura alternativa. Capacidad de cómputo, almacenamiento y red en otra ubicación, permanente o bajo demanda.
- Runbooks. Procedimiento escrito, paso a paso, con responsables, orden de arranque y criterios de validación.
- Orquestación. Automatización de los pasos repetitivos para reducir el tiempo y el margen de error humano.
- Dependencias. Mapa de qué debe estar arriba antes de qué: directorio, DNS, bases de datos, aplicaciones.
- Comunicaciones. Direccionamiento, publicación, certificados y conmutación de nombres hacia la ubicación alternativa.
- Pruebas. Ejecución real del procedimiento en entorno aislado, con informe de resultados y correcciones.
- Simulacros. Ensayos periódicos con el equipo del cliente, incluida la parte organizativa y de comunicación.
- Mantenimiento del plan. Actualización del plan cada vez que cambia la plataforma, que es lo que hace que siga siendo válido.
Estrategias según el RTO objetivo
Cada estrategia tiene un coste distinto. La elección la determina el impacto de la parada, no la tecnología disponible.
| Estrategia | Qué implica | Cuándo tiene sentido |
|---|---|---|
| Reconstrucción desde copia | Se levanta la plataforma desde la copia sobre infraestructura contratada tras el incidente. | RTO de días. Coste mínimo en reposo. |
| Réplica en frío | Datos replicados en el emplazamiento alternativo; la infraestructura se levanta cuando hace falta. | RTO de horas. Buen equilibrio para la mayoría de organizaciones. |
| Réplica en caliente | Infraestructura alternativa encendida y sincronizada, lista para asumir la carga. | RTO de minutos. Coste alto, reservado a servicios muy críticos. |
| Activo-activo | La carga se sirve simultáneamente desde dos ubicaciones. | Sin interrupción percibida. Exige diseño de aplicación compatible. |
Cómo se construye el plan
- 1
Análisis de impacto
Qué servicios son críticos, qué impacto tiene cada hora de parada y qué dependencias existen entre ellos.
- 2
Objetivos por servicio
RTO y RPO acordados servicio a servicio. No todo necesita el mismo nivel ni el mismo coste.
- 3
Diseño de la estrategia
Elección de la estrategia de recuperación y de la ubicación alternativa para cada grupo de servicios.
- 4
Implantación
Replicación, infraestructura alternativa, conectividad y acceso a credenciales desde fuera del entorno principal.
- 5
Runbook
Redacción del procedimiento con orden de arranque, responsables y criterios de validación.
- 6
Prueba real
Ejecución en entorno aislado. Casi siempre aparecen dependencias no documentadas: para eso se prueba.
- 7
Corrección
Ajuste del plan con lo aprendido y repetición de la prueba hasta que el resultado sea limpio.
- 8
Mantenimiento
Revisión periódica y actualización cada vez que cambia algo relevante en la plataforma.
Sobre las cifras de RTO y RPO
No publicamos objetivos de recuperación universales. Un RTO de cuatro horas es realista en una plataforma con réplica en caliente y absolutamente irreal en una que se reconstruye desde una copia externa de varios terabytes.
Los objetivos se definen por proyecto, servicio a servicio, y se contrastan con lo que la infraestructura puede sostener de verdad. Comprometer una cifra antes de haber probado la recuperación sería vender una expectativa.
Preguntas frecuentes
¿Necesitamos un segundo centro de datos?
No siempre. Con RTO de horas o días se puede recuperar sobre infraestructura contratada en el momento del incidente, incluida capacidad en cloud público. Un segundo emplazamiento permanente se justifica cuando el RTO es corto o cuando hay una obligación contractual.
¿Con qué frecuencia hay que probar el plan?
Al menos una vez al año, y semestralmente en plataformas críticas. También cada vez que se produce un cambio relevante: una migración, una aplicación nueva o un cambio de proveedor de conectividad pueden invalidar un procedimiento que funcionaba.
¿La prueba afecta a producción?
No. Las pruebas se ejecutan en red aislada, levantando la plataforma replicada sin tocar el entorno productivo. Sólo los simulacros completos, cuando el cliente decide hacerlos, implican una conmutación real y se planifican en ventana acordada.
¿Sirve el Disaster Recovery frente a un ransomware?
Ayuda, pero no basta por sí solo. Si la réplica es continua, el cifrado se replica también. Por eso el plan debe apoyarse en copias inmutables con retención suficiente para poder retroceder a un punto anterior al incidente.
Servicios relacionados
Backup inmutable anti-ransomware
Repositorios inmutables, Object Lock, air-gap lógico y separación de credenciales.
Ver servicioAlta disponibilidad (HA)
Clustering, redundancia, quorum y eliminación de puntos únicos de fallo.
Ver servicioInterconexión de centros de datos
Enlaces dedicados, redes privadas, VPN, BGP, redundancia y replicación entre ubicaciones.
Ver servicioDiseñemos su plan de recuperación
Empezamos por identificar los servicios críticos y sus objetivos de recuperación.