Saltar al contenido principal

Copia de seguridad y restauración

Se recomienda una estrategia de copia de seguridad 3-2-1 para proteger tus datos. Deberías mantener copias de tus fotos/videos cargados, así como de la base de datos de Immich para una solución de respaldo completa. Esta página proporciona una visión general sobre cómo respaldar la base de datos y la ubicación de las imágenes y videos cargados por los usuarios. Un script bash de plantilla que se puede ejecutar como un trabajo cron está disponible aquí

peligro

Las instrucciones en esta página te muestran cómo preparar tu instancia de Immich para ser respaldada y qué archivos tomar como respaldo. Aún necesitas encargarte de usar una herramienta de respaldo real para realizar el respaldo tú mismo.

Base de datos

precaución

Immich guarda rutas de archivo en la base de datos, no escanea la carpeta de la biblioteca para actualizar la base de datos, por lo que los respaldos son cruciales.

información

Consulta la documentación oficial de postgres para obtener detalles sobre cómo respaldar y restaurar una base de datos postgres.

precaución

No se recomienda hacer directamente una copia de seguridad de la carpeta DB_DATA_LOCATION. Hacerlo mientras la base de datos está en ejecución puede generar un respaldo corrupto que no se pueda restaurar.

Volcados de base de datos automáticos

advertencia

Los volcados de base de datos automáticos se pueden utilizar para restaurar la base de datos en caso de daño en los archivos de la base de datos Postgres. No hay monitoreo para estos volcados y no se te notificará si fallan.

precaución

Los volcados de base de datos NO contienen imágenes ni videos, solo metadatos. Solo son utilizables con una copia de los otros archivos en UPLOAD_LOCATION como se describe a continuación.

Con fines de recuperación ante desastres, Immich creará automáticamente volcados de base de datos. Los volcados se almacenan en UPLOAD_LOCATION/backups. Asegúrate de realizar tu propio respaldo independiente de la base de datos junto con las carpetas de recursos como se indica a continuación. Puedes ajustar el horario y la cantidad de volcados de base de datos que se conservan en la configuración de administración. Por defecto, Immich conservará los últimos 14 volcados de base de datos y creará un nuevo volcado todos los días a las 2:00 AM.

Disparar un volcado

Puedes disparar un volcado de base de datos en la página de estado de trabajos de administración. Visita la página, abre el modal "Crear trabajo" en la parte superior derecha, selecciona "Crear volcado de base de datos" y haz clic en "Confirmar". Un trabajo se ejecutará y disparará un volcado; puedes verificar que esto funcionó correctamente comprobando los registros o la carpeta backups/. Estos volcados contarán para los últimos X volcados que se conservarán según tu configuración.

Restaurando

Esperamos simplificar la restauración en versiones futuras; por ahora puedes encontrar los volcados de base de datos en la carpeta UPLOAD_LOCATION/backups en tu host. Por favor, sigue los pasos de la siguiente sección para restaurar la base de datos.

Respaldo y restauración manual

Respaldar
docker exec -t immich_postgres pg_dumpall --clean --if-exists --username=<DB_USERNAME> | gzip > "/path/to/backup/dump.sql.gz"
Restaurar
docker compose down -v  # ¡PRECAUCIÓN! Elimina todos los datos de Immich para comenzar desde cero
## Descomenta la siguiente línea y reemplaza DB_DATA_LOCATION con tu ruta de Postgres para restablecer permanentemente la base de datos de Postgres
# rm -rf DB_DATA_LOCATION # ¡PRECAUCIÓN! Elimina todos los datos de Immich para comenzar desde cero
docker compose pull # Actualizar a la última versión de Immich (si lo deseas)
docker compose create # Crear contenedores Docker para las aplicaciones de Immich sin ejecutarlas
docker start immich_postgres # Iniciar el servidor de Postgres
sleep 10 # Esperar a que el servidor de Postgres se inicie
# Verifica el usuario de la base de datos si te desviaste del predeterminado
gunzip --stdout "/path/to/backup/dump.sql.gz" \
| sed "s/SELECT pg_catalog.set_config('search_path', '', false);/SELECT pg_catalog.set_config('search_path', 'public, pg_catalog', true);/g" \
| docker exec -i immich_postgres psql --dbname=postgres --username=<DB_USERNAME> # Restaurar respaldo
docker compose up -d # Iniciar el resto de las aplicaciones de Immich

Ten en cuenta que para que la restauración de la base de datos proceda correctamente, requiere una instalación completamente nueva (es decir, el servidor de Immich nunca ha funcionado desde que se crearon los contenedores Docker). Si la aplicación de Immich ha estado en funcionamiento, se pueden encontrar conflictos de Postgres al restaurar la base de datos (relación ya existente, restricciones de clave externa violadas, múltiples claves primarias, etc.), en cuyo caso debes borrar la carpeta DB_DATA_LOCATION para restablecer la base de datos.

