Vamos a ser claros desde la primera línea: en informática, la pregunta no es si va a ocurrir un desastre, sino cuándo te va a pillar tomando café.
Puede ser un ransomware que cifra hasta las fotos de la cena de Navidad de la empresa, un becario que borra la base de datos de producción creyendo que era el entorno de pruebas, o simplemente una tubería que revienta justo encima de tu rack de servidores (basado en hechos reales, lamentablemente).
Aquí es donde entra el Plan de Recuperación ante Desastres (Disaster Recovery Plan – DRP). Si no tienes uno, cuando ocurra lo inevitable, no tendrás un incidente informático; tendrás un currículum que actualizar.
Índice de contenidos
¿Qué es exactamente un DRP y por qué no es lo mismo que la Continuidad de Negocio?
A menudo la gente confunde términos y usa las siglas como si fueran Pokémon intercambiables. Vamos a poner orden.
El DRP es un documento técnico (y procedimental) que detalla, paso a paso, cómo recuperar la infraestructura tecnológica y los datos después de un evento catastrófico. Es el manual de «cómo resucitar a los muertos».
Por otro lado, el Plan de Continuidad de Negocio (Business Continuity Plan – BCP) es el hermano mayor y más estratégico. El BCP se preocupa de que la empresa siga ganando dinero mientras tú estás sudando tinta intentando arreglar los servidores.
La metáfora del restaurante:
- El Desastre: La cocina se incendia.
- El BCP: Decidir que, mientras se apaga el fuego, serviréis comida fría y bebidas en la terraza para no perder clientes.
- El DRP: Es el plano exacto de cómo reconstruir la cocina, dónde comprar los hornos nuevos y cómo recuperar las recetas de la abuela que se quemaron.
Sin DRP, el BCP es solo una lista de buenos deseos.
Los dos acrónimos que decidirán tu destino: RTO y RPO
Si te saltas esta sección, deja de leer y vete a ver Netflix, porque sin entender esto, tu plan no vale ni el papel en el que está escrito. Estos dos métricas definen cuánto dolor está dispuesta a soportar la empresa.
RTO (Recovery Time Objective) – Objetivo de Tiempo de Recuperación
Básicamente: ¿Cuánto tiempo podemos estar «apagados» antes de que el CEO empiece a despedir gente?
Es el tiempo máximo tolerable que un sistema puede estar caído.
- Si tu RTO es de 2 horas y tardas 4 en levantar el servicio, has fracasado.
- Si tu RTO es de 24 horas, puedes tomarte un café antes de empezar a restaurar copias.
Ojo: Todo el mundo quiere un RTO de «cero». Cuando les dices el precio de la infraestructura necesaria para tener un RTO cercano a cero (alta disponibilidad real, replicación síncrona), de repente les parece bien esperar un par de horitas.
RPO (Recovery Point Objective) – Objetivo de Punto de Recuperación
Esto va sobre datos. ¿Cuánta información estamos dispuestos a perder?
Imagina que haces copias de seguridad cada noche a las 00:00. Si el desastre ocurre hoy a las 23:00, habrás perdido 23 horas de trabajo. ¿Es aceptable?
- Para un banco, perder 1 segundo de transacciones es inaceptable (RPO ≈ 0).
- Para una web estática que se actualiza una vez al mes, perder un día da igual.
Nota del arquitecto: Definir un RPO bajo (poca pérdida de datos) suele ser más caro que definir un RTO bajo. La replicación de datos en tiempo real no es barata, amigos.
El BIA (Business Impact Analysis): Separa el grano de la paja
No todos los sistemas nacen iguales. El Análisis de Impacto en el Negocio (BIA) es el proceso donde te sientas con los jefes de cada departamento y les preguntas qué procesos son vitales.
Aquí descubrirás la cruda realidad:
- Crítico: El servidor de facturación y correo. Si caen, la empresa se para.
- Importante: La herramienta de RRHH. Molesta si no va, pero nadie muere hoy.
- Prescindible: La intranet donde se cuelgan las fotos de los cumpleaños.
Un error clásico es intentar proteger todo al mismo nivel. Eso es como ponerle una puerta acorazada a la caseta del perro. Gasta el presupuesto en lo Crítico.
Estrategias de Recuperación: No pongas todos los huevos en la misma cesta
Una vez sabes qué recuperar y cuánto tiempo tienes, necesitas el cómo. Aquí es donde la tecnología brilla (o falla estrepitosamente).
La regla 3-2-1 de los Backups
Si a estas alturas no conoces la regla 3-2-1 (aunque ya hay mejores estrategias de backup), tenemos un problema grave.
- 3 copias de tus datos.
- En 2 soportes diferentes (disco y cinta/nube).
- 1 de ellas fuera de la oficina (off-site).
Si tu copia de seguridad está en el mismo edificio que el servidor original y hay un incendio, felicidades: tienes unos datos tostados y una copia tostada.
Sitios de recuperación: ¿Dónde nos vamos?
Si tu oficina principal es zona catastrófica (inundación, terremoto, plaga de zombies), ¿dónde levantas los sistemas?
- Cold Site (Sitio Frío): Un local vacío con luz y agua. Tienes que llevar los equipos, instalarlos y configurarlos. Barato, pero tu RTO se irá a días o semanas.
- Warm Site (Sitio Tibio): Tienes los equipos, pero no los datos actualizados. Tienes que ir allí y volcar las copias de seguridad.
- Hot Site (Sitio Caliente): Una réplica espejo de tu centro de datos. Si cae el principal, el secundario entra casi al instante. Es la opción «Clase VIP», y cuesta como tal.
DRaaS (Disaster Recovery as a Service)
La nube ha democratizado esto. Ahora puedes replicar tus máquinas virtuales en AWS o Azure y encenderlas solo cuando las necesites. Es como tener un seguro de coche: pagas una cuota por si acaso, y si te chocas, te dan coche de sustitución.
El Equipo de Respuesta: ¿Quién tiene el botón rojo?
Un plan en papel no sirve si nadie sabe quién debe ejecutarlo.
Necesitas un organigrama de crisis claro:
- El líder del desastre: Alguien con autoridad para decir «Declaramos desastre, activad el plan». No puede ser una decisión por comité; debe ser una dictadura temporal.
- El equipo técnico: Los que saben qué cables conectar.
- El portavoz: Alguien que hable con los clientes (y la prensa) para que los técnicos no tengan que hacerlo. Créeme, no quieres a tu administrador de sistemas estresado hablando con la prensa.
Detalle vital: Ten una lista de contactos impresa. Sí, en papel. Si el Active Directory ha caído y el correo no va, ¿cómo buscas el teléfono del proveedor de internet?
El papel lo aguanta todo: Si no lo pruebas, no sirve
Este es el pecado capital número uno de la ciberseguridad. Tener un DRP precioso de 200 páginas que nadie ha probado nunca.
El día que lo necesites, descubrirás que la contraseña del backup cambió hace seis meses y nadie actualizó el documento. O que la cinta de restauración está corrupta.
Tipos de pruebas
- Checklist review: Leemos el plan y vemos si tiene sentido.
- Tabletop (Prueba de escritorio): Nos sentamos en una sala y planteamos un escenario: «Ha entrado un Ransomware, ¿qué hacemos?«. Cada uno explica su rol.
- Simulacro parcial: Restauramos algunos sistemas no críticos para ver si funcionan.
- Full Interruption (El valiente): Desconectamos el servidor principal y vemos si el secundario arranca. Advertencia: Haz esto un fin de semana y con pañales puestos, porque las cosas suelen romperse de verdad.
Checklist de Supervivencia para tu DRP
Aquí tienes una lista rápida para que la imprimas y la pegues en la nevera de la sala de servidores:
- Inventario de activos: ¿Sabes qué tienes? No puedes proteger lo que no sabes que existe (Shadow IT, te estoy mirando a ti). Revisa nuestro artículo dedicado al inventario de activos para conocer sus bases.
- BIA realizado: ¿Sabes qué es crítico y qué no?
- RTO y RPO definidos: Y firmados por gerencia. Que luego no vengan con prisas.
- Estrategia de Backup 3-2-1: Verificada y automatizada.
- Contactos de emergencia: Proveedores, equipo interno, policía, bomberos y el de las pizzas.
- Plan probado: Al menos una vez al año.
- Plan actualizado: Si cambias de infraestructura, actualiza el plan. Un mapa del tesoro antiguo no te lleva a ningún sitio.
Conclusión
El Plan de Recuperación ante Desastres no es un trámite burocrático para pasar la auditoría ISO 27001 (aunque ayuda). Es el chaleco salvavidas de tu empresa-
Vivimos en un mundo digital hostil. Los discos duros fallan, el software tiene bugs y los ciberdelincuentes no descansan. Un buen DRP convierte una catástrofe potencial que podría cerrar tu negocio en una anécdota tensa de un martes por la tarde.
Así que, hazte un favor: revisa tus copias de seguridad hoy mismo. Incluso los centros de datos se pueden quemar alguna vez… de verdad que pasa: OVH se quemó y con el mis webs. Por suerte tenía backups diarias sincronizadas en Google drive. Nunca se recuperaron los archivos de OVH pero al día siguiente yo ya tenía mis webs funcionando en otro proveedor de Hosting.
Para aquellos que quieran profundizar en la estructura formal, la NIST SP 800-34 (Guía de Planificación de Contingencia para Sistemas de Información Federales) es la biblia técnica de este tema. Aunque es densa, es el estándar de oro.
