Qué es un DRP y por qué tu DC no es resiliente sin uno

Tu data center tiene redundancia N+1 en chillers, dos UPS en configuración dual bus, generador con autonomía de 48 horas y doble acometida de CFE. Sobre el papel, es Tier III. En la realidad, no tienes un DRP. La diferencia entre ambos conceptos es la diferencia entre una infraestructura que tolera fallas de componentes y una organización que sobrevive a un desastre. Un DRP no es un documento que se archiva y se olvida; es el conjunto de decisiones, procedimientos y simulacros que permiten que tu operación continúe cuando el data center primario deja de existir como tal.

El acrónimo DRP significa Disaster Recovery Plan. NIST SP 800-34 Rev. 1 lo define como el plan documentado que contiene procedimientos para recuperar y restaurar sistemas de tecnología de información y datos críticos en caso de desastre. Pero esa definición es engañosa por lo corta: un DRP serio incluye análisis de impacto al negocio (BIA), estrategias de recuperación por niveles, sitios alternos definidos, procedimientos operativos documentados, roles y responsabilidades, métricas de recuperación, simulacros periódicos y un presupuesto anual dedicado. Sin todo eso, no tienes un DRP; tienes un documento.

Por qué la redundancia técnica no es resiliencia

El error más común que veo en data centers mexicanos es confundir redundancia con resiliencia. Son cosas distintas. La redundancia es la duplicación de componentes para que, si uno falla, otro tome su lugar. La resiliencia es la capacidad de la organización de continuar operando su misión cuando el sistema completo, redundante o no, falla.

Un ejemplo: tu data center tiene dos chillers en N+1. Uno falla. El segundo asume la carga. Esto es redundancia funcionando. Ahora imagina un escenario distinto: una inundación del cuarto eléctrico deja los dos chillers fuera de servicio simultáneamente. La redundancia N+1 no protege contra esto; protege contra falla de un solo componente. La resiliencia — seguir operando — requiere un plan que diga: si esto pasa, los servidores críticos migran al sitio alterno en 4 horas. Eso es un DRP.

Los tres números que importan: RTO, RPO y MTPD

Un DRP se mide por tres parámetros, definidos en NIST SP 800-34 y adoptados en ISO 22301:

• RTO (Recovery Time Objective). Tiempo máximo tolerable entre la interrupción del servicio y su restablecimiento. Si tu RTO es de 4 horas, la promesa al negocio es: tras una interrupción, los sistemas críticos vuelven a estar operativos en menos de 4 horas. Superar ese tiempo es un incidente mayor que afecta la operación del cliente y dispara cláusulas contractuales.

• RPO (Recovery Point Objective). Máxima cantidad de datos que estás dispuesto a perder, medida hacia atrás desde el momento de la interrupción. Si tu RPO es de 15 minutos, significa que la última copia válida de los datos tiene como máximo 15 minutos de antigüedad. Esto define la tecnología de replicación: para RPO de 0 necesitas replicación sincrónica; para RPO de 5 minutos, replicación asincrónica con snapshot cada 5 minutos es suficiente.

• MTPD (Maximum Tolerable Period of Disruption). El tiempo total más allá del cual la organización deja de ser viable. Para un banco, el MTPD puede ser de 24 horas; para una PyME de facturación, puede ser de 5 días. RTO siempre es menor o igual a MTPD. Lo que pasa entre RTO y MTPD es la zona donde el daño al negocio pasa de recuperable a catastrófico.

Los 4 tiers de un DRP según NIST

NIST SP 800-34 Rev. 1 clasifica las soluciones de disaster recovery en cuatro tiers, de menor a mayor capacidad:

Tier 1 — Backup simple sin sitio alterno

Backups en cinta o disco que se almacenan fuera del sitio (en otra ubicación física). RTO típico: 1-5 días. RPO: hasta 24 horas. La recuperación implica restaurar los backups en hardware nuevo (o reparado) en el sitio original o en uno nuevo. Costo: bajo. Adecuado para: archivos históricos, datos no críticos, sistemas internos de gestión.

Tier 2 — Sitio alterno caliente (warm site)

Un segundo data center con capacidad eléctrica, mecánica y de red pre-instalada, pero sin datos sincronizados. Los servidores existen en el sitio alterno pero deben ser configurados con los datos restaurados desde backup. RTO típico: 12-48 horas. RPO: 4-24 horas. Costo: medio. Adecuado para: sistemas internos críticos con tolerancia a medio día de indisponibilidad.

Tier 3 — Sitio alterno activo (hot site) con replicación

