Continuidad de negocio y plan de recuperación:
RTO, RPO y por qué tus backups no bastan
Serie Blue Team | unfantasmaenelsistema.com
Casi cualquier organización sabe decir «tenemos copias de seguridad». Muy pocas saben responder a la siguiente pregunta: si mañana a las ocho de la mañana el centro de datos, el proveedor de nube o el dominio entero deja de funcionar, ¿en cuántas horas vuelve a facturar la empresa, y cuánto trabajo se pierde por el camino? Esa segunda pregunta es la que responde un plan de continuidad de negocio, y su respuesta rara vez coincide con lo que la gente supone.
Los backups son una pieza necesaria pero pequeña de ese plan. Restaurar un fichero es fácil; reconstruir en orden un servicio con sus bases de datos, su identidad, su DNS, sus integraciones y sus proveedores externos, mientras el negocio presiona para volver ya, es un ejercicio completamente distinto. Este artículo explica el vocabulario (BIA, RTO, RPO), las estrategias de recuperación, las dependencias ocultas que tumban los planes bien redactados y cómo se prueba todo esto antes de necesitarlo.
Qué aprenderás en este artículo
La diferencia entre continuidad de negocio, recuperación ante desastres y copia de seguridad · Cómo hacer un BIA ligero: identificar procesos críticos y asignarles RTO y RPO · Qué significan RTO y RPO en horas y en euros, con ejemplos · Estrategias de recuperación: sitio frío, templado y caliente, y el papel de la nube · Las dependencias ocultas (DNS, identidad, telefonía, proveedor único) que rompen el plan · Cómo cambia todo cuando el desastre es un ransomware · Los tres niveles de prueba: de escritorio, restauración parcial y failover completo
1. Tres cosas distintas: continuidad, recuperación y backup
Se usan como sinónimos y no lo son. Confundirlas lleva a planes con agujeros: se invierte en la parte técnica y se olvida la organizativa, o al revés.
| Concepto | Qué cubre | Pregunta que responde |
|---|---|---|
| Continuidad de negocio (BCP) | Que la organización siga operando sus procesos esenciales durante una interrupción, con o sin tecnología (procedimientos manuales, sedes alternativas, personas) | ¿Cómo sigue funcionando el negocio mientras los sistemas están caídos? |
| Recuperación ante desastres (DRP) | La parte tecnológica del plan: reconstruir sistemas, datos y comunicaciones hasta un nivel de servicio aceptable | ¿Cómo y en qué orden vuelven a estar en pie los sistemas? |
| Copia de seguridad (backup) | Disponer de una copia de los datos desde la que restaurar | ¿De dónde saco los datos para reconstruir? |
El backup alimenta al DRP, y el DRP es un capítulo del BCP. Un plan que solo tiene backups asume, sin decirlo, que alguien sabrá improvisar el resto bajo presión. Casi nunca es así.
2. El BIA: qué procesos importan y cuánto pueden esperar
El análisis de impacto en el negocio (Business Impact Analysis) es el cimiento del plan y no requiere una consultora ni seis meses. Consiste en listar los procesos de negocio —no los sistemas—, estimar qué pasa si cada uno se detiene, y a partir de ahí asignarle dos números: cuánto tiempo puede estar caído (RTO) y cuántos datos recientes puede permitirse perder (RPO).
- Inventario de procesos: facturación, atención al cliente, producción, nóminas, logística, contratación — en el lenguaje del negocio, no en el de infraestructura
- Impacto en el tiempo: qué se pierde a la hora, al día y a la semana de parada — ingresos, penalizaciones contractuales, obligaciones legales, reputación, seguridad de personas
- Ventana crítica: muchos procesos toleran bien una caída un martes por la tarde y nada una caída el día de cierre de mes o de campaña
- Dependencias: de qué sistemas, datos, proveedores y personas depende cada proceso — aquí es donde el BIA conecta con el inventario técnico
- Recursos mínimos: con qué se puede operar en modo degradado (un portátil, una hoja de cálculo, un teléfono) hasta que vuelva el servicio completo
El error de puntuarlo todo como crítico
Si cada proceso sale del BIA con RTO de una hora, el plan es a la vez carísimo e inservible · La priorización es el entregable: normalmente un 20 % de los procesos concentra el impacto grave y merece inversión real en recuperación rápida · El resto puede tolerar recuperación en días con procedimientos manuales, y decirlo por escrito libera presupuesto para lo que de verdad importa
3. RTO y RPO, con números
Son los dos parámetros que traducen «esto es importante» en una decisión de arquitectura y de presupuesto. Conviene fijarlos por proceso, no para toda la organización de golpe.
| Parámetro | Definición | Ejemplo |
|---|---|---|
| RTO — Recovery Time Objective | Tiempo máximo aceptable desde que se declara el desastre hasta que el proceso vuelve a estar operativo | El TPV de la tienda online: RTO de 1 hora. La intranet de RRHH: RTO de 3 días. |
| RPO — Recovery Point Objective | Cantidad máxima de datos recientes que se puede permitir perder, medida en tiempo | Base de datos de pedidos: RPO de 5 minutos (replicación). Repositorio de documentos: RPO de 24 horas (copia nocturna). |
| MTD / MTPD — Máximo tiempo de parada tolerable | El umbral a partir del cual el daño es irreversible; el RTO siempre debe quedar por debajo | Si a las 72 horas se pierde el cliente y el contrato, el MTD es 72 h y el RTO se fija en 24-48 h. |
| WRT — Work Recovery Time | Tiempo adicional, tras recuperar el sistema, para validar datos y volver a la operación normal (recuperar el trabajo pendiente, cuadrar) | El ERP arranca en 4 h (RTO) pero se tardan 6 h más en reconciliar transacciones antes de facturar. |
La regla práctica: el RPO lo determina la frecuencia y el tipo de copia o replicación; el RTO lo determina la estrategia de recuperación y el grado de automatización. Bajar cualquiera de los dos cuesta dinero de forma no lineal: pasar de un RPO de 24 horas a uno de 6 horas suele ser barato; pasar de 1 hora a 1 minuto puede multiplicar el coste de la plataforma.
4. Estrategias de recuperación: frío, templado, caliente
La estrategia es lo que hace posible (o imposible) el RTO que se ha fijado. Se describe clásicamente con la temperatura del sitio alternativo, y hoy casi siempre se implementa sobre nube o sobre un segundo proveedor.
| Estrategia | Qué hay preparado de antemano | RTO típico | Coste relativo |
|---|---|---|---|
| Sitio frío (cold) | Espacio y conectividad, sin hardware ni datos cargados; se aprovisiona todo tras el desastre | Días | Bajo |
| Sitio templado (warm) | Infraestructura provista y configurada, datos restaurados periódicamente pero no en tiempo real | Horas | Medio |
| Sitio caliente (hot) | Réplica casi idéntica con datos sincronizados de forma continua, lista para asumir carga | Minutos | Alto |
| Activo-activo | Dos ubicaciones sirviendo tráfico a la vez; la caída de una es transparente | Casi cero | Muy alto |
| Copia inmutable en frío (para ransomware) | Copia aislada, no borrable, verificada; no acelera el RTO pero garantiza que existe un punto limpio | N/A (es el origen, no el destino) | Bajo-medio |
- La nube no es un plan de recuperación por sí sola: replicar a otra región del mismo proveedor protege de un fallo de centro de datos, no de un borrado por credenciales comprometidas ni de una caída global del proveedor ni de un problema de facturación que suspende la cuenta
- Copias de configuración, no solo de datos: infraestructura como código, plantillas, definiciones de red y políticas de identidad exportadas y versionadas fuera del entorno que protegen
- Recuperación por niveles: no todo necesita sitio caliente; una arquitectura sensata mezcla caliente para el núcleo transaccional y templado o frío para el resto
5. El plan escrito: quién lo activa y cómo
Un plan de recuperación que solo describe pasos técnicos y no dice quién decide, cuándo y con qué autoridad, se queda bloqueado en la primera hora de la crisis real. La parte de gobierno es tan importante como los procedimientos.
- Criterios de activación: qué situación concreta convierte una incidencia en un desastre declarado, y quién tiene autoridad para declararlo (con un suplente para cada rol)
- Roles y responsabilidades: coordinador de crisis, responsable técnico de recuperación, portavoz, enlace legal y de cumplimiento, enlace con proveedores — con nombres y teléfonos
- Árbol de llamadas: cómo se avisa a cada persona, en qué orden, y por qué canal alternativo si el corporativo está caído
- Procedimientos de recuperación por sistema: paso a paso, con el nivel de detalle suficiente para que los ejecute alguien que no sea el experto habitual (que puede estar de vacaciones o ilocalizable)
- Criterios de vuelta a la normalidad: quién declara el incidente cerrado y con qué comprobaciones
- Copia del plan fuera de banda: impresa o en un almacenamiento independiente; un plan que solo vive en el wiki corporativo desaparece justo cuando se necesita
La dependencia del héroe
Si la recuperación de un sistema crítico depende de que una persona concreta esté disponible y con su portátil, eso no es un plan: es una apuesta · Los procedimientos deben estar escritos para ser ejecutados por otra persona con perfil técnico general, no solo por quien los redactó · Las credenciales de emergencia (break-glass) deben estar custodiadas de forma que dos personas puedan acceder a ellas sin depender de un tercero concreto
6. Las dependencias ocultas que tumban el plan
La mayoría de los planes de recuperación fallan no por el sistema que querían recuperar, sino por algo de lo que ese sistema dependía y que nadie había puesto en la lista. Un buen BIA las caza; una prueba real las confirma.
| Dependencia | Cómo rompe la recuperación | Mitigación |
|---|---|---|
| DNS | Los sistemas restauran, pero nadie los resuelve; el proveedor de DNS es un tercero sin plan de contingencia propio | DNS secundario en otro proveedor; TTL revisados; control del registro del dominio |
| Identidad (AD / IdP) | Todo depende del inicio de sesión único; si la identidad no arranca primero, nada más arranca | Recuperar identidad como paso 1 del orden; controladores/tenants redundantes; cuentas de emergencia locales |
| Telefonía y comunicación | El árbol de llamadas usa el móvil corporativo o Teams/Slack, que están en el dominio caído | Lista de contactos fuera de banda; canal de crisis en un servicio independiente |
| Proveedor único (SaaS, nube, ISP) | Toda la resiliencia interna no cubre una caída del proveedor del que se depende al 100 % | Segundo proveedor o salida de datos contractual; aceptar y documentar el riesgo residual si no hay alternativa |
| Licencias y certificados | El sistema arranca pero no valida porque el certificado caducó o el servidor de licencias no responde | Inventario de caducidades; certificados y claves en la copia; modo offline de las licencias |
| Documentación y credenciales | El procedimiento está en el sistema que hay que recuperar; las claves en un gestor que también cayó | Copia del plan y acceso de emergencia al gestor de secretos fuera del entorno protegido |
7. Cuando el desastre es un ransomware
El ransomware rompe los supuestos del DRP clásico, pensado para incendios, inundaciones o fallos de hardware. En esos casos la copia es fiable y el problema es de tiempo. En un ransomware, el atacante ha estado dentro semanas, ha buscado y cifrado las copias accesibles, y puede haber dejado persistencia en la propia imagen que se va a restaurar.
- El punto de recuperación limpio no es «el último backup»: hay que identificar cuándo empezó el compromiso y volver a antes de esa fecha, aunque eso suponga un RPO real de días o semanas
- Copias inmutables y aisladas: al menos una copia que el atacante no pueda borrar ni cifrar aunque tenga credenciales de administración (object lock, air gap, soporte offline)
- Orden de recuperación en entorno aislado: reconstruir en una red limpia y separada, no sobre la que sigue comprometida; identidad primero, luego núcleo, luego el resto
- Verificación de integridad antes de reconectar: análisis de las imágenes restauradas, rotación de todas las credenciales y secretos, revisión de tareas programadas y cuentas antes de dar servicio
- Decisiones de negocio en paralelo: comunicación, obligaciones de notificación y valoración legal no esperan a que termine la parte técnica
Enlace con el resto de la serie
La regla 3-2-1 y las copias inmutables se tratan a fondo en nuestro artículo sobre backups que sobreviven a un ransomware · El ensayo de la decisión y la comunicación de crisis está en el artículo sobre ejercicios de mesa · Este artículo es el que une ambos: convierte «tenemos copias» en «sabemos en qué orden y en cuánto tiempo vuelve el negocio»
8. Probar el plan: tres niveles
Un plan sin probar es una hipótesis. Las pruebas se escalan en coste y en realismo, y conviene combinarlas a lo largo del año en vez de hacer una única prueba anual grande.
| Nivel de prueba | En qué consiste | Qué valida | Frecuencia razonable |
|---|---|---|---|
| De escritorio (walkthrough / tabletop) | El equipo recorre el plan en una sala ante un escenario narrado, sin tocar sistemas | Que el plan existe, se conoce, los roles están claros y los contactos son correctos | Semestral |
| Restauración parcial | Se restaura de verdad un sistema o base de datos en un entorno de pruebas y se verifica su integridad | Que las copias son legibles, completas y restaurables en el tiempo previsto | Trimestral, rotando sistemas |
| Failover completo | Se conmuta un servicio real (o un conjunto) al sitio alternativo y se opera desde allí un tiempo | El RTO real de extremo a extremo, incluidas las dependencias ocultas y el WRT | Anual, para los procesos más críticos |
- Medir siempre: cada prueba anota el RTO y el RPO reales conseguidos y los compara con los objetivos; la desviación es el hallazgo
- Probar la vuelta, no solo la ida: el failback al entorno principal suele estar menos ensayado y da tantos problemas como el failover
- Acta con dueño y plazo: igual que en un ejercicio de mesa, cada hueco detectado se convierte en una acción concreta con responsable y fecha
- Revisión del plan tras cambios: una migración, un proveedor nuevo o una reorganización invalidan partes del plan; la revisión anual es el mínimo, no el ideal
Para seguir profundizando
ISO 22301 — norma de sistemas de gestión de continuidad de negocio; ISO 22317 para el BIA en detalle · NIST SP 800-34 — guía de planificación de contingencia para sistemas de información (define RTO, RPO, MTD) · NIST SP 800-84 — pruebas y ejercicios de los planes · Guías del CCN-CERT sobre continuidad y el marco del ENS en materia de disponibilidad · Nuestros artículos sobre backups 3-2-1, ejercicios de mesa y análisis de riesgos con MAGERIT
Conclusión
Tener copias de seguridad responde a «¿de dónde saco los datos?». La continuidad de negocio responde a las preguntas que de verdad importan cuando algo grande se cae: qué procesos hay que levantar primero, en cuánto tiempo, cuántos datos se pierden por el camino, quién lo decide y de qué depende cada paso.
El trabajo se hace en frío: un BIA ligero que priorice, unos RTO y RPO realistas por proceso, una estrategia de recuperación acorde, un plan escrito que otra persona pueda ejecutar y —sobre todo— pruebas periódicas que conviertan las suposiciones en números medidos. Hecho así, el día del desastre el plan es aburrido, que es exactamente como debe ser.
unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)