Cómo evitar que las copias de seguridad de Immich capturen un estado incoherente

Evita copias de seguridad incoherentes de Immich tratando la base de datos y los archivos multimedia como una sola unidad de recuperación, cuyo orden de captura y actividad de escritura se controlan deliberadamente.

Una copia de seguridad puede contener todos los archivos que se le pidió copiar y aun así restaurarse mal si la base de datos hace referencia a recursos que no se capturaron, o si la copia multimedia corresponde a un momento distinto del catálogo. Define primero el límite de coherencia, elige un método detenido o activo coordinado y valida el resultado de forma aislada.

Define la unidad de recuperación antes de programar la copia de seguridad

Enumera la base de datos PostgreSQL, los archivos multimedia subidos, los datos de perfil, la configuración del despliegue, los valores de entorno, los secretos y cualquier ruta de almacenamiento personalizada necesaria para recrear el servicio. Clasifica por separado las miniaturas generadas, los vídeos codificados y los archivos de modelos, según si tu política de recuperación los protege o los regenera.

La comparación de ZimaSpace sobre las copias de seguridad de Immich en funcionamiento y detenido explica la elección básica de coherencia. Este flujo de prevención va un paso más allá: sea cual sea el método que elijas, debe producir un punto documentado que pueda restaurarse sin tener que adivinar qué base de datos corresponde a qué copia multimedia.

Escribe el orden de restauración junto al alcance de la copia de seguridad. Si el plan dice «restaurar fotos», pero no indica qué volcado de base de datos, configuración, credenciales y asignaciones de almacenamiento vuelven a conectar esas fotos con los usuarios y álbumes, la definición de la copia está incompleta antes de que comience la primera ejecución programada.

Usa una captura con el servicio detenido cuando el límite más sencillo sea aceptable

En un hogar pequeño que pueda tolerar una breve ventana de mantenimiento, pausa las subidas y detén los servicios de la aplicación que escriben el estado de la biblioteca. Crea la copia de la base de datos, captura los archivos multimedia y la configuración, y reinicia solo después de que la instantánea o copia tenga una marca de tiempo y un resultado de finalización claros.

Detener la aplicación no corrige automáticamente una ruta incorrecta. Verifica que la exportación de la base de datos se haya realizado correctamente, que se hayan incluido las raíces multimedia previstas y que el destino de la copia sea independiente de los datos activos que debe recuperar. Registra las horas de inicio y finalización para que las restauraciones posteriores puedan identificar la generación exacta.

El método es válido cuando no se producen escrituras de la aplicación durante la captura y una restauración de prueba devuelve los usuarios, el número esperado de recursos, los álbumes y una muestra de los originales esperados. Si el tiempo de inactividad supera habitualmente la tolerancia del hogar, cambia a un método activo coordinado en lugar de permitir silenciosamente que las subidas se reanuden a mitad de la copia de archivos.

En las copias activas, captura la base de datos y los archivos en un orden conocido

Cuando Immich deba permanecer disponible, crea un volcado coherente nativo de la base de datos en lugar de copiar el directorio de datos activo de PostgreSQL como archivos normales. Después, captura o crea una instantánea del árbol multimedia en el orden documentado y registra las subidas que lleguen durante la ventana de copia de seguridad.

El flujo práctico de copia de seguridad de la base de datos de Immich muestra el enfoque consciente de la base de datos. Los comandos y nombres de contenedores pueden variar según el despliegue, por lo que el principio transferible consiste en pedir a PostgreSQL una copia coherente en lugar de confiar en una copia recursiva activa de los archivos de la base de datos.

Prefiere un orden que no permita que la base de datos restaurada apunte a archivos multimedia que nunca entraron en la copia. Si la copia del sistema de archivos contiene archivos adicionales que la base de datos aún no conoce, estos pueden conciliarse de forma más segura que los registros de la base de datos cuyos originales referenciados están ausentes. Documenta cualquier subida que cruce el límite.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Coordina las instantáneas del sistema de archivos con enlaces de la base de datos en lugar de asumir atomicidad

Las instantáneas del sistema de archivos son valiosas porque capturan rápidamente un volumen, pero por sí solas no hacen que dos sistemas que cambian de forma independiente sean transaccionalmente coherentes. Si la base de datos y los archivos multimedia se encuentran en conjuntos de datos o dispositivos distintos, define enlaces previos y posteriores a la instantánea y deja visible su momento en el registro de copias de seguridad.

Un ejemplo de 2026 que combina software de copias de seguridad con enlaces de instantáneas de Btrfs muestra por qué la orquestación de instantáneas necesita límites explícitos de la aplicación o la base de datos. Usa la idea para coordinar las capturas; no copies sus comandos del sistema de archivos sin más en una distribución diferente.

Si la herramienta de instantáneas no puede coordinar el límite temporal de la base de datos y los archivos multimedia, vuelve a un volcado lógico de la base de datos junto con una copia multimedia en lugar de afirmar que la recuperación es atómica. La complejidad solo está justificada cuando el simulacro de restauración demuestra que la captura más rápida sigue devolviendo un estado coherente de la aplicación.

Haz que las pruebas de restauración formen parte del calendario de copias de seguridad

Una tarea de copia de seguridad correcta solo demuestra que la captura terminó. Selecciona periódicamente una generación reciente, restáurala bajo un nombre de host aislado, conecta el almacenamiento esperado y verifica los usuarios, los originales representativos, los álbumes, los permisos, el comportamiento de búsqueda y una copia nueva de la base de datos desde la instancia restaurada.

La descripción general de recuperación de PostgreSQL incluida en la planificación de copias de seguridad y restauración de PostgreSQL destaca la validación de la restauración y los objetivos de recuperación, en lugar de tratar la creación del volcado como el final del proceso. Aplica la misma disciplina a la unidad de recuperación combinada de Immich.

Declara fallida la política de copias de seguridad si la restauración de la base de datos funciona pero faltan archivos, si los archivos multimedia se abren sin usuarios ni relaciones, o si la recuperación depende de un secreto almacenado únicamente en el host averiado. Corrige el alcance, el orden, la retención o la independencia antes de aumentar la frecuencia de las copias; más copias incoherentes no crean un punto de recuperación fiable.