Copia de seguridad y recuperación de un servidor doméstico: un pequeño ejercicio de restauración.

Un código de salida de copia de seguridad exitoso no garantiza que un servicio pueda reiniciarse a partir de los datos guardados. Separe la restauración de archivos, la legibilidad de la base de datos y las operaciones de la aplicación que necesite. Comience con un ejercicio que nunca acceda a datos de producción.

Definir la recuperación exitosa

Diagram 1 · Use the button to switch views

Un servicio de fotografía requiere relaciones entre las imágenes y los registros de la base de datos. La autenticación también puede depender de la configuración y las claves de cifrado. Defina el RPO (Objetivo de Punto de Recuperación) aceptable, independientemente del RTO (Duración de Recuperación) aceptable. La frecuencia de las copias de seguridad y el tiempo de restauración son medidas diferentes.

Ejecutar un ejercicio aislado

Guarde restore_lab.py y ejecute python3 restore_lab.py. Utiliza la biblioteca estándar de Python 3.12.3. Cada ejecución crea un directorio temporal nuevo, un archivo de texto y un registro SQLite. No detiene ni elimina ningún servicio o conjunto de datos existente.

El script utiliza la API de copia de seguridad de SQLite para copiar la base de datos, la empaqueta junto con el archivo de texto en un archivo ZIP y la restaura en otro directorio vacío. Verifica los hashes SHA-256, PRAGMA integrity_check y un registro SQL conocido. Consulte la explicación oficial de la API de copia de seguridad de SQLite (https://www.sqlite.org/backup.html).

file_hashes: pass
sqlite_integrity: pass
application_read: pass
scope: synthetic fixture only

Las tres comprobaciones se superaron el 7 de septiembre de 2026. En este caso, la lectura de la aplicación se refiere a la consulta SQL conocida, no al inicio de Immich o Nextcloud. El archivo directory impreso contiene la evidencia conservada. El archivo ZIP en ese directorio temporal es un artefacto de prueba, no una protección contra la pérdida del dispositivo de almacenamiento.

Capturar servicios reales de forma consistente

La copia ordinaria de archivos de bases de datos en producción puede no preservar la consistencia necesaria para la recuperación. Para PostgreSQL, revise los requisitos de métodos como los volcados SQL (https://www.postgresql.org/docs/current/backup-dump.html). La coherencia entre la instantánea de la base de datos y los archivos externos referenciados es un aspecto aparte.

La coincidencia de hashes establece la igualdad con la copia capturada. No demuestra que toda la aplicación fuera coherente en el momento de la captura.

Comprobaciones adicionales con restic

El siguiente es un procedimiento para un entorno donde restic ya está instalado; restic no se ejecutó en este ejercicio. Configure el repositorio y las credenciales por separado y registre restic version. Seleccione una instantánea y restáurela en un destino vacío.

restic snapshots
restic check --read-data
restic restore SNAPSHOT_ID --target /path/to/empty-restore

Reemplace el ID y la ruta con los de su entorno. La restauración (https://restic.readthedocs.io/en/stable/050_restore.html) y la verificación del repositorio (https://restic.readthedocs.io/en/stable/045_working_with_repos.html) responden a preguntas diferentes. Considere los costos de tiempo de ejecución y transferencia al leer datos almacenados con --read-data.

Mantenga un registro de recuperación

Registre la hora de captura, el inicio y el final de la recuperación, el volumen de datos, las versiones, los resultados de la verificación de archivos y las operaciones de la aplicación. Verifique en un entorno aislado antes de reemplazar los datos de producción, con el correo electrónico saliente y los webhooks deshabilitados. Las comprobaciones de autenticación y lectura de archivos convierten este sencillo ejercicio en un procedimiento específico del servicio para la plataforma del servidor principal (https://restic.readthedocs.io/en/stable/045_working_with_repos.html).