consejo

Algunos métodos de despliegue dificultan iniciar la base de datos sin también iniciar el servidor. En estos casos, puedes configurar la variable de entorno DB_SKIP_MIGRATIONS=true antes de iniciar los servicios. Esto evitará que el servidor ejecute migraciones que interfieran con el proceso de restauración. Asegúrate de eliminar esta variable y reiniciar los servicios después de restaurar la base de datos.

Sistema de archivos

Immich almacena dos tipos de contenido en el sistema de archivos: (a) recursos originales, sin modificar (fotos y videos), y (b) contenido generado. Recomendamos respaldar todo el contenido de UPLOAD_LOCATION, pero solo el contenido original es crítico, que se almacena en las siguientes carpetas:

  1. UPLOAD_LOCATION/library
  2. UPLOAD_LOCATION/upload
  3. UPLOAD_LOCATION/profile

Si decides respaldar solo esas carpetas, necesitarás volver a ejecutar los trabajos de transcodificación y generación de miniaturas para todos los recursos después de restaurar desde un respaldo.

precaución

Si moviste algunas de estas carpetas a un dispositivo de almacenamiento diferente, como profile/, asegúrate de ajustar la ruta de respaldo para que coincida con tu configuración.

Tipos de recursos y ubicaciones de almacenamiento

Algunas ubicaciones de almacenamiento se ven afectadas por la plantilla de almacenamiento. Consulta a continuación para más detalles.

nota

La carpeta UPLOAD_LOCATION/library no se utiliza por defecto en máquinas nuevas que ejecutan la versión 1.92.0. Solo se usa si el administrador del sistema activó el motor de plantilla de almacenamiento, para más información, lee las notas de lanzamiento.

1. Carpetas específicas del usuario:

  • Cada usuario tiene una cadena única que lo representa.
  • Puedes encontrar tu ID de usuario en Configuración de cuenta -> Cuenta -> ID de usuario.

2. Tipos de recursos y ubicaciones de almacenamiento:

  • Recursos de origen:

    • Recursos originales cargados a través de la interfaz del navegador, móvil y CLI.
    • Almacenados en UPLOAD_LOCATION/upload/<userID>.
  • Imágenes de avatar:

    • Imágenes de perfil de usuario.
    • Almacenadas en UPLOAD_LOCATION/profile/<userID>.
  • Imágenes de miniaturas:

    • Imágenes de vista previa (miniaturas pequeñas y vistas previas grandes) para cada recurso y miniaturas de caras reconocidas.
    • Almacenadas en UPLOAD_LOCATION/thumbs/<userID>.
  • Recursos codificados:

    • Videos que han sido recodificados desde el original para una mayor compatibilidad. El original no se elimina.
    • Almacenados en UPLOAD_LOCATION/encoded-video/<userID>.
  • Postgres

    • La base de datos de Immich que contiene toda la información para permitir que el sistema funcione correctamente. Nota: Esta carpeta solo aparecerá para los usuarios que hayan realizado los cambios mencionados en v1.102.0 (un cambio opcional, no obligatorio) o que hayan comenzado con esta versión.
    • Almacenados en DB_DATA_LOCATION.
    peligro

    ¡Un respaldo de esta carpeta no constituye un respaldo de tu base de datos! Sigue las instrucciones enumeradas aquí para aprender cómo realizar un respaldo adecuado.

peligro

No toques los archivos dentro de estas carpetas bajo ninguna circunstancia excepto para realizar una copia de seguridad. Cambiar o eliminar un activo puede causar archivos no rastreados o faltantes. Puedes pensar en ello como una App-Que-No-Debe-Ser-Nombrada, el único acceso para ver, cambiar y eliminar activos es solo a través de la interfaz móvil o del navegador.

Orden de Copias de Seguridad

Una copia de seguridad de Immich debe contener tanto la base de datos como los archivos de activos. Al hacer estas copias, es posible que se desincronicen, lo que puede resultar en activos dañados después de la restauración. La mejor manera de manejar esto es detener el contenedor del servidor de Immich mientras realizas una copia de seguridad. Si no se realizan cambios, la copia de seguridad siempre estará sincronizada.

Si detener el contenedor no es una opción, entonces el orden recomendado es primero hacer una copia de seguridad de la base de datos y luego del sistema de archivos. De esta manera, el peor escenario es que haya archivos en el sistema de archivos que la base de datos no conozca. Si es necesario, estos pueden ser subidos (de nuevo) manualmente después de una restauración. Si la copia de seguridad se hace al revés, con el sistema de archivos primero y la base de datos después, es posible que la base de datos restaurada haga referencia a archivos que no están en la copia de seguridad del sistema de archivos, lo que resultaría en activos dañados.