Cómo recuperar una base de datos de Immich a partir de una copia de seguridad válida conocida

Una copia de seguridad válida de la base de datos de Immich solo es útil si la restauras en un estado controlado y demuestras que la base de datos recuperada sigue apuntando a los archivos multimedia que tu servidor realmente puede ver.

Trata la recuperación como una secuencia, no como un único comando de importación. Conserva primero la instancia fallida, identifica la versión de Immich y la fecha y hora de la copia de seguridad, inicia un destino de base de datos limpio y compatible, restaura sin permitir que la aplicación escriba primero en un esquema vacío y, después, valida las cuentas, los datos de la cronología, las rutas de los archivos multimedia y una escritura nueva. Si algún paso no está claro, detente antes de reemplazar la última copia recuperable.

Congela el estado fallido antes de restaurar nada

Detén las nuevas cargas y las escrituras en segundo plano de la instancia de Immich afectada antes de comenzar las tareas de recuperación. Guarda el archivo de Compose actual, los valores del entorno, las rutas montadas, las versiones de las imágenes, los registros recientes y el estado de la base de datos dañada si el almacenamiento lo permite. Una base de datos fallida aún puede contener pruebas que expliquen lo sucedido, y sobrescribirla elimina esas pruebas.

Identifica exactamente qué copia de seguridad pretendes utilizar. Registra su fecha y hora, cómo se creó, su tamaño y si alguna vez se restauró como prueba. Un volcado SQL producido por la base de datos es un recurso de recuperación diferente de una copia sin procesar del directorio de datos activo de PostgreSQL; no los trates como intercambiables.

Crea el destino de recuperación en un directorio independiente o en una pila aislada siempre que sea posible. El criterio para dar por terminada esta etapa es sencillo: el estado fallido original está conservado, la copia de seguridad elegida es de solo lectura y sabes con qué versión de la implementación y rutas de almacenamiento debe volver a conectarse la restauración.

Comprueba que la copia de seguridad realmente se puede restaurar

Inspecciona la copia de seguridad antes de reproducirla. Un volcado SQL comprimido debe descomprimirse correctamente y contener contenido reconocible de un volcado de PostgreSQL, no ser un archivo vacío generado por una canalización fallida. Si tienes sumas de comprobación o resultados de verificación del repositorio, compáralos ahora en lugar de descubrir la corrupción a mitad de la recuperación.

Un volcado de PostgreSQL es un recurso de recuperación más seguro que una copia improvisada de un directorio de base de datos activo, porque se crea mediante herramientas conscientes de la base de datos y puede reproducirse en un destino limpio. El método de copia de seguridad mediante volcado de la base de datos también mantiene la base de datos separada de la copia de los archivos multimedia, lo que facilita validar cada parte antes de la recuperación.

Confirma también que los archivos multimedia y la configuración correspondientes al periodo de la copia de seguridad siguen existiendo. Restaurar solo la base de datos puede recuperar usuarios, álbumes, metadatos y referencias a archivos, pero dejar todos los recursos inutilizables si faltan las rutas de la biblioteca referenciadas. Continúa solo cuando el volcado y el conjunto de archivos multimedia y configuración pertenezcan a un punto de recuperación conocido.

Inicia primero un destino de base de datos limpio y compatible

Adapta el método de restauración a la versión que creó la copia de seguridad. Las versiones actuales de Immich ofrecen la restauración de la base de datos mediante Administración > Mantenimiento y mediante el flujo de incorporación de una instalación nueva, mientras que las copias de seguridad antiguas pueden requerir instrucciones manuales específicas de cada versión; el flujo de restauración cambió en la versión 2.5.0.

Para un destino de recuperación nuevo, no permitas que Immich ejecute migraciones normales contra un esquema vacío antes de que la restauración de la base de datos esté lista. Si tu método de implementación inicia la aplicación junto con PostgreSQL, utiliza los controles de restauración adecuados para la versión, de modo que el servidor no cree un estado paralelo antes de la importación.

Si la base de datos no se vuelve saludable por sí sola, detente y resuelve primero ese problema. No sigas reproduciendo la misma copia de seguridad en un destino que se reinicia, se ha quedado sin espacio en disco o utiliza una disposición de almacenamiento incompatible. Un destino limpio y estable es un requisito previo, no una tarea secundaria de resolución de problemas.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Restaura el volcado una sola vez y detente ante el primer error

Restaura el volcado elegido en la base de datos preparada y captura toda la salida. Utiliza las herramientas de la base de datos y las opciones adecuadas al formato del volcado para que un error haga que la restauración falle de forma visible, en lugar de dejar un esquema importado parcialmente que aún se inicia.

Un conjunto de migración utilizable necesita los recursos, el estado de PostgreSQL y la configuración que los vuelve a conectar. Un conjunto completo de copias de seguridad de Immich incluye los recursos subidos, una copia de seguridad compatible de la base de datos y la configuración de la implementación, y utiliza pruebas de restauración para demostrar que el conjunto funciona. Mantén esas piezas juntas para que el destino pueda asociarse con un único punto de recuperación.

Después de una importación correcta, inicia la aplicación Immich y observa atentamente su primer arranque. Si la interfaz te pide crear un nuevo primer administrador en lugar de aceptar las cuentas existentes, detente: eso sugiere firmemente que la base de datos restaurada no es la que Immich está utilizando. No empieces a volver a subir fotos en ese estado vacío.

Valida el estado de la base de datos, las rutas de los archivos multimedia y una escritura nueva

Inicia sesión con una cuenta existente y revisa una muestra de la cronología en fechas antiguas y recientes. Abre varios originales, inspecciona álbumes o favoritos que sepas que existían y confirma que la aplicación puede resolver los archivos subyacentes, en lugar de mostrar únicamente filas de la base de datos.

El estado de la base de datos, los archivos de la aplicación, la configuración y las cargas deben coincidir en el momento de la restauración. Utiliza una copia de seguridad coherente del contenedor de la base de datos como modelo de aceptación, no simplemente el hecho de que PostgreSQL se inicie.

Por último, sube una foto desechable, espera a que se procese normalmente, confirma que sobrevive a un reinicio de Immich y a un reinicio del host y, después, elimínala desde la aplicación. Si las cuentas, los recursos antiguos y la nueva escritura funcionan con normalidad, crea una copia de seguridad nueva del estado recuperado antes de actualizar de versión. Si no, vuelve a las pruebas del fallo conservadas o a una copia de seguridad anterior conocida como válida, en lugar de agravar el daño.