El panel indica que las copias de seguridad terminaron correctamente. Sin una prueba de recuperación, sigue sin saberse si el equipo puede localizarlas, acceder a sus claves, restaurarlas y devolver datos utilizables a la aplicación.
Un ensayo de restauración debe terminar con criterios verificables. ‘La base arrancó’ es un hito técnico; recuperar el servicio exige comprobar también datos, permisos y consumidores.
Preparación: elige el incidente que quieres ensayar
Define una situación concreta: pérdida de una instancia, borrado accidental de un conjunto o indisponibilidad de una ubicación. El escenario determina qué recursos se consideran ausentes y qué accesos se pueden utilizar.
Si simulas la pérdida de la cuenta principal, no resuelvas toda la prueba utilizando una credencial que solo existiría en esa cuenta. Registra las excepciones del ejercicio para no atribuirle una cobertura que no ha demostrado.
La guía de AWS sobre pruebas periódicas de recuperación recomienda validar integridad, disponibilidad de los datos y objetivos de recuperación. El procedimiento siguiente concreta un ensayo para una plataforma con base de datos, archivos e informes derivados.
Paso 1. Escribe el alcance y las condiciones de éxito
Identifica el respaldo y el punto que pretendes recuperar. Incluye los registros de cambios u otras piezas necesarias y comprueba su disponibilidad antes de comenzar.
Define qué servicio debe funcionar al final. En un ejemplo construido, podría ser consultar un pedido, abrir su documento adjunto y generar un informe que lo incluya. Ese recorrido requiere más que la tabla de pedidos.
Acuerda el tiempo admisible para el ejercicio y la pérdida de información tolerable según el proceso. Son requisitos de la organización; no deben deducirse de una opción predeterminada del proveedor.
Paso 2. Prepara un destino aislado
Crea un entorno autorizado que no pueda escribir accidentalmente en producción. Revisa nombres, redes, permisos, tareas programadas y destinos externos antes de iniciar servicios restaurados.
Una copia de una aplicación puede conservar automatizaciones que envían correos o llaman a integraciones. Sustituye o desactiva esos efectos dentro del ensayo, y documenta qué parte de la experiencia se comprobará con destinos de prueba.
Aplica protección equivalente para los datos restaurados. El hecho de estar en un entorno de ensayo no elimina sus restricciones de acceso. Define también cómo se retirarán los recursos al terminar.
Paso 3. Ejecuta el procedimiento registrado
Utiliza el runbook que emplearía el equipo durante un incidente. Registra inicio, hitos, errores y decisiones. Si hace falta una acción que solo conoce una persona, incorpórala al procedimiento después de comprobarla.
No ajustes silenciosamente el ejercicio hasta obtener un resultado favorable. Una clave inaccesible, un permiso insuficiente o una dependencia olvidada son hallazgos que el ensayo debe conservar.
Distingue tiempo de preparación, restauración, validación y habilitación del consumidor. Esa separación ayuda a localizar dónde se consume el tiempo de recuperación.
Paso 4. Comprueba el dato, no solo el estado del recurso
| Nivel de control | Ejemplo de comprobación |
|---|---|
| Identidad del respaldo | Origen, fecha, versión y piezas utilizadas |
| Estructura | Tablas o colecciones y esquema esperado |
| Cobertura | Claves y periodos incluidos en el punto recuperado |
| Integridad | Relaciones y ausencia de duplicados inesperados |
| Datos rastreables | Operaciones conocidas anteriores al corte |
| Dependencias | Documentos, objetos y referencias que deben resolverse |
| Consumo | Consulta o recorrido funcional con permisos de prueba |
Compara contra evidencia compatible con el mismo corte. El estado actual de producción puede contener operaciones posteriores al respaldo y no es una referencia exacta para exigir igualdad de todos los totales.
Una huella de archivo ayuda a comprobar que se conserva el mismo objeto; no demuestra por sí sola que el archivo perteneciera al respaldo correcto. Combina identidad, integridad y controles de negocio.
Paso 5. Valida los consumidores derivados
Comprueba vistas, cachés, índices de búsqueda e informes. Pueden requerir reconstrucción o apuntar a rutas que no existen en el entorno restaurado.
Si el informe utiliza una transformación posterior al punto recuperado, identifica qué versión de la lógica debe aplicarse. Restaurar datos antiguos y ejecutar reglas actuales puede producir un resultado distinto del que se pretende reconstruir.
Cuando sea necesario regenerar un histórico, utiliza un backfill con entradas y validación definidas. Conserva el vínculo entre el respaldo y las salidas derivadas del ensayo.
Paso 6. Mide la recuperación completa
Registra cuándo el consumidor supera el criterio de aceptación. Ese momento puede ser posterior a la finalización de la herramienta de restauración.
Determina el último punto de información recuperable y explica los datos que quedarían fuera respecto al incidente simulado. La frecuencia de los backups no demuestra por sí sola la pérdida efectiva si faltan piezas o hay retrasos.
La comparación entre backup y réplica ayuda a identificar qué mecanismos intervienen, pero el resultado del ensayo depende de su configuración y de las dependencias observadas.
Cierre: convierte los hallazgos en trabajo verificable
Cada fallo necesita una acción, un responsable y una nueva comprobación. Conserva qué parte se validó y qué quedó simulada. Repite el tramo afectado cuando cambie una dependencia relevante.
Al terminar, confirma la retirada de copias temporales y recursos según la retención autorizada. Mantén la evidencia necesaria sin conservar indefinidamente datos adicionales.
Si necesitas preparar este ensayo en una plataforma de datos, comparte con Nexeus Big Data el inventario de respaldos y el recorrido que debe recuperar el usuario. Esa relación permite convertir una prueba técnica en una demostración concreta de recuperación.