¿Quién hace las copias de seguridad de un servidor de Immich y cómo lo recuperas todo?

El 19 de octubre de 2026 borramos todo lo que había en un servidor Immich de prueba, incluido el repositorio local de Borg. Solo quedaron el repositorio de Borg externo y su clave exportada. Una instalación nueva recuperó toda la biblioteca a partir de esas dos cosas.

En un VPS de DreamHost, hacer esas copias de seguridad es cosa tuya. El soporte de DreamHost está disponible 24/7 para el hardware, la red y la conectividad, y tú gestionas el sistema operativo, el software y la configuración. El Centro de ayuda de DreamHost dice que, como controlas por completo un VPS, DreamHost no puede acceder a tus datos, hacer copias de seguridad de ellos ni recuperarlos. Immich hace su propio volcado de la base de datos cada noche a las 2:00 de la madrugada. Pero esos volcados solo contienen metadatos, nunca fotos ni vídeos. En un servidor Immich de DreamHost, la utilidad immich-backup vuelca la base de datos y te avisa de que debes copiar el directorio de la biblioteca fuera del servidor por separado. Si todavía estás mudándote desde Google Photos, conserva los archivos de Takeout hasta que se haya ejecutado la primera copia de seguridad que te explicamos más abajo. Si aún no has elegido una app de fotos, empieza por cómo se compara Immich con PhotoPrism, Ente y Nextcloud.

Qué debe incluir la copia de seguridad

La documentación de Immich dice que guarda las rutas de los archivos y los metadatos de usuario en la base de datos y que no escanea la carpeta de la biblioteca, así que una copia de seguridad necesita ambas cosas de la misma noche. Los álbumes, los elementos compartidos y las ediciones viven en esos metadatos. Si restauras las fotos sin la base de datos, obtienes archivos sueltos sin álbumes. Si restauras la base de datos sin las fotos, Immich apunta a archivos que no existen. Los tamaños de abajo corresponden a la segunda copia de seguridad de nuestra biblioteca de prueba.

Dejar fuera las dos carpetas regenerables nos ahorró 214 MB de una carpeta de 1,39 GB, y el precio fue regenerar las miniaturas tras la restauración. Tus archivos .env y docker-compose.yml están fuera de la carpeta de subidas, así que cópialos fuera del servidor una vez. Nosotros restauramos sin los nuestros, a partir de copias nuevas y con una contraseña nueva para la base de datos, pero los tuyos te ahorrarán tener que buscar las rutas y la versión.

Cómo restauramos un servidor borrado

El servidor de prueba (no un servidor de DreamHost) tenía dos cuentas: una de administrador y otra de un familiar. Entre las dos sumaban 401 fotos y 4 vídeos que ocupaban 1,06 GB, más otras 5 fotos en la papelera. Lo configuramos con lo que una familia echaría de menos si desapareciera. Algunas fotos eran favoritas, con descripciones y valoraciones con estrellas; otras estaban archivadas, y otras tenían fechas y ubicaciones editadas. Un álbum estaba compartido con la segunda cuenta. Un enlace para compartir tenía contraseña y fecha de caducidad.

Cada copia de seguridad siguió el script de Borg de Immich con Borg 1.4.0. Volcaba la base de datos en la carpeta de subidas y luego copiaba esa carpeta en un repositorio cifrado fuera de la VM, dejando fuera las miniaturas y el vídeo transcodificado. Tras el borrado, reconstruimos el servidor en este orden.

1. Reinstala Immich con sus propios archivos

   Descarga copias nuevas de docker-compose.yml y example.env desde la guía de inicio rápido de Immich. Establece IMMICH_VERSION en .env con la versión que tenías, porque el valor predeterminado v3 descarga la versión v3 más reciente. La encontrarás en el nombre de cada volcado automático. También pusimos una contraseña de base de datos distinta de la del servidor antiguo, y docker compose pull tardó 16,4 segundos con nuestra conexión.

2. Extrae el archivo más reciente del repositorio externo

   Ejecuta borg extract para el archivo de Borg más reciente y mueve las carpetas a la nueva ubicación de subidas. El nuestro, de 1,15 GB, se extrajo en 4,8 segundos. Si dejaste thumbs/ y encoded-video/ fuera de tu copia de seguridad, la página de integridad de Immich indica que crees un archivo .immich vacío en cada una de esas carpetas, porque Immich lo comprueba al arrancar.

