Probar el DR antes de necesitarlo

La primera vez que pedí ejecutar una prueba real de recuperación ante desastres en SUMāTO, alguien del equipo me dijo, con toda honestidad: "Tenemos el plan documentado, pero nunca lo hemos corrido completo". Esa frase me quitó el sueño. Un plan de DR que vive en un PDF y nunca se ejecuta no es un plan: es una hipótesis. Y descubrir que su hipótesis era falsa en plena caída del centro de datos, con el reloj corriendo y los clientes llamando, es la forma más cara posible de aprender. En noviembre de 2018, después de varios ejercicios, tengo una convicción clara: el DR no se mide por lo que está escrito, sino por lo que se ha probado.

En corto: Un plan de recuperación ante desastres que nunca se prueba es ficción organizada. Una prueba de DR (DR Test) verifica que usted puede realmente recuperar sistemas y datos dentro de los tiempos comprometidos, y convierte supuestos en evidencia. Sin pruebas periódicas, usted no tiene un plan: tiene una esperanza documentada.

¿Por qué un plan de DR sin pruebas es ficción?

Un plan de DR describe un futuro que usted espera que ocurra: restaurar el respaldo, levantar el sitio alterno, redirigir el tráfico, validar la integridad de los datos y volver a operar. Cada uno de esos pasos contiene supuestos que suenan razonables sobre el papel y se rompen en la práctica.

Los supuestos que más veces he visto fallar son estos:

• El respaldo existe, pero no restaura. El trabajo de copia terminaba "con éxito" cada noche, pero nadie había intentado leer ese respaldo de vuelta. Un backup que no se restaura no es un respaldo.
• La documentación está desactualizada. El procedimiento mencionaba un servidor que ya no existe, una IP que cambió o una persona que dejó la organización hace meses.
• Faltan credenciales o permisos. En la crisis, quien debía ejecutar no tenía el acceso, y quien tenía el acceso estaba inalcanzable.
• Las dependencias ocultas. El sistema crítico levantaba, pero dependía de un servicio secundario que nadie había incluido en el alcance de recuperación.

Ninguno de estos problemas aparece leyendo el documento. Solo aparecen cuando usted ejecuta. Por eso insisto: la prueba no es un trámite de cumplimiento, es el único momento en que su plan deja de ser una creencia y se convierte en una capacidad. Si quiere entender cómo se estructura un plan que de verdad se pueda probar, conviene partir de un plan de recuperación ante desastres bien definido en alcance y responsabilidades.

¿Qué es exactamente una prueba de DR?

Una prueba de DR es un ejercicio controlado en el que usted simula la pérdida de uno o varios componentes y verifica que el equipo, los procedimientos y la tecnología logran recuperarlos dentro de los objetivos acordados. No es un simulacro teórico de "qué haríamos si": es ejecutar, medir y dejar evidencia.

Una prueba seria responde tres preguntas concretas:

• ¿Recuperamos a tiempo? Es decir, ¿cumplimos el RTO, el tiempo máximo aceptable que el sistema puede estar caído?
• ¿Recuperamos sin perder más datos de lo aceptable? Es decir, ¿cumplimos el RPO, la cantidad máxima de información que podemos permitirnos perder medida en tiempo?
• ¿La información recuperada es íntegra y usable? No basta con que el sistema "encienda"; los datos deben ser consistentes y la operación debe poder continuar sobre ellos.

Si una prueba no mide contra esos objetivos, no es una prueba de DR: es una demostración para sentirse bien. La diferencia es la honestidad de los criterios de aceptación definidos antes de empezar.

¿Qué tipos de prueba de DR existen?

No todas las pruebas tienen el mismo costo ni el mismo riesgo. Lo sano es subir gradualmente en realismo a medida que el equipo gana confianza. Estos son los tipos que usamos, de menor a mayor exigencia:

• Revisión de escritorio (tabletop). El equipo se sienta y recorre el plan paso a paso ante un escenario hipotético. Sirve para detectar huecos en la documentación y en los roles. Es barata y no toca producción.
• Prueba de restauración aislada. Se toma un respaldo y se restaura en un ambiente separado para confirmar que los datos vuelven completos y legibles. Es la prueba que más fallas silenciosas destapa.
• Prueba parcial (walkthrough). Se ejecuta la recuperación de un subconjunto de sistemas en infraestructura alterna, sin afectar la operación real.
• Simulacro completo (full failover). Se conmuta la operación real al sitio o entorno de recuperación y se opera desde allí. Es la prueba más reveladora y también la de mayor riesgo, por lo que exige preparación, ventana acordada y plan de retorno.

Mi recomendación práctica es nunca saltar directamente al failover completo. Empiece por lo barato, corrija lo que aparezca, y suba el nivel cuando cada peldaño ya esté limpio.

