Qué es un plan de disaster recovery (y cómo montarlo en una PYME)

Un jueves por la tarde salta el diferencial de la oficina. Cuando vuelve la luz, el servidor no arranca. La copia de seguridad existe, pero nadie sabe cuánto tarda en restaurarse, ni en qué máquina se va a restaurar, ni quién tiene que hacerlo. Mientras se averigua, veinte personas están mirando la pantalla sin poder facturar.

Ese hueco entre "tenemos copias" y "estamos otra vez trabajando" es exactamente lo que cubre un plan de disaster recovery. Y en la mayoría de PYMEs que visitamos, ese hueco no está escrito en ningún sitio.

¿Qué es un plan de disaster recovery?

Un plan de disaster recovery, o plan de recuperación ante desastres, es el documento que describe cómo vuelve a funcionar la informática de una empresa después de un incidente grave. Fija cuánto tiempo se puede estar parado, con qué medios se restaura cada sistema, en qué orden y quién hace cada cosa. Su objetivo no es evitar el desastre, sino recortar lo que dura.

Un "desastre" aquí no es solo un incendio. En una PYME catalana, lo habitual es mucho más prosaico:

• Un ransomware que cifra el servidor de ficheros y las carpetas compartidas.
• Una avería de hardware que se lleva por delante el servidor del ERP.
• Un corte de luz largo o una subida de tensión que estropea equipos.
• Un error humano, alguien borra la carpeta equivocada y nadie lo ve hasta semanas después.
• Un fallo del proveedor de nube o del operador de internet.

Todos acaban en el mismo punto, la empresa no puede trabajar. Y el coste no lo marca la causa, lo marcan las horas.

Backup, disaster recovery y continuidad de negocio

Se usan como sinónimos y no lo son. La diferencia es práctica, no académica.

• Backup (copia de seguridad). Es tener los datos guardados en otro sitio. Responde a "¿existe una copia?".
• Disaster recovery. Es el procedimiento para volver a levantar sistemas y datos en un plazo conocido. Responde a "¿en cuánto tiempo estamos operativos?".
• Continuidad de negocio. Es el plan completo de la empresa, incluida la parte no informática. Dónde trabaja la gente si la oficina no es accesible, cómo se atiende al cliente mientras tanto, qué se comunica y a quién.

La confusión más cara es la primera. Tener backup sin plan de recuperación es tener el material de una obra sin planos ni albañil. Como ya escribimos en su momento, una copia que nunca se ha probado no es una copia, es una esperanza.

¿Qué son el RTO y el RPO?

Son las dos cifras que sostienen todo el plan. El RTO (tiempo objetivo de recuperación) es cuánto tiempo puede estar parado un sistema antes de que el daño sea serio. El RPO (punto objetivo de recuperación) es cuántos datos puedes permitirte perder, medido en tiempo hacia atrás desde el incidente.

Un ejemplo concreto. Si tu copia se hace todas las noches a las 22:00 y el servidor muere a las 17:00, has perdido el trabajo de todo el día. Tu RPO real es de 24 horas, aunque nadie lo haya decidido nunca. Y si restaurar ese servidor lleva dos días, tu RTO real es de dos días.

Lo importante es que esas dos cifras se eligen, no se heredan. Bajar el RPO a 15 minutos exige replicación continua. Bajar el RTO a menos de una hora exige tener a dónde arrancar, normalmente un equipo local que asume la operativa mientras se repara el original, o un salto automático a la nube. Ambas cosas cuestan dinero, así que la pregunta correcta es cuánto cuesta lo contrario.

Cómo saber qué RTO te puedes permitir

Hay una cuenta sencilla que sirve para empezar. Coge la facturación anual, y divídela entre las horas laborables del año, unas 1.800 en jornada normal. Una empresa que factura tres millones se mueve en torno a 1.650 euros por hora trabajada. Dos días parada son unas 32 horas, algo más de 50.000 euros de actividad que no se hace.

Esa cifra es tosca y se queda corta, porque no incluye lo que viene después. Las horas extra para recuperar el retraso, los pedidos que se van a otro, las penalizaciones por incumplir plazos, el tiempo del equipo dedicado a apagar el fuego. Pero sirve para lo que importa, poner el coste de la parada al lado del coste de la prevención y ver cuál de los dos números es mayor.