3. Restaura la base de datos antes de que Immich arranque

   La restauración por línea de comandos de Immich necesita una instalación nueva en la que el servidor de Immich no se haya ejecutado nunca desde que se crearon sus contenedores, así que arranca solo Postgres. Estos son los comandos de Immich, con el nombre de base de datos y el usuario predeterminados de example.env. Cambia gunzip --stdout por cat cuando el volcado sea SQL plano, como lo genera el script de Immich.

   bashCopiar

   docker compose create
   docker start immich_postgres
   sleep 10
   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=immich --username=postgres --single-transaction --set ON_ERROR_STOP=on

   Este paso, incluida la espera de 10 segundos, tardó 19,9 segundos.

4. Inicia Immich

   Ejecuta docker compose up -d. El nuestro respondió en 3,9 segundos, y la antigua contraseña de administrador funcionó. Contando medio segundo para crear la carpeta y mover los archivos a su sitio, los pasos de la restauración sumaron 46 segundos.

5. Regenera las miniaturas con la opción All

   La línea de tiempo no mostraba miniaturas, porque no estaban en la copia de seguridad. La página de integridad de Immich sugiere ejecutar la tarea de miniaturas para los elementos que faltan, y esperábamos que funcionara. Pero en nuestro servidor restaurado esa opción no puso nada en cola, porque la base de datos seguía registrando todas las rutas de las miniaturas. En Administración, abre las colas de tareas y ejecuta en su lugar la tarea de miniaturas con All. Regeneró 810 miniaturas y vistas previas en 100 segundos, unos 8 archivos por segundo en nuestra VM de 2 vCPU. Las fotos reales de móvil son más grandes, así que cuenta con un ritmo más lento en una biblioteca familiar.

En un servidor real, el paso de extracción va a la velocidad de la conexión con tu repositorio externo, así que una biblioteca grande tarda mucho más que la nuestra. Comparamos el servidor restaurado con una instantánea tomada antes del borrado.

La restauración web de Immich

En Immich v3 también puedes restaurar desde la pantalla de bienvenida de un servidor nuevo, y Immich recomienda la vía web para la mayoría de la gente. La probamos en una segunda instalación borrada tras volver a copiar toda la carpeta de subidas, con las miniaturas y backups/ incluidos: 1,39 GB en total.

La pantalla de bienvenida ofrece Getting Started o Restore From Backup. Haz clic en la segunda e Immich se reinicia en modo de mantenimiento. Nuestro navegador de prueba sin interfaz se quedó en Server is restarting durante 2 minutos, así que iniciamos sesión con el enlace de acceso de mantenimiento que el servidor escribe en su registro, que puedes ver con docker logs immich_server. Es posible que un navegador normal se actualice solo, pero no lo probamos. Después, Immich comprobó que cada carpeta tenía permisos de lectura y escritura y mostró los volcados que encontró en backups/ con su fecha, versión y tamaño.

Elegimos el más reciente, un volcado que el servidor restaurado había hecho por su cuenta a las 2:00 de la madrugada. Immich guardó primero un punto de restauración de 9,5 MB de la base de datos actual. La página de inicio de sesión volvió 20 segundos después de confirmar, y todas las comprobaciones de la tabla anterior volvieron a superarse. Esta vez las miniaturas aparecieron sin regenerarlas, porque la copia de la carpeta las incluía.

Dónde van las tres copias

El README de Immich te dice que sigas siempre un plan de copia de seguridad 3-2-1 para tus fotos y vídeos.

En un servidor alquilado, el propio servidor es la primera copia (ya está lejos de tu casa). La segunda va en un disco o un NAS en casa. La tercera va a un repositorio de Borg externo. Un repositorio en el propio disco del servidor no cuenta, porque se come el disco de tu plan y desaparece con el servidor. Un segundo VPS de DreamHost está fuera del servidor, pero el Centro de ayuda de DreamHost dice que todos los VPS están alojados en su centro de datos US East de Ashburn (Virginia), así que no cuenta como copia externa.

BorgBase, que la página del script de Immich menciona para las copias externas, aloja repositorios de Borg. Cuando consultamos sus planes el 19 de octubre, ofrecía 10 GB gratis, cobraba 30 $ al año por 250 GB o 110 $ al año por 1 TB, y no cobraba por transferencia. Las fotos apenas se comprimen, así que necesitarás un repositorio de más o menos el tamaño de tus originales. Nuestro segundo archivo de Borg pasó de 1150 MB a 1130 MB.

