Tener backups no basta: cómo preparar una prueba de restauración

La pregunta que nadie hace hasta que es tarde

«Sí, tenemos backups.» La respuesta tranquiliza hasta el día en que se necesitan y se descubre que la copia estaba incompleta, que nadie sabe cómo restaurarla o que la última buena es de hace tres meses. La única manera de saber si una copia sirve es restaurarla.

Qué es una prueba de restauración

Es un ejercicio planeado en el que tomas una copia real y la restauras en un entorno separado de producción, para comprobar que el sistema vuelve a funcionar con los datos esperados. El NCSC del Reino Unido recomienda en su guía para pequeñas empresas no solo hacer copias, sino comprobar que puedes recuperar los datos. El NIST, en su guía de planeación de contingencias, incluye las pruebas como parte del plan.

Preparar la prueba

Aislamiento

Un sitio restaurado puede enviar correos, ejecutar tareas programadas o conectarse a pasarelas de pago. Antes de encenderlo, desactiva envíos y conexiones externas, o usa credenciales de prueba. Restringe el acceso al entorno: contiene datos reales.

Validar

• El sistema arranca y la página principal carga.
• Se puede iniciar sesión con un usuario de prueba.
• Los registros más recientes de la copia están presentes.
• Los archivos e imágenes se ven.
• Una operación clave funciona en modo de prueba.

Mide el tiempo total, desde que se pide la copia hasta que el sistema queda validado. Ese número te dice cuánto tardarías en volver a operar.

Procedimiento

1. Elige el sistema y la copia a probar.
2. Prepara un entorno aislado.
3. Desactiva envíos y conexiones externas.
4. Restaura y anota el tiempo.
5. Valida con los criterios acordados.
6. Registra evidencias y hallazgos.
7. Elimina el entorno de prueba de forma segura o restringe su acceso.
8. Programa la siguiente prueba.

Ejemplo aplicado

Límites

Una prueba exitosa demuestra que esa copia se pudo restaurar en ese momento. No garantiza que todas las copias futuras funcionen: por eso conviene repetirla periódicamente.

Cómo usar el registro descargable

1. Una fila por prueba.
2. Confirma el aislamiento.
3. Registra tiempos y criterios cumplidos.
4. Programa la siguiente prueba.

Criterios de una prueba válida

Ejemplo sintético completo

Ejemplo sintético. Una empresa ficticia de servicios tiene copias diarias de su sistema de reservas. Programa su primera prueba de restauración en un servidor temporal sin acceso público y con el envío de correos desactivado.

Restaurar la base de datos toma 40 minutos; restaurar los archivos adjuntos falla porque la copia no los incluía. El sistema arranca, pero las reservas no muestran sus documentos. La empresa ajusta la copia para incluir los adjuntos y repite la prueba dos semanas después: todo restaura en 65 minutos y una persona de operaciones completa una reserva de prueba de principio a fin.

Registra ambas pruebas, define que la restauración completa toma alrededor de una hora y agenda la siguiente para el próximo trimestre. Ejemplo inventado.

Errores frecuentes, explicados

Restaurar sobre el entorno real para «ahorrar tiempo» puede sobrescribir datos actuales. Restaurar sin desactivar envíos puede mandar correos o cobros duplicados a clientes reales. Y dar por buena una restauración solo porque el sistema arrancó deja sin comprobar si los datos están completos. La prueba solo vale si se valida con criterios definidos antes de empezar.

Cómo saber si funcionó

• La restauración se completó en un entorno aislado.
• Los criterios de validación se cumplieron.
• El tiempo real de restauración es conocido.

Plan para las primeras cuatro semanas

1. Semana 1: define alcance y criterios.
2. Semana 2: prepara el entorno aislado.
3. Semana 3: restaura y valida.
4. Semana 4: corrige hallazgos y agenda la siguiente.

Diagnóstico antes de empezar

• Pregunta dónde están las copias y cada cuánto se hacen.
• Pregunta cuándo se restauró una copia por última vez.
• Define qué sistema sería más grave perder.

Un segundo ejemplo, en contraste

Ejemplo sintético. Una empresa ficticia restaura su sitio informativo sin problemas en 15 minutos. Su sistema de facturación, en cambio, depende de un proveedor externo que nunca le ha mostrado una restauración. La prueba pasa a ser una solicitud por escrito al proveedor. A diferencia del primer ejemplo, la prueba no dependía de su equipo. Ejemplo inventado.

Qué hacer cuando algo falla

• Si la restauración falla, no toques el entorno real: documenta el error y corrige la copia.
• Si tarda más de lo tolerable, revisa el método de copia.
• Si faltan datos, ajusta qué se respalda y repite.

Cómo medirlo con tus propios datos

• Registra la fecha, la duración y el resultado de cada prueba.
• Anota qué faltó en cada restauración.
• Compara el tiempo de restauración con lo que tu operación puede tolerar sin el sistema.
• Revisa si las correcciones de la prueba anterior se aplicaron.

La comparación entre pruebas sucesivas es tu mejor indicador. Si cada prueba restaura más completo y en menos tiempo, el proceso mejora. Si el tiempo supera lo que tu operación tolera, la conversación ya no es sobre copias sino sobre el método de recuperación, y eso debe discutirse con tu proveedor con estos registros en la mano.

Errores frecuentes

• Probar sobre producción.
• No desactivar correos o cobros en el entorno restaurado.
• Validar solo que «carga la página».
• No medir el tiempo.
• Dejar el entorno de prueba abierto con datos reales.

Checklist

• Entorno aislado.
• Envíos externos desactivados.
• Criterios de validación definidos.
• Tiempo medido.
• Siguiente prueba agendada.