Comprobar de verdad las copias de seguridad: la prueba de restauración

Objetivo

Demostrar que, a partir de las copias de seguridad existentes, se obtiene un estado operativo, cuánto tarda en lograrse y cuántos datos se pierden en el proceso, antes de que una caída obligue a conocer la respuesta.

Requisitos previos

Una copia de seguridad que no esté en el mismo soporte que el original; un entorno de destino limpio (contenedor, máquina virtual, segunda instancia) que no pueda acceder al sistema de producción; acceso a las claves de las copias cifradas desde una fuente que no sea la propia copia; una ventana de tiempo y una persona que lleve el registro.

Pasos

1. Dejar por escrito la expectativa: qué punto en el tiempo se debe restaurar, qué bases de datos, archivos y configuraciones forman parte de él, y cómo se reconoce el éxito (número de filas, sumas de verificación, un inicio de sesión, una muestra de registros reales).
2. Elegir la copia como se haría en una emergencia real: solo a través de la ubicación de almacenamiento documentada y las credenciales documentadas, no desde el equipo que generó la copia.
3. Comprobar la integridad del archivo antes de restaurar nada; para ello restic describe el comando check, que, opcionalmente, con --read-data lee también los bloques de datos y no solo la estructura.
4. Restaurar en el entorno vacío: la documentación de PostgreSQL indica que los volcados que no son de texto se restauran con pg_restore y que los roles propietarios deben existir de antemano; justamente detalles como este faltan en los runbooks hasta que la prueba los descubre. Anotar cada comando y cada desviación.
5. Medir el resultado frente a la expectativa del paso 1: tablas y número de filas, sumas de verificación de archivos, arrancar la aplicación y ejecutar una función real (inicio de sesión, informe, pedido en modo de prueba).
6. Registrar la duración desde el inicio hasta que la aplicación es utilizable y compararla con el objetivo de recuperación acordado; igualmente, la diferencia entre el momento de la copia y el último estado de producción, que es la ventana de pérdida real.
7. Archivar el informe: fecha, estado de la copia, duración, desviaciones, puntos pendientes. Corregir el runbook, fijar la fecha de la siguiente prueba y eliminar el entorno de destino.

Resultado esperado

Una evidencia fechada de que la copia está completa, es legible y se puede restaurar en un tiempo conocido, o bien una lista de defectos concretos (clave ausente, archivo de configuración olvidado, rol inexistente, script obsoleto) que se corrigen antes de que llegue la emergencia.

Límites y base de verificación

La prueba verifica la copia en el momento elegido, no todas las futuras; debe repetirse tras cambios en el esquema, el cifrado o la ubicación de almacenamiento. Una restauración a pequeña escala dice poco sobre la duración con grandes volúmenes de datos. Los comandos siguen la documentación citada de PostgreSQL y restic; sobre la frecuencia adecuada de la prueba este artículo no hace ninguna afirmación, y el wiki tiene una pregunta abierta al respecto.