Con ese dato, la conversación cambia. Ya no se discute si el plan es caro, se decide qué RTO tiene sentido para cada sistema. Porque no todos valen lo mismo, el ERP y el correo pueden necesitar horas, y la carpeta del histórico de 2015 puede esperar tranquilamente una semana.

Qué debe incluir el plan, punto por punto

Un plan de disaster recovery útil cabe en pocas páginas. Lo que no puede faltar:

1. Inventario de sistemas críticos. Qué aplicaciones y datos sostienen la facturación, ordenados por prioridad de arranque. Sin este orden, el día del incidente se restaura lo primero que alguien recuerda.
2. RTO y RPO por sistema. Una cifra para cada uno, acordada con dirección y puesta por escrito.
3. Dónde está cada copia. Aplicando la regla del 3-2-1, tres copias de los datos, en dos soportes distintos, con una fuera de la oficina. Y al menos una de ellas inmutable o desconectada, para que un ransomware no pueda tocarla.
4. A dónde se restaura. Hardware de repuesto, equipo local de arranque inmediato o infraestructura en nube. Restaurar sin destino es la razón número uno por la que las recuperaciones tardan días, y por eso conviene decidir con calma qué servidor de disaster recovery necesitas y dónde ponerlo.
5. El procedimiento escrito. Paso a paso, con contraseñas y licencias accesibles fuera de los sistemas afectados. Un plan guardado solo en el servidor que se ha caído no existe.
6. Quién hace qué. Nombre y teléfono del responsable técnico, del proveedor informático, del operador y del seguro. Con suplente, porque los desastres no consultan el calendario de vacaciones.
7. Cómo se comunica. Qué se dice a los empleados, a los clientes y, si hay datos personales afectados, a la Agencia Española de Protección de Datos dentro del plazo de 72 horas que marca el RGPD.
8. Cuándo se prueba. Con fecha en el calendario y resultado por escrito.

Si tu empresa trabaja con Microsoft 365, el plan tiene que incluirlo de forma explícita. Correo, OneDrive, Teams y SharePoint entran dentro del alcance, porque la licencia no incluye copia de seguridad y sus plazos de retención son cortos.

Los cuatro fallos que más vemos

• El plan está en la cabeza de una persona. Funciona hasta el día que esa persona está de baja, de vacaciones o ya no trabaja en la empresa.
• Nunca se ha hecho una restauración completa. Se comprueba que el backup "está en verde" y se da por bueno. El verde solo dice que el trabajo terminó, no que los datos sirvan.
• Las copias están al alcance del atacante. En un disco conectado por USB o en una carpeta de red con permisos amplios. Un cifrado se las lleva junto al resto, y es justo lo que hace el ransomware antes de dejarte la nota.
• El plan tiene tres años. Desde entonces cambió el ERP, se migró el correo y entraron dos servidores nuevos. El documento describe una empresa que ya no existe.

¿Cada cuánto hay que probar el plan de recuperación?

Un simulacro completo al año como mínimo, y restauraciones parciales cada mes o cada trimestre. También hay que revisarlo cada vez que cambia algo importante, un servidor nuevo, una migración de correo o un cambio de aplicación de gestión. Un plan que no se prueba envejece igual que uno que no se escribe.

La prueba anual no tiene por qué parar la empresa. Se restaura en un entorno aparte, se cronometra cuánto se tarda de verdad y se compara con el RTO que habíais fijado. Si el cronómetro dice cuatro horas y el papel decía una, ya sabes en qué trabajar. Ese contraste, hecho una vez al año, es lo que convierte un documento en un plan.

Y si el incidente que te toca es un cifrado, las primeras horas tienen su propio guion, lo repasamos en qué hacer ante un ransomware.

Empieza por saber cuánto tardarías hoy

No hace falta montar el plan entero de golpe. Empieza por responder a dos preguntas con números, no con sensaciones. Si mañana por la mañana el servidor principal no arranca, ¿cuánto tardaríamos en volver a trabajar? ¿Y cuántas horas de trabajo perderíamos por el camino?

Si no sabes contestar, ese es el primer entregable. En Nodetic ese cálculo va dentro de nuestros planes de continuidad informática, con tiempos de recuperación por escrito y pruebas calendarizadas, no prometidas de palabra.

En una auditoría de continuidad informática revisamos tus copias, tus sistemas críticos y tu tiempo real de recuperación, y te decimos qué pasaría hoy si el jueves del diferencial fuera el tuyo.