Borg solo guarda lo que ha cambiado. Nuestra primera ejecución añadió 852 MB al repositorio externo. Después de añadir 110 fotos, la segunda añadió 304,7 MB (las fotos nuevas más el volcado de la base de datos, que había cambiado). El script completo se ejecutó en 8,8 segundos. Un trabajo de copia simple volvería a enviarlo todo. Una sincronización tampoco es una copia de seguridad, porque una foto borrada en el servidor desaparece también de la copia sincronizada, mientras que Borg conserva los archivos antiguos.

La primera copia fuera del servidor es la lenta. Pongamos una fototeca de 165 GB, más o menos el máximo que nuestra guía de Google Photos asigna a Stack 16. Son 1320 gigabits (165 x 8), es decir, unos 44 minutos a una velocidad de ejemplo de 500 Mbps. La copia en casa se descarga a la velocidad de descarga de tu conexión doméstica. Si alguna vez restauras desde esa copia en casa, los datos vuelven a subir a la velocidad de subida de tu conexión, y con 20 Mbps de subida son unas 18 horas. Immich VPS Hosting incluye ancho de banda sin límite, sin cargos por exceso (sujeto a una política de uso razonable).

Configura la copia de seguridad nocturna

Necesitarás un acceso SSH al servidor y un repositorio vacío en tu servicio externo.

1. Instala Borg

   En Debian 13, sudo apt install borgbackup instala Borg 1.4.0, la versión que probamos, según la lista de paquetes de Debian. La guía de inicio rápido de Borg explica con más detalle los comandos de abajo.

2. Deja que el servidor acceda al repositorio sin pedir contraseña

   Cron no puede escribir una contraseña, así que añade la clave pública SSH del servidor en tu servicio externo y guarda la frase de contraseña del repositorio en un archivo que solo pueda leer root.

   bashCopiar

   sudo sh -c 'umask 077; printf "%s" "YOUR-PASSPHRASE" > /root/.borg-passphrase'

3. Crea el repositorio con cifrado

   El script de Immich crea sus repositorios con --encryption=none. Nosotros activamos el cifrado para la copia externa. Borg te pedirá la frase de contraseña.

   bashCopiar

   borg init --encryption=repokey-blake2 ssh://USER@HOST/./immich-borg

4. Exporta la clave y guárdala fuera del servidor

   Guarda la clave y la frase de contraseña en tu propio ordenador o en tu gestor de contraseñas, porque sin ellas no puedes abrir el repositorio. En nuestra prueba, la clave exportada y el repositorio fueron lo único que sobrevivió al servidor.

   bashCopiar

   borg key export ssh://USER@HOST/./immich-borg immich-borg-key.txt

5. Guarda el script de copia de seguridad

   Este es el script de Immich con cifrado, un solo repositorio, siete archivos diarios conservados y sin el -t del comando de volcado. Con -t, nuestro volcado acumuló 242 266 retornos de carro. El volcado se restauró igualmente sin errores, pero una tarea que lanza cron no tiene terminal con la que comunicarse, así que quitamos la opción. El script de Immich solo conserva archivos semanales y mensuales, así que una foto añadida y borrada en la misma semana puede no quedar en ningún archivo; por eso añadimos --keep-daily=7. Crea la carpeta database-backup dentro de la carpeta de subidas una vez antes de la primera ejecución.

   bashCopiar

   #!/bin/sh
   set -eu
   UPLOAD_LOCATION="/path/to/immich/upload"   # UPLOAD_LOCATION from Immich's .env
   REPO="ssh://USER@HOST/./immich-borg"
   export BORG_PASSCOMMAND="cat /root/.borg-passphrase"
   
   # Database first
   docker exec immich_postgres pg_dump --clean --if-exists --dbname=immich --username=postgres \
     > "$UPLOAD_LOCATION/database-backup/immich-database.sql"
   
   # Then the files, without the rebuildable folders
   borg create "$REPO::{now}" "$UPLOAD_LOCATION" \
     --exclude "$UPLOAD_LOCATION/thumbs/" --exclude "$UPLOAD_LOCATION/encoded-video/"
   
   # Keep 7 daily, 4 weekly and 3 monthly archives
   borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=3 "$REPO"
   borg compact "$REPO"

   En un servidor Immich de DreamHost, ejecuta immich-backup en lugar de la línea docker exec y añade el volcado que genera a la línea borg create. No ejecutamos esta utilidad en nuestra prueba, así que revisa su salida para ver dónde quedan el volcado y la carpeta de la biblioteca, y haz que UPLOAD_LOCATION apunte ahí.