Dos data centers operando en paralelo con replicación asincrónica de datos entre ambos. El sitio alterno tiene capacidad completa y puede asumir la carga con poca reconfiguración. RTO típico: 1-6 horas. RPO: 5-30 minutos. Costo: alto. Adecuado para: sistemas de operación crítica, ERP, plataformas transaccionales.

Tier 4 — Resiliencia con cero downtime y cero pérdida de datos

Múltiples data centers con replicación sincrónica, balanceo de carga entre sitios, failover automático a nivel de aplicación. RTO: menos de 1 hora (típicamente minutos). RPO: 0 o casi 0. Costo: muy alto. Adecuado para: servicios financieros en tiempo real, plataformas de trading, infraestructura de pagos.

El BIA: el primer paso antes de escribir el DRP

Antes de redactar una sola línea del DRP, debes hacer un Business Impact Analysis (BIA). El BIA identifica las funciones críticas del negocio, los sistemas que las soportan, el impacto financiero y operacional de su interrupción, y las dependencias entre ellos. ISO 22301 define los componentes del BIA:

• Identificación de actividades críticas. Cuáles funciones del negocio, si se interrumpen, generan pérdida directa de ingresos, incumplimiento regulatorio, daño reputacional o impacto a clientes.

• Análisis de dependencias. Para cada actividad crítica, qué sistemas IT, qué proveedores externos, qué servicios públicos (energía, telecom, agua) y qué personal se requieren.

• Estimación de impacto financiero por tiempo de interrupción. Cuánto pierde el negocio por hora, por día, por semana de indisponibilidad. Esto sustenta el cálculo de qué tier de DRP se justifica económicamente.

• Definición de RTO y RPO por actividad. No todas las actividades necesitan el mismo tier. Una plataforma transaccional puede requerir RTO de 1 hora; el sistema de reportes financieros internos puede tolerar 24 horas.

El BIA toma entre 4 y 12 semanas dependiendo del tamaño de la organización. Es trabajo de entrevistas con líderes de cada área, no de un documento escrito por un solo consultor. Si el BIA se hace correctamente, el DRP se escribe solo; si se hace mal, el DRP termina siendo un wishlist técnicamente inalcanzable.

Tipos de desastre que el DRP debe contemplar

Un DRP maduro cubre al menos estas categorías de desastre, con procedimientos específicos para cada una:

• Desastres naturales. Inundación, incendio, terremoto, huracán, falla estructural del edificio. El DRP define el sitio alterno y la logística de movilización.

• Fallas eléctricas extendidas. Caída de CFE mayor a 4 horas, falla del generador, agotamiento de combustible, falla del UPS. El DRP define cuándo evacuar al sitio alterno y cuándo esperar la recuperación del sitio primario.

• Fallas de telecom. Caída del proveedor principal de internet, falla de la fibra oscura, ataque de denegación de servicio al uplink. El DRP define redundancia de carriers y DNS failover.

• Ciberataques. Ransomware que cifra datos de producción, exfiltración de información, compromiso de credenciales administrativas. El DRP define comunicación con el equipo de respuesta a incidentes, restauración desde backups offline y notificación a clientes y autoridades.

• Errores humanos. Borrado accidental de bases de datos, configuración errónea de firewalls, despliegue de código defectuoso en producción. El DRP define procedimientos de rollback, restauración desde backup reciente y validación de integridad.

• Fallas de proveedor. Caída del servicio de un SaaS crítico, insolvencia del proveedor de nube, incumplimiento de SLA del hosting. El DRP define el plan B cuando el proveedor no responde.

Cómo se redacta un DRP

La estructura típica de un DRP serio, basada en NIST SP 800-34 Rev. 1:

1. Alcance y supuestos. Qué sistemas cubre, qué se asume (ubicación del personal, disponibilidad de comunicación, escenarios excluidos).

1. Roles y responsabilidades. Quién declara el desastre, quién autoriza la activación del DRP, quién ejecuta cada procedimiento, quién se comunica con clientes y autoridades. Sin nombres propios (cambian); con roles: Director de TI, Gerente de NOC, Líder de Comunicación.

1. Procedimientos de detección y activación. Cómo se identifica que el evento califica como desastre (umbral de tiempo, severidad de impacto), cómo se escala al comité de crisis, cómo se declara formalmente el estado de DRP activo.

1. Procedimientos de recuperación. Por cada sistema crítico: paso a paso para levantarlo en el sitio alterno o restaurar desde backup. Incluye comandos, IPs, contactos, dependencias.

1. Procedimientos de comunicación. Quién habla con clientes, con autoridades regulatorías, con medios, con empleados, con proveedores. Plantillas de comunicación pre-aprobadas.

