Qui sauvegarde un serveur Immich, et comment tout récupérer ?

Le 19 octobre 2026, nous avons tout supprimé sur un serveur Immich de test, y compris le dépôt Borg local. Il ne restait que le dépôt Borg hors site et sa clé exportée. Une nouvelle installation a récupéré toute la photothèque à partir de ces deux éléments.

Sur un VPS DreamHost, c'est à vous d'effectuer ces sauvegardes. Le support de DreamHost est disponible 24 h/24, 7 j/7 pour le matériel, le réseau et la connectivité, et vous gérez le système d'exploitation, les logiciels et la configuration. Le centre d'aide de DreamHost indique que, comme vous avez le contrôle total d'un VPS, DreamHost ne peut ni accéder à vos données, ni les sauvegarder, ni les récupérer. Immich fait son propre dump de la base de données chaque nuit à 2 h. Mais ces dumps ne contiennent que les métadonnées, jamais les photos ni les vidéos. Sur un serveur Immich de DreamHost, l'outil immich-backup fait un dump de la base de données et vous rappelle que vous devez copier séparément le dossier de la photothèque hors du serveur. Si vous êtes encore en pleine migration depuis Google Photos, conservez les fichiers Takeout jusqu'à ce que la première sauvegarde décrite ci-dessous ait été effectuée. Si vous n'avez pas encore choisi d'application photo, commencez par notre comparatif d'Immich avec PhotoPrism, Ente et Nextcloud.

Ce que la sauvegarde doit contenir

Selon la documentation d'Immich, celui-ci stocke les chemins des fichiers et les métadonnées des utilisateurs dans la base de données et n'analyse pas le dossier de la photothèque : une sauvegarde doit donc contenir les deux, pris la même nuit. Les albums, les partages et les modifications se trouvent dans ces métadonnées. Si vous restaurez les photos sans la base de données, vous obtenez des fichiers en vrac, sans albums. Si vous restaurez la base de données sans les photos, Immich pointe vers des fichiers qui n'existent pas. Les tailles ci-dessous proviennent de la deuxième sauvegarde de notre photothèque de test.

En excluant les deux dossiers reconstructibles, nous avons économisé 214 Mo sur un dossier de 1,39 Go, au prix d'une reconstruction des miniatures après la restauration. Vos fichiers .env et docker-compose.yml se trouvent hors du dossier de téléversement : copiez-les une fois hors du serveur. Nous avons restauré sans les nôtres, à partir de copies neuves et avec un nouveau mot de passe de base de données, mais les vôtres vous éviteront de rechercher les chemins et la version.

Comment nous avons restauré un serveur effacé

