Tu backup existe, pero ¿se restaura? Prueba de recuperación completa

Publicado el 2026-11-14 por frfrand

Procedimiento para restaurar código, PostgreSQL, archivos, secretos y servicios en un entorno aislado, con medición de RTO y RPO.

# Tu backup existe, pero ¿se restaura? Prueba de recuperación completa

Un archivo llamado backup.zip no demuestra que una empresa pueda volver a operar. Para verificar continuidad hay que reconstruir una aplicación funcional, con datos coherentes, archivos, configuración y permisos, sin poner en riesgo producción.

1. Define qué significa recuperarse

Determina RPO (pérdida máxima de datos tolerable en el tiempo) y RTO (tiempo máximo objetivo para recuperar el servicio). Un respaldo nocturno podría implicar hasta casi un día de pérdida si no existen otras técnicas; un RTO de una hora es imposible de asegurar sin pruebas. Haz inventario de código, ramas, imágenes, base de datos, volumen de uploads, secretos, certificados, DNS, colas, cron y servicios externos.

2. Prepara un ensayo aislado

Crea VPS, contenedores o redes separados. No conectes cron, emails o integraciones reales de pagos al entorno restaurado. Usa credenciales de prueba y evita exposición pública de información sensible. Registra fecha del backup, herramienta, tamaño, checksum, versión de PostgreSQL y dependencias.

3. Restaura componentes en orden

1. Provisiona versiones compatibles de sistema, runtime y PostgreSQL. 2. Recupera código y dependencias desde un commit identificado. 3. Importa base de datos y archivos de usuarios en rutas consistentes. 4. Carga secretos mediante mecanismo seguro, nunca dentro del repositorio. 5. Aplica migraciones solo si corresponde al punto recuperado y verifica compatibilidad. 6. Arranca servicios y valida dependencias y colas.

Ejemplo orientativo para un volcado personalizado de PostgreSQL realizado correctamente:

createdb -h localhost -U app_restore app_restore
pg_restore -h localhost -U app_restore -d app_restore --exit-on-error backup.dump

4. Verifica negocio, no solo procesos

Confirma que usuarios autorizados inicien sesión, que un registro histórico esté presente, que imágenes se abran, que búsquedas devuelvan resultados y que las tareas puedan procesarse en modo seguro. Compara recuentos, integridad referencial y muestras con manifiestos de origen. Prueba una operación de lectura y una de escritura inocua. Documenta errores y sus causas.

5. Mide y aprende

Cronometra desde la declaración del incidente hasta la restauración comprobada. Calcula la antigüedad de los datos recuperados y compárala con el RPO/RTO. Registra los pasos manuales y las dependencias del administrador original. Automatiza las verificaciones periódicas, almacena copias fuera del servidor principal y comprueba el acceso de recuperación.

6. Estrategia de resiliencia

Un backup en el mismo disco que la aplicación no protege contra fallos de disco ni compromisos del servidor. Usa retención, separación de credenciales, cifrado, copias remotas y protección contra borrados maliciosos cuando sea posible. Versiona la infraestructura y documenta las llaves necesarias para descifrar.

Complementa con pg_dump y pg_restore y migraciones de base de datos.

Preguntas frecuentes

¿Un backup correcto prueba que restaura? No. ¿Debo restaurar sobre producción? No para un ensayo habitual. ¿Qué prueba es más importante? Recuperar un flujo de negocio completo con datos válidos.