Cómo se ensaya un DRP: del tabletop al simulacro real

Hay una frase que resume medio problema de la continuidad: un plan de recuperación que nunca se probó no es un plan, es una hipótesis. Se ve bien en el PDF, tiene sus RTO y sus procedimientos, y nadie sabe si funciona porque nadie lo ha corrido nunca. El día del desastre no es el momento de estrenarlo. Ensayarlo sí tiene método, y va por niveles.

Los cuatro niveles de prueba

Van de menor a mayor realismo —y de menor a mayor costo y riesgo. La idea es subir de nivel conforme el plan madura, no saltar directo al más agresivo:

• 1. Repaso / checklist (walkthrough): alguien revisa el documento contra la realidad. ¿Los contactos siguen vigentes? ¿El inventario coincide? ¿Las versiones son las actuales? Barato, aburrido y sorprendentemente útil: aquí caen los errores por desactualización.
• 2. Tabletop (de escritorio): el equipo se sienta y habla el desastre. Alguien narra un escenario ("son las 2am, el datacenter está inundado") y cada quien explica qué haría, paso a paso. No se toca ningún sistema. Descubre huecos de decisión: quién declara el desastre, quién autoriza, a quién se llama. Es la prueba con mejor relación valor/riesgo.
• 3. Simulación / prueba en paralelo: se recupera de verdad, pero en un entorno aislado que no toca producción. Se levantan los sistemas en el sitio de recuperación y se verifica que arranquen y respondan. Aquí es donde se descubre si los respaldos de verdad restauran.
• 4. Interrupción real (full failover): se corta el sitio primario a propósito y se opera desde el DR site. Es la prueba definitiva y la de mayor riesgo; se hace cuando el plan ya maduró en los niveles anteriores y en ventanas controladas.

Lo que siempre aparece cuando pruebas

Las pruebas no fallan por lo exótico, fallan por lo básico y repetido:

• Los procedimientos no funcionan como estaban escritos: pasos que asumen conocimiento que quien está de guardia no tiene, o que quedaron obsoletos tras un cambio de infraestructura.
• Los respaldos no restauran: el backup corría "bien" durante meses y la restauración nunca se probó. Está corrupto, incompleto o tarda muchísimo más que el RTO.
• Nadie sabe quién declara el desastre: la decisión de "activar el plan" no tiene dueño, y el equipo pierde una hora preciosa esperando permiso.
• El plan está donde no se alcanza: guardado en el mismo sistema que se cayó.

Cada cuánto, y qué hacer con lo que encuentras

No hay un número mágico, pero sí un piso razonable: un tabletop al menos una vez al año y tras cada cambio importante de infraestructura, y una prueba de recuperación real con la frecuencia que tu RTO justifique —quien vende continuidad de minutos prueba mucho más seguido que quien tolera días. Y lo más importante: cada prueba produce lecciones aprendidas que se escriben y se corrigen en el plan. Una prueba que encuentra fallas y no actualiza el documento desperdició el ejercicio; el objetivo no es aprobar, es encontrar los huecos mientras cuestan poco.

La pregunta que conviene hacerse

No es "¿tenemos un DRP?" —esa se responde con un archivo. Es: ¿cuándo fue la última vez que alguien lo corrió de verdad, y qué cambió en el plan después? Si la respuesta es "nunca" o "no me acuerdo", entonces no tienes un plan probado, tienes una hipótesis bien redactada. Diseñar el DRP para que se pueda probar, correr los simulacros y convertir cada hallazgo en una corrección es parte de mantener un plan vivo —el único que sirve el día que arde.