Pregunta a tu gerente (o en una de esas TÚ eres el gerente o director) si existe un plan de recuperación ante desastres y muchas veces la respuesta será: Sí. Pídelo y aparecerá un PDF de hace seis años que nadie ha vuelto a abrir —a veces guardado, con una ironía perfecta de esas de la vida, en el mismo servidor que se supone que protege. Auch. Tener un DRP y tener un DRP que sirva son cosas distintas, y la diferencia, otra vez, se descubre el peor día y de la peor manera.
Para qué sirve de verdad
Un plan de recuperación ante desastres (DRP) no es un requisito de auditoría que se llena y se archiva. Es el guion que alguien —quizás no tú, quizás si, quizás alguien de guardia a las tres de la mañana de un sábado, con medio entorno de producción caído y dirección presionando y preguntando: ¿A qué hora queda? Esa es la prueba de todo lo que contiene: ¿Podría usarlo para recuperar la operación una persona que no lo escribió? Si la respuesta es no, no es un plan, es un adorno.
Qué debe contener
Un DRP útil, sin relleno, incluye:
- Inventario y criticidad: qué sistemas hay y cuáles se recuperan primero. No todo vuelve a la vez; hay que saber el orden.
- RPO y RTO por sistema: cuánto dato se tolera perder y en cuánto tiempo debe volver cada uno. Sin estos números —los de RPO y RTO— el plan no tiene metas.
- Roles y contactos: quién hace qué, quién decide, a quién se llama. Con teléfonos que funcionen aunque el correo esté caído.
- Procedimientos paso a paso: cómo se restaura cada cosa, en concreto. No "restaurar el servidor", sino los pasos reales.
- Dependencias: qué necesita qué para levantar. El orden importa, y las dependencias ocultas son lo que descarrila una recuperación.
- Plan de comunicación: qué se le dice al equipo, a los clientes y —si aplica— a las autoridades, y quién lo dice.
Lo que lo vuelve papel mojado
Un DRP se echa a perder por tres motivos, y todos son evitables:
- Nunca se probó. Los procedimientos que se ven perfectos en el documento fallan al ejecutarlos. Solo un simulacro lo revela —es el mismo principio de que un backup sin probar no es un backup.
- Está desactualizado. La infraestructura cambió; el documento no. Cada servidor nuevo, cada migración, cada sistema que se dio de baja y quedó en el plan lo aleja de la realidad.
- Es inaccesible cuando arde. Guardado solo en la red que cayó, o en la cabeza de la única persona que no contesta el teléfono ese día.
Un documento vivo, no un entregable
Aquí está lo que conviene aceptar de entrada: un DRP no es un proyecto con fecha de cierre, es un proceso. Se revisa tras cada cambio importante y al menos una vez al año, se valida con simulacros, y se guarda donde se pueda alcanzar cuando todo lo demás falle. Eso cuesta disciplina —igual que probar restauraciones o mantener el inventario al día— y es exactamente esa disciplina la que separa a quien tiene un plan de quien tiene un archivo.
Ayudar a redactarlo, probarlo y mantenerlo vivo —y, cuando el RTO lo exige, respaldarlo con DRaaS real en lugar de solo con buenas intenciones— es parte de lo que hacemos. Porque el día que arde, un plan vivo es la diferencia entre una mala tarde y una mala noticia.