Le serveur de test (qui n'était pas un serveur DreamHost) comptait deux comptes : un administrateur et un membre de la famille. À eux deux, ils avaient 401 photos et 4 vidéos, soit 1,06 Go, plus 5 photos dans la corbeille. Nous y avons mis ce qu'une famille regretterait de perdre. Certaines photos étaient en favoris, avec des descriptions et des notes en étoiles, d'autres étaient archivées, et d'autres encore avaient des dates et des lieux modifiés. Un album était partagé avec le second compte. Un lien de partage était protégé par un mot de passe et avait une date d'expiration.

Chaque sauvegarde suivait le script Borg d'Immich, avec Borg 1.4.0. Il faisait un dump de la base de données dans le dossier de téléversement, puis copiait ce dossier vers un dépôt chiffré hors de la VM, en excluant les miniatures et les vidéos transcodées. Après l'effacement, nous avons reconstruit le serveur dans cet ordre.

1. Réinstallez Immich à partir de ses propres fichiers

   Téléchargez des copies neuves de docker-compose.yml et example.env depuis le guide de démarrage rapide d'Immich. Dans .env, réglez IMMICH_VERSION sur la version que vous utilisiez, car la valeur par défaut v3 récupère la dernière version v3. Vous la trouverez dans le nom de chaque dump automatique. Nous avons aussi choisi un mot de passe de base de données différent de celui de l'ancien serveur, et docker compose pull a pris 16,4 secondes avec notre connexion.

2. Extrayez la dernière archive du dépôt hors site

   Exécutez borg extract pour l'archive la plus récente et déplacez les dossiers vers le nouvel emplacement de téléversement. La nôtre, de 1,15 Go, a été extraite en 4,8 secondes. Si vous avez exclu thumbs/ et encoded-video/ de votre sauvegarde, la page sur l'intégrité d'Immich indique de créer un fichier .immich vide dans chacun de ces dossiers, car Immich vérifie sa présence au démarrage.

3. Restaurez la base de données avant tout démarrage d'Immich

   La restauration en ligne de commande d'Immich nécessite une installation neuve où le serveur Immich n'a jamais tourné depuis la création de ses conteneurs : ne démarrez donc que Postgres. Voici les commandes d'Immich, avec le nom de base de données et l'utilisateur par défaut de example.env. Remplacez gunzip --stdout par cat quand le dump est en SQL brut, comme celui que produit le script d'Immich.

   bashCopier

   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

   Cette étape, attente de 10 secondes comprise, a pris 19,9 secondes.

4. Démarrez Immich

   Exécutez docker compose up -d. Notre serveur a répondu en 3,9 secondes, et l'ancien mot de passe administrateur a fonctionné. En comptant une demi-seconde pour créer le dossier et mettre les fichiers en place, les étapes de restauration ont pris 46 secondes au total.

5. Régénérez les miniatures avec l'option All

   La chronologie n'affichait aucune miniature, puisqu'elles n'étaient pas dans la sauvegarde. La page sur l'intégrité d'Immich suggère de lancer la tâche des miniatures pour les éléments manquants, et nous pensions que cela fonctionnerait. Mais sur notre serveur restauré, cette option n'a rien mis en file d'attente, car la base de données répertoriait encore le chemin de chaque miniature. Dans Administration, ouvrez les files de tâches et lancez plutôt la tâche des miniatures avec All. Elle a reconstruit 810 miniatures et aperçus en 100 secondes, soit environ 8 fichiers par seconde sur notre VM à 2 vCPU. Les vraies photos de téléphone sont plus lourdes : attendez-vous à un rythme plus lent pour une photothèque familiale.

Sur un vrai serveur, l'étape d'extraction dépend du débit de la connexion vers votre dépôt hors site : une grande photothèque prend donc bien plus de temps que la nôtre. Nous avons comparé le serveur restauré à un instantané pris avant l'effacement.

La restauration web d'Immich

Dans Immich v3, vous pouvez aussi restaurer depuis l'écran d'accueil d'un serveur neuf, et Immich recommande cette méthode web à la plupart des utilisateurs. Nous l'avons essayée sur une seconde installation effacée, après avoir recopié tout le dossier de téléversement, miniatures et backups/ compris, soit 1,39 Go au total.

L'écran d'accueil propose Getting Started ou Restore From Backup. Cliquez sur la seconde option, et Immich redémarre en mode maintenance. Notre navigateur de test sans interface est resté bloqué sur Server is restarting pendant 2 minutes : nous nous sommes donc connectés via le lien de connexion de maintenance que le serveur écrit dans son journal, affiché par docker logs immich_server. Un navigateur classique se rafraîchira peut-être tout seul, mais nous ne l'avons pas testé. Immich a ensuite vérifié que chaque dossier était accessible en lecture et en écriture, puis a listé les dumps trouvés dans backups/ avec leur date, leur version et leur taille.

Nous avons choisi le plus récent, un dump que le serveur restauré avait fait de lui-même à 2 h. Immich a d'abord enregistré un point de restauration de 9,5 Mo de la base de données actuelle. La page de connexion est revenue 20 secondes après notre confirmation, et toutes les vérifications du tableau ci-dessus ont de nouveau réussi. Cette fois, les miniatures se sont affichées sans reconstruction, car la copie du dossier les contenait.

Où placer les trois copies

Le README d'Immich vous conseille de toujours suivre une stratégie de sauvegarde 3-2-1 pour vos photos et vidéos.

Sur un serveur loué, le serveur lui-même est la première copie (il se trouve déjà loin de chez vous). La deuxième copie va sur un disque ou un NAS chez vous. La troisième va dans un dépôt Borg hors site. Un dépôt sur le disque du serveur lui-même ne compte pas : il consomme l'espace disque de votre offre et disparaît avec le serveur. Un second VPS DreamHost est bien hors du serveur, mais le centre d'aide de DreamHost indique que tous les VPS sont hébergés dans son centre de données US East, à Ashburn, en Virginie : il ne compte donc pas comme copie hors site.

BorgBase, que la page du script d'Immich cite pour les sauvegardes hors site, héberge des dépôts Borg. Quand nous avons consulté ses offres le 19 octobre, il proposait 10 Go gratuits, facturait 30 $ par an pour 250 Go ou 110 $ par an pour 1 To, sans frais de transfert. Les photos se compressent à peine : prévoyez un dépôt à peu près de la taille de vos originaux. Notre deuxième archive est passée de 1 150 Mo à 1 130 Mo.

Borg ne stocke que ce qui a changé. Notre première exécution a ajouté 852 Mo au dépôt hors site. Après l'ajout de 110 photos, la deuxième a ajouté 304,7 Mo (les nouvelles photos plus le dump de la base de données modifié). Le script complet s'est exécuté en 8,8 secondes. Une simple tâche de copie renverrait tout. Une synchronisation n'est pas non plus une sauvegarde : une photo supprimée sur le serveur disparaît aussi de la copie synchronisée, alors que Borg conserve les archives plus anciennes.

La première copie hors du serveur est la plus lente. Prenez une photothèque de 165 Go, à peu près le maximum que notre guide Google Photos prévoit pour Stack 16. Cela représente 1 320 gigabits (165 × 8), soit environ 44 minutes à un débit de 500 Mbit/s, par exemple. La copie à domicile se télécharge à la vitesse de téléchargement de votre connexion. Si vous restaurez un jour depuis cette copie, elle remonte à la vitesse d'envoi de votre connexion : avec 20 Mbit/s en envoi, cela prend environ 18 heures. La bande passante de l'hébergement VPS Immich est illimitée, sans frais de dépassement (dans le respect d'un usage raisonnable).

Configurez la sauvegarde nocturne

Il vous faut un accès SSH au serveur et un dépôt vide chez votre service hors site.

1. Installez Borg

   Sur Debian 13, sudo apt install borgbackup installe Borg 1.4.0, la version que nous avons testée, d'après la liste des paquets de Debian. Le guide de démarrage rapide de Borg détaille les commandes ci-dessous.

2. Permettez au serveur de se connecter au dépôt sans invite de saisie

   Cron ne peut pas saisir de mot de passe : ajoutez donc la clé publique SSH du serveur chez votre service hors site, et enregistrez la phrase secrète du dépôt dans un fichier lisible uniquement par root.

   bashCopier

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

3. Créez le dépôt avec chiffrement

   Le script d'Immich crée ses dépôts avec --encryption=none. Nous avons activé le chiffrement pour la copie hors site. Borg vous demande la phrase secrète.

   bashCopier

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

4. Exportez la clé et conservez-la hors du serveur

   Conservez la clé et la phrase secrète sur votre propre ordinateur ou dans votre gestionnaire de mots de passe, car vous ne pouvez pas ouvrir le dépôt sans elles. Lors de notre exercice, la clé exportée et le dépôt sont les seuls éléments à avoir survécu au serveur.

   bashCopier

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

5. Enregistrez le script de sauvegarde

   Voici le script d'Immich avec le chiffrement, un seul dépôt, sept archives quotidiennes conservées et l'option -t retirée de la commande de dump. Avec -t, notre dump contenait 242 266 retours chariot. Il s'est quand même restauré sans erreur, mais une tâche lancée par cron n'a pas de terminal avec lequel communiquer : nous avons donc retiré l'option. Le script d'Immich ne conserve que des archives hebdomadaires et mensuelles : une photo ajoutée puis supprimée la même semaine peut donc ne figurer dans aucune archive, d'où l'ajout de --keep-daily=7. Créez le dossier database-backup dans le dossier de téléversement une fois, avant la première exécution.

   bashCopier

   #!/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"

   Sur un serveur Immich de DreamHost, exécutez immich-backup à la place de la ligne docker exec et ajoutez le dump qu'il produit à la ligne borg create. Nous n'avons pas exécuté cet outil lors de notre exercice : vérifiez dans sa sortie où se trouvent le dump et le dossier de la photothèque, et faites pointer UPLOAD_LOCATION vers ces emplacements.

6. Ajoutez la copie à domicile

   Répétez les lignes create, prune et compact pour un second dépôt sur une machine à domicile, comme le fait le script d'Immich pour ses copies locale et distante. Le serveur doit pouvoir joindre cette machine en SSH, soit via une redirection de port sur votre box, soit via un tunnel réseau privé entre les deux. Le tunnel nous semble la solution la plus simple, car il ne nécessite pas d'adresse fixe à domicile.

7. Lancez-le une fois, puis planifiez-le avec cron

   Exécutez le script à la main et lisez sa sortie. Exécutez ensuite sudo crontab -e et ajoutez une ligne qui le lance chaque nuit, ici à 4 h, après le dump nocturne d'Immich.

   bashCopier

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

8. Soyez averti quand une sauvegarde nocturne échoue

   Ajoutez à la fin du script une ligne qui appelle une URL de signalement : vous serez ainsi prévenu les nuits où la sauvegarde ne s'est pas terminée. La page Uptime Kuma de DreamHost indique que ses moniteurs push permettent à vos propres cron jobs de se signaler. Après les deux premières nuits, borg list devrait afficher une nouvelle archive par nuit : la première fait à peu près la taille de votre bibliothèque, les suivantes sont bien plus petites.

Récupérez une photo depuis une archive plus ancienne

Si vous n'avez pas activé le modèle de stockage d'Immich (désactivé par défaut), vos photos dans upload/ portent des noms aléatoires générés par Immich. Pour en retrouver une, extrayez le dump SQL en texte brut de la même archive et cherchez-y le nom de fichier d'origine de la photo. Son chemin enregistré figure sur la même ligne. Extrayez ensuite ce seul fichier.

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

L'extraction d'un original depuis l'archive de notre première nuit a pris 0,5 seconde. Son SHA-256 correspondait à celui du fichier d'avant la sauvegarde. Importez-le de nouveau via l'application ou la page web d'Immich. Nous n'avons pas testé ce qu'une photo réimportée conserve : prévoyez donc de la rajouter vous-même à ses albums.

Sauvegardez avant chaque mise à jour d'Immich

Immich ne permet pas de revenir à une version antérieure, même au sein d'une version mineure : la sauvegarde que vous faites avant une mise à jour est donc votre seul moyen de revenir en arrière. La page Immich de DreamHost recommande d'exécuter immich-backup pour la base de données avant toute mise à jour. Notez aussi la version que vous utilisez. Immich l'inscrit dans le nom de chaque dump automatique, juste avant la version de Postgres, et une restauration sur une autre version tente automatiquement les migrations de la base de données.

Tous les quelques mois, faites une restauration de test. borg check a réussi sur notre dépôt en 1,8 seconde, mais seule une vraie restauration prouve qu'Immich peut repartir de ce dépôt. Le test qui compte, c'est la restauration ci-dessus sur un serveur jetable, suivie des contrôles d'intégrité d'Immich, que la v3 exécute chaque nuit à 3 h. Les miniatures manqueront pour tout ce qui se trouve dans la corbeille, ce qui est normal. Ouvrez ensuite un album partagé et quelques photos modifiées, et vérifiez qu'ils sont tels que vous les avez laissés.

Notre méthode de mesure

DreamHost a mené l'exercice les 19 et 20 octobre 2026 avec Immich v3.3.3. La VM de test tournait sous Ubuntu 24.04.4 en arm64 avec 2 vCPU et 7 922 Mo de mémoire, sous Colima sur un Mac à puce Apple. Ce n'est pas un serveur DreamHost, et elle a moitié moins de cœurs que Stack 16. Immich tournait à partir de son propre fichier compose et de example.env, modifiés uniquement pour les chemins, le fuseau horaire, la version épinglée et le mot de passe de la base de données. Borg 1.4.0 tournait dans un conteneur Debian 13. La bibliothèque se composait de JPEG synthétiques avec des dates et des coordonnées GPS dans leurs données EXIF, plus quatre courts clips vidéo en 1080p, répartis dans des comptes jetables. Chaque étape n'a été exécutée qu'une fois.

Ce test ne couvre ni l'image Immich de DreamHost ni son utilitaire immich-backup, ni un transfert sur un vrai réseau (le dépôt hors site était un dossier sur le même Mac), ni une bibliothèque de plusieurs centaines de gigaoctets, ni la restauration sur une version plus récente d'Immich d'une sauvegarde issue d'une version plus ancienne. Immich v3.3.4 est sortie le 20 octobre. Ses notes de version mentionnent des requêtes plus rapides sur les personnes et une traduction manquante, mais rien sur la sauvegarde ni la restauration. Nous n'avons pas refait l'exercice avec cette version.

FAQ sur la sauvegarde d'Immich