1. Plan de retorno a la normalidad. Una vez recuperado el sitio primario, cómo se regresa la operación sin generar una nueva interrupción. Incluye ventana de mantenimiento, validación de integridad, sincronización de datos.

1. Métricas y KPIs. RTO real vs objetivo, RPO real vs objetivo, tiempo de declaración del desastre, tiempo de recuperación completa, número de incidentes cubiertos por simulacro.

El error más caro: el DRP sin simulacros

He visto DRPs perfectamente redactados, de 200 páginas, con diagramas de red, procedimientos paso a paso y firmas de aprobación. Y he visto esos mismos DRPs fallar cuando se necesitaron, porque nadie los había probado. Un DRP que no se ha ejecutado en simulacro es un documento teórico. La primera vez que se ejecuta bajo presión, el documento revela sus inconsistencias, omisiones y suposiciones erróneas.

La frecuencia mínima aceptable de simulacros:

• Una vez al año, simulacro completo de recuperación en sitio alterno (con caída planeada del sitio primario o simulación de indisponibilidad).

• Dos veces al año, simulacro parcial de uno o dos sistemas críticos (restauración desde backup, failover de aplicación,切换 de proveedor de telecom).

• Trimestral, simulacro de escritorio (tabletop exercise). El equipo se sienta, el facilitador presenta un escenario, y se discute paso a paso qué se haría.

Cada simulacro debe generar un documento post-mortem: qué funcionó, qué falló, qué ajustar. El DRP se actualiza con esos hallazgos. Un DRP sin post-mortem es un DRP que envejece mal.

Cómo elegir el tier correcto para tu organización

Tres preguntas que cualquier CFO responde sin problema:

1. ¿Cuánto pierdes por hora de indisponibilidad de tu sistema más crítico? Si la respuesta es menos de $50,000 MXN/hora, probablemente un Tier 1 o 2 es suficiente. Si es más de $500,000 MXN/hora, necesitas Tier 3 o 4.

1. ¿Cuál es el costo anual de operar cada tier? Tier 1: bajo (backups offline, $200,000 MXN/año). Tier 2: medio (sitio warm, $1-3M MXN/año). Tier 3: alto (sitio activo, $5-15M MXN/año). Tier 4: muy alto (multi-site con replicación sincrónica, $20M+ MXN/año).

1. ¿Cuál es la probabilidad anual de un desastre que requiera el DRP? Si operas en zona sísmica alta o en zona de huracanes, la probabilidad anual de un evento mayor es mayor, lo que reduce el tiempo de payback del Tier 3 o 4. Si operas en zona estable con redundancia técnica robusta, Tier 2 puede ser suficiente durante años.

La respuesta no es siempre el tier más alto. Es el tier donde el costo anual del DRP es menor o igual a la pérdida esperada anual por desastres. Esa es la decisión financiera correcta.

Recomendación para empezar

Si hoy no tienes DRP, este es el orden mínimo viable:

1. Identifica tus 3-5 sistemas más críticos. Lo que, si se cae por 24 horas, genera pérdida directa de ingresos o incumplimiento regulatorio.

1. Para cada uno, define RTO y RPO con el dueño del negocio. No los inventes tú.

1. Documenta el procedimiento de recuperación de cada uno, paso a paso, en un documento que pueda ejecutar una persona con conocimiento técnico medio (no el experto que se fue hace 6 meses).

1. Establece backups offline (cinta, disco externo, almacenamiento inmutable) que se prueben restaurando al menos trimestralmente. Un backup que no se ha probado restaurando no es un backup.

1. Haz un simulacro de escritorio en los siguientes 60 días. El facilitador presenta un escenario: el data center primario está inaccesible. ¿Qué haces en la primera hora? ¿Quién habla con el cliente? ¿Cómo recuperas el sistema más crítico?

Eso es lo mínimo. Es menos que un DRP formal, pero es más que la mayoría de las organizaciones en México. A partir de ahí, escala al tier que tu BIA justifique.

Fuentes y referencias

• NIST SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems — https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf

• ISO 22301:2019 — Security and resilience: Business continuity management systems — Requirements — https://www.iso.org/standard/75106.html

• DRI International (DRII) — Professional Practices for Business Continuity Management — https://www.drii.org/

• Sentinel One — RTO vs RPO: Key Differences in Disaster Recovery Planning — https://www.sentinelone.com/cybersecurity-101/cloud-security/rto-vs-rpo/

• Splunk — What is Business Impact Analysis? — https://www.splunk.com/en_us/blog/learn/business-impact-analysis-bia.html