¿Deberías hacer una copia de seguridad de Immich Live o detener primero el servicio?

Detén Immich primero cuando quieras el límite de coherencia más sencillo y fácil de explicar; usa una copia de seguridad en vivo solo cuando puedas realizar un volcado nativo de la base de datos y coordinar la captura o instantánea de los archivos multimedia para conocer su relación durante la restauración.

Immich almacena los registros de los recursos en PostgreSQL, mientras que los archivos originales y derivados residen en el almacenamiento, por lo que una copia recursiva normal en vivo puede observar momentos diferentes. Para un hogar pequeño, una breve ventana de mantenimiento suele ser más segura que una orquestación compleja. Cuando las cargas continuas sean importantes, mantén el servicio activo, pero usa herramientas compatibles con la base de datos, registra el orden de captura, protege los recursos que lleguen recientemente y evalúa la copia de seguridad mediante una restauración aislada.

Define Cada Componente que Debe Recrearse Durante la Restauración

Haz un inventario de la base de datos PostgreSQL, la biblioteca de cargas, los archivos multimedia generados que necesite tu política, las definiciones de bibliotecas externas, los archivos de Compose y de entorno, los secretos, la configuración del proxy y las claves de cifrado. Clasifica qué elementos administra Immich y cuáles pueden regenerarse.

Un artículo práctico sobre copias de seguridad de bases de datos explica cómo usar un volcado de PostgreSQL en lugar de tratar el directorio activo de la base de datos como archivos normales. Su método de copia compatible con la base de datos admite el funcionamiento en vivo; confirma los comandos y las versiones para tu implementación.

Un plan falla si protege los originales, pero no puede restaurar sus registros, o si protege la base de datos y omite los archivos multimedia. Escribe el orden de restauración junto al orden de la copia de seguridad antes de decidir si el tiempo de inactividad es aceptable.

Elige una Copia con el Servicio Detenido para Obtener el Límite más Claro

Pausa las cargas, detén correctamente la aplicación y los trabajadores de Immich, y después realiza una copia nativa de la base de datos y copia o crea una instantánea de los archivos multimedia y de los archivos de implementación. Mantén PostgreSQL en ejecución solo cuando sea necesario para el volcado, o detenlo correctamente antes de crear una instantánea del almacenamiento diseñada para ese servicio.

Detener el servicio no corrige las rutas incorrectas ni un alcance incompleto, así que verifica los montajes y los tamaños de los archivos. Una ejecución correcta no tiene escrituras activas de Immich durante la captura, incluye una copia de seguridad de la base de datos realizada correctamente, muestras de archivos multimedia legibles, sumas de comprobación y una hora de reinicio documentada.

La guía de ZimaSpace sobre la verificación de claves y restauraciones de copias de seguridad refuerza que una copia realizada en un sistema inactivo no es recuperable hasta probar sus credenciales y su ruta de restauración.

Usa una Copia en Vivo Coordinada Cuando el Tiempo de Actividad sea Necesario

Para un plan en vivo, crea un volcado coherente y nativo de la base de datos y combínalo con una instantánea del almacenamiento o una captura de archivos cuyo momento y comportamiento de escritura se comprendan. Registra las horas de inicio y finalización, conserva las cargas nuevas hasta la siguiente copia de seguridad y evita copiar directamente el directorio activo de la base de datos.

Una conversación de la comunidad sobre cómo hacer copias de seguridad de Immich desde una implementación en ejecución muestra por qué los operadores distinguen la base de datos de los archivos cargados. Usa ese límite de la copia en vivo como contexto práctico, no como sustituto de una prueba de restauración.

Un diseño en vivo solo es válido si la herramienta de base de datos finaliza correctamente, la captura del sistema de archivos es atómica o su orden está documentado, y las cargas creadas durante la ventana quedan contabilizadas. De lo contrario, elige el método con el servicio detenido o aumenta la frecuencia de las copias para reducir la ventana de mantenimiento.

-15% OFF

ZimaBoard 2 - Mini servidor doméstico para tu gran idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Restaura de Forma Aislada y Toma la Decisión Final

Restaura la base de datos y los archivos multimedia seleccionados en un destino aislado usando los archivos de implementación guardados. Comprueba los usuarios, el número de recursos, muestras de los originales, álbumes, favoritos, búsquedas, bibliotecas externas y una carga nueva. Reinicia el destino y repite las comprobaciones críticas.

Elige copias con el servicio detenido cuando el tiempo de inactividad sea adecuado para el hogar y la simplicidad reduzca los errores. Elige copias en vivo coordinadas cuando la disponibilidad justifique herramientas adicionales y las pruebas de restauración repetidas demuestren que el proceso funciona. La decisión puede cambiar a medida que crezcan el tamaño de la biblioteca y la frecuencia de las cargas.

Detén el retiro de producción si la restauración presenta errores de archivos faltantes o registros huérfanos. Conserva ambos componentes de la copia de seguridad y los registros, y después concilia las marcas de tiempo y el alcance. Escala el problema indicando la versión de la base de datos, el método de volcado, el método del sistema de archivos, las horas de captura y el número de discrepancias; nunca elimines la última copia con el servicio detenido hasta que el método en vivo haya superado una prueba independiente.