6. Añade la copia en casa

   Repite las líneas create, prune y compact para un segundo repositorio en un equipo de casa, como hace el script de Immich con sus copias local y remota. El servidor tiene que llegar a ese equipo por SSH, ya sea con una redirección de puertos en el router de casa o con un túnel de red privada entre los dos. Creemos que el túnel es la opción más sencilla, porque no necesita una dirección fija en casa.

7. Ejecútalo una vez y prográmalo con cron

   Ejecuta el script a mano y lee su salida. Luego ejecuta sudo crontab -e y añade una línea que lo lance cada noche, aquí a las 4:00, después del volcado nocturno de Immich.

   bashCopiar

   0 4 * * * /usr/local/bin/immich-borg.sh >> /var/log/immich-borg.log 2>&1

8. Recibe un aviso cuando falle una noche

   Añade al final del script una línea que llame a una URL de aviso, para que te enteres cuando una noche la copia no termine. La página de Uptime Kuma de DreamHost explica que sus monitores push permiten que tus propios cron jobs envíen ese aviso. Tras las dos primeras noches, borg list debería mostrar un archivo nuevo por noche: el primero, del tamaño aproximado de tu biblioteca, y los siguientes, mucho más pequeños.

Recupera una foto de un archivo anterior

Si no has activado la plantilla de almacenamiento de Immich (desactivada por defecto), tus fotos en upload/ tienen nombres aleatorios generados por Immich. Para encontrar una, extrae el volcado SQL en texto plano del mismo archivo y busca en él el nombre original de la foto. Su ruta guardada aparece en la misma línea. Después, extrae solo ese archivo.

borg extract "$REPO::ARCHIVE-NAME" path/inside/the/archive/photo.jpg

Extraer un original del archivo de nuestra primera noche tardó 0,5 segundos. Su SHA-256 coincidía con el del archivo anterior a la copia. Vuelve a subirlo desde la app o la web de Immich. No probamos qué conserva una foto que se sube de nuevo, así que cuenta con tener que añadirla tú a sus álbumes.

Haz una copia antes de cada actualización de Immich

Immich no admite volver a una versión anterior, ni siquiera dentro de una misma versión menor, así que la copia que hagas antes de actualizar es tu única forma de volver atrás. La página de Immich de DreamHost indica que ejecutes immich-backup para la base de datos antes de actualizar. Anota también la versión que usas. Immich la incluye en el nombre de cada volcado automático, justo antes de la versión de Postgres, y una restauración en otra versión intenta aplicar las migraciones de la base de datos automáticamente.

Cada pocos meses, haz una restauración de prueba. borg check salió bien en nuestro repositorio en 1,8 segundos, pero solo una restauración real demuestra que Immich vuelve a funcionar a partir de él. La prueba que cuenta es la restauración descrita arriba en un servidor provisional, seguida de las comprobaciones de integridad de Immich, que la v3 ejecuta cada noche a las 3:00. Verás miniaturas ausentes en todo lo que esté en la papelera, y es normal. Después, abre un álbum compartido y un par de fotos editadas y comprueba que están como las dejaste.

Cómo lo medimos

DreamHost hizo el simulacro el 19 y el 20 de octubre de 2026 con Immich v3.3.3. La VM de prueba ejecutaba Ubuntu 24.04.4 en arm64 con 2 vCPU y 7922 MB de memoria, bajo Colima en un Mac con Apple silicon. No es un servidor de DreamHost y tiene la mitad de núcleos que Stack 16. Immich se ejecutó con su propio archivo compose y example.env, cambiando solo las rutas, la zona horaria, la versión fijada y la contraseña de la base de datos. Borg 1.4.0 se ejecutó en un contenedor de Debian 13. La biblioteca eran JPEG sintéticos con fechas y GPS en sus datos EXIF, más cuatro clips de vídeo cortos en 1080p, en cuentas desechables. Cada paso se ejecutó una vez.

La prueba no cubre la imagen de Immich de DreamHost ni su herramienta immich-backup, una transferencia por una red real (el repositorio externo era una carpeta en el mismo Mac), una biblioteca de cientos de gigabytes ni una copia de una versión antigua de Immich restaurada en otra más reciente. Immich v3.3.4 salió el 20 de octubre. Sus notas de versión mencionan consultas de personas más rápidas y una traducción que faltaba, nada sobre copias de seguridad ni restauración. No hemos repetido el simulacro con ella.

Preguntas frecuentes sobre las copias de seguridad de Immich