¿Con qué frecuencia se debe probar?

No existe un número mágico universal, y desconfío de quien lo promete. La frecuencia adecuada depende de cuán crítico es el sistema y de cuánto cambia. Dicho eso, hay principios que sí sostengo:

• Pruebe los sistemas críticos con regularidad, no una vez al año "para la auditoría". Un sistema que define la operación merece ejercicios frecuentes.
• Pruebe después de cada cambio relevante. Una migración, una nueva integración o un cambio de proveedor invalidan supuestos del plan anterior.
• Pruebe cuando cambia la gente. Si quienes ejecutarían la recuperación ya no son los mismos, su capacidad real cambió aunque el documento siga igual.

La idea es que probar deje de ser un evento extraordinario y se vuelva una rutina. Una organización madura no recuerda cuándo fue su última prueba porque las hace de forma constante. La replicación continua entre entornos hace que estos ejercicios sean mucho menos traumáticos; en SUMāTO trabajamos esa capa con SyncDR para mantener los datos listos para recuperar sin grandes ventanas de inactividad.

¿Qué evidencia debe dejar una prueba?

Una prueba que no deja rastro es una anécdota. Para que el ejercicio sirva a la mejora continua y a cualquier auditoría, debe producir evidencia concreta. Lo que pido siempre que cerramos una prueba es:

• Tiempos reales medidos: cuánto tardó cada fase de la recuperación, contra el objetivo comprometido.
• Hallazgos y fallas: qué no funcionó, qué supuesto se rompió y qué paso del procedimiento estaba mal.
• Acciones correctivas con responsable y fecha: cada falla detectada se convierte en una tarea con dueño, no en una nota suelta.
• Decisión sobre el siguiente nivel: si la prueba pasó limpia, cuándo subimos al siguiente tipo de ejercicio.

Esta evidencia es lo que cierra el ciclo de mejora continua: probar, encontrar la falla, corregirla y volver a probar para confirmar que la corrección funcionó. Un hallazgo sin verificación posterior es solo una buena intención.

¿Cuánto cuesta descubrir las fallas en plena crisis?

El costo de probar es conocido, acotado y planificable: unas horas del equipo, una ventana coordinada, un ambiente de pruebas. El costo de no probar es desconocido hasta que ocurre el desastre, y entonces se paga todo junto y al peor precio.

Cuando usted descubre que el respaldo no restaura mientras el sistema está caído, ya no tiene margen. La operación está detenida, la presión es máxima, las decisiones se toman improvisando y cada minuto adicional erosiona la confianza de sus clientes. Lo que en una prueba habría sido un hallazgo corregido en calma, en la crisis se vuelve una herida abierta. He aprendido a verlo así: la prueba de DR es el seguro más barato que existe, porque transforma sorpresas catastróficas en tareas de mantenimiento manejables.

Preguntas frecuentes

¿Tener respaldos no es suficiente?
No. Un respaldo solo demuestra que se copiaron datos, no que esos datos se pueden recuperar y usar. La única forma de saber que un respaldo sirve es restaurarlo y validar su integridad. Hasta que no lo restaura, usted tiene una copia sin garantía.

¿Una prueba de DR afecta la operación?
Depende del tipo. Las revisiones de escritorio y las restauraciones en ambiente aislado no tocan producción. El failover completo sí conmuta la operación real, por eso se hace con ventana acordada, preparación previa y un plan de retorno claro. Por eso recomendamos subir de nivel gradualmente.

¿Qué pasa si la prueba falla?
Que la prueba haya cumplido su propósito. Una prueba fallida no es un fracaso: es exactamente el hallazgo que usted quería encontrar en un entorno controlado y no en medio de una crisis. Cada falla se convierte en una acción correctiva con responsable, y luego se vuelve a probar para confirmar el arreglo.

¿Cada cuánto deberíamos probar nuestro DR?
No hay un número único. Pruebe sus sistemas críticos con regularidad, y siempre después de cambios relevantes en tecnología, procesos o personas. La meta es que probar deje de ser un evento anual y se convierta en una rutina.

El primer paso

Si al leer esto usted no recuerda cuándo fue la última vez que su organización restauró un respaldo de extremo a extremo, ese es justamente el lugar por donde empezar. No necesita un failover completo mañana; necesita una primera prueba honesta que le diga qué tan real es su plan hoy.

En SUMāTO acompañamos ese ejercicio con un diagnóstico de capacidad de recuperación: revisamos su plan, definimos objetivos de tiempo y de datos, y diseñamos un calendario de pruebas que sube de nivel sin poner en riesgo su operación. Conversemos sobre su recuperación ante desastres y convirtamos su plan de ficción en una capacidad probada.