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.
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:
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.
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:
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.
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:
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.
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:
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.
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:
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.
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.
¿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.
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.