Wie maakt de back-up van een Immich-server, en hoe krijg je alles terug?

Op 19 oktober 2026 hebben we alles op een Immich-testserver verwijderd, inclusief de lokale Borg-repository. Alleen de externe Borg-repository en de geëxporteerde sleutel bleven over. Met die twee haalde een nieuwe installatie de hele bibliotheek terug.

Op een VPS van DreamHost draai je die back-ups zelf. De support van DreamHost is 24/7 beschikbaar voor de hardware, het netwerk en de connectiviteit, en jij beheert het besturingssysteem, de software en de configuratie. Volgens het Help Center van DreamHost kan DreamHost je gegevens op een VPS niet inzien, back-uppen of herstellen, omdat jij er volledige controle over hebt. Immich maakt elke nacht om 2:00 uur zelf een databasedump. Maar die dumps bevatten alleen metadata, nooit foto's of video's. Op een Immich-server van DreamHost maakt de helper immich-backup een dump van de database en meldt hij dat je de bibliotheekmap apart van de server moet kopiëren. Ben je nog aan het overstappen van Google Photos, bewaar de Takeout-bestanden dan tot de eerste back-up hieronder heeft gedraaid. Heb je nog geen foto-app gekozen, begin dan met hoe Immich zich verhoudt tot PhotoPrism, Ente en Nextcloud.

Wat de back-up moet bevatten

Volgens de documentatie van Immich slaat het bestandspaden en gebruikersmetadata op in de database en scant het de bibliotheekmap niet. Een back-up heeft dus beide nodig, van dezelfde nacht. Albums, gedeelde items en bewerkingen zitten in die metadata. Herstel je de foto's zonder de database, dan krijg je losse bestanden zonder albums. Herstel je de database zonder de foto's, dan verwijst Immich naar bestanden die er niet zijn. De groottes hieronder komen van de tweede back-up van onze testbibliotheek.

Door de twee herbouwbare mappen weg te laten, bespaarden we 214 MB van een map van 1,39 GB. De prijs: na het herstel moesten de miniaturen opnieuw worden opgebouwd. Je .env en docker-compose.yml staan buiten de uploadmap, dus kopieer die één keer van de server. Wij herstelden zonder de onze, met nieuwe kopieën en een nieuw databasewachtwoord, maar met die van jou hoef je de paden en de versie niet op te zoeken.

Zo hebben we een gewiste server hersteld

De testserver (geen server van DreamHost) had twee accounts: een beheerder en een gezinslid. Samen hadden ze 401 foto's en 4 video's, goed voor 1,06 GB, plus nog 5 foto's in de prullenbak. We richtten hem in met de dingen die een gezin zou missen als ze verdwenen. Sommige foto's waren favorieten met beschrijvingen en sterbeoordelingen, sommige waren gearchiveerd en bij sommige waren de datum en locatie bewerkt. Eén album was gedeeld met het tweede account. Een deellink had een wachtwoord en een vervaldatum.

Elke back-up volgde het Borg-script van Immich met Borg 1.4.0. Het script maakte een dump van de database in de uploadmap en kopieerde die map daarna naar een versleutelde repository buiten de VM, zonder miniaturen en getranscodeerde video. Na het wissen bouwden we de server in deze volgorde opnieuw op.

1. Installeer Immich opnieuw met de eigen bestanden

   Download nieuwe kopieën van docker-compose.yml en example.env uit de snelstartgids van Immich. Zet IMMICH_VERSION in .env op de versie die je draaide, want de standaardwaarde v3 haalt de nieuwste v3-release op. Je vindt die versie in de naam van elke automatische dump. We stelden ook een ander databasewachtwoord in dan op de oude server, en docker compose pull duurde 16,4 seconden op onze verbinding.

2. Pak het nieuwste archief uit de externe repository uit

   Voer borg extract uit voor het nieuwste archief en verplaats de mappen naar de nieuwe uploadlocatie. Ons archief van 1,15 GB was in 4,8 seconden uitgepakt. Heb je thumbs/ en encoded-video/ uit je back-up weggelaten, dan zegt de integriteitspagina van Immich dat je in elk van die mappen een leeg bestand .immich moet aanmaken, omdat Immich daar bij het opstarten op controleert.

3. Herstel de database voordat Immich ooit start

   Herstellen via de opdrachtregel van Immich vereist een nieuwe installatie waarop de Immich-server nog nooit heeft gedraaid sinds de containers zijn aangemaakt, dus start alleen Postgres. Dit zijn de opdrachten van Immich, met de standaardnaam van de database en de standaardgebruiker uit example.env. Vervang gunzip --stdout door cat als de dump platte SQL is, zoals het script van Immich hem maakt.

   bashKopiëren

   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

   Deze stap duurde inclusief de wachttijd van 10 seconden 19,9 seconden.

4. Start Immich

   Voer docker compose up -d uit. Onze server reageerde na 3,9 seconden, en het oude beheerderswachtwoord werkte. Met een halve seconde voor het aanmaken van de map en het verplaatsen van de bestanden kwamen de herstelstappen samen op 46 seconden.

5. Bouw de miniaturen opnieuw op met de optie All

   De tijdlijn toonde geen miniaturen, omdat die niet in de back-up zaten. De integriteitspagina van Immich raadt aan de miniaturentaak voor ontbrekende items te draaien, en we verwachtten dat dat zou werken. Maar op onze herstelde server zette die optie niets in de wachtrij, omdat de database nog elk miniatuurpad bevatte. Open in Administration de taakwachtrijen en draai de miniaturentaak in plaats daarvan met All. Die bouwde 810 miniaturen en voorbeelden opnieuw op in 100 seconden, ongeveer 8 bestanden per seconde op onze VM met 2 vCPU's. Echte telefoonfoto's zijn groter, dus reken op een lager tempo bij een gezinsbibliotheek.

Op een echte server verloopt het uitpakken op de snelheid van de verbinding met je externe repository, dus een grote bibliotheek duurt veel langer dan de onze. We vergeleken de herstelde server met een momentopname van vóór het wissen.

Herstellen via de webinterface van Immich

In Immich v3 kun je ook herstellen vanaf het welkomstscherm van een nieuwe server, en Immich adviseert die webroute voor de meeste mensen. We probeerden het op een tweede gewiste installatie, nadat we de hele uploadmap hadden teruggezet, inclusief miniaturen en backups/, in totaal 1,39 GB.

Het welkomstscherm biedt Getting Started of Restore From Backup. Klik op de tweede optie en Immich herstart in onderhoudsmodus. Onze testbrowser zonder interface bleef 2 minuten hangen op Server is restarting, dus logden we in via de onderhoudslink die de server in zijn log zet en die docker logs immich_server laat zien. Een gewone browser ververst misschien vanzelf, maar dat hebben we niet getest. Daarna controleerde Immich of elke map lees- en schrijfbaar was en toonde het de dumps die het in backups/ vond, met datum, versie en grootte.

We kozen de nieuwste, een dump die de herstelde server zelf om 2:00 uur had gemaakt. Immich bewaarde eerst een herstelpunt van 9,5 MB van de huidige database. De inlogpagina kwam 20 seconden na onze bevestiging terug, en elke controle uit de tabel hierboven slaagde opnieuw. Deze keer verschenen de miniaturen zonder opnieuw opbouwen, omdat de gekopieerde map ze bevatte.

Waar de drie kopieën staan

De README van Immich zegt dat je voor je foto's en video's altijd een plan voor een 3-2-1-back-up moet volgen.

Op een gehuurde server is de server zelf kopie één (die staat al buiten je huis). Kopie twee komt op een schijf of NAS thuis. Kopie drie gaat naar een externe Borg-repository. Een repository op de eigen schijf van de server telt niet, want die vreet de schijfruimte van je abonnement op en is weg zodra de server weg is. Een tweede VPS van DreamHost staat wel buiten de server, maar volgens het Help Center van DreamHost wordt elke VPS gehost in het datacenter US East in Ashburn, Virginia, dus telt die niet als externe kopie.

BorgBase, dat de scriptpagina van Immich noemt voor externe back-ups, host Borg-repository's. Toen we op 19 oktober de abonnementen bekeken, bood het 10 GB gratis, kostte 250 GB $30 per jaar en 1 TB $110 per jaar, en waren er geen kosten voor dataverkeer. Foto's zijn nauwelijks te comprimeren, dus je hebt een repository nodig van ongeveer de grootte van je originelen. Ons tweede archief ging van 1.150 MB naar 1.130 MB.

Borg slaat alleen op wat er veranderd is. Onze eerste run voegde 852 MB toe aan de externe repository. Nadat we 110 foto's hadden toegevoegd, voegde de tweede run 304,7 MB toe (de nieuwe foto's plus de gewijzigde databasedump). Het hele script draaide in 8,8 seconden. Een gewone kopieertaak zou alles opnieuw versturen. Synchroniseren is ook geen back-up, want een foto die je op de server verwijdert, verdwijnt ook uit de gesynchroniseerde kopie, terwijl Borg oudere archieven bewaart.

De eerste kopie buiten de server is de trage. Neem een bibliotheek van 165 GB, ongeveer het maximum dat onze Google Photos-gids op Stack 16 zet. Dat is 1.320 gigabit (165 x 8), dus ongeveer 44 minuten bij een voorbeeldsnelheid van 500 Mbps. De kopie thuis komt binnen met de downloadsnelheid van je thuisverbinding. Herstel je ooit vanaf die kopie thuis, dan gaat alles terug met de uploadsnelheid van je thuisverbinding, en bij een upload van 20 Mbps is dat ongeveer 18 uur. De bandbreedte bij Immich VPS Hosting is ongelimiteerd, zonder kosten voor overschrijding (er geldt een fair-usebeleid).

Stel de nachtelijke back-up in

Je hebt een SSH-login op de server nodig en een lege repository bij je externe dienst.

1. Installeer Borg

   Op Debian 13 installeert sudo apt install borgbackup volgens de pakketlijst van Debian Borg 1.4.0, de versie die we hebben getest. De snelstartgids van Borg behandelt de opdrachten hieronder uitgebreider.

2. Laat de server zonder prompt inloggen op de repository

   Cron kan geen wachtwoord typen, dus voeg de openbare SSH-sleutel van de server toe bij je externe dienst en sla de wachtwoordzin van de repository op in een bestand dat alleen root kan lezen.

   bashKopiëren

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

3. Maak de repository aan met versleuteling

   Het script van Immich maakt zijn repository's aan met --encryption=none. Wij zetten versleuteling aan voor de externe kopie. Borg vraagt om de wachtwoordzin.

   bashKopiëren

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

4. Exporteer de sleutel en bewaar hem buiten de server

   Bewaar de sleutel en de wachtwoordzin op je eigen computer of in je wachtwoordmanager, want zonder die twee krijg je de repository niet open. In onze test waren de geëxporteerde sleutel en de repository de enige dingen die de server overleefden.

   bashKopiëren

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

5. Sla het back-upscript op

   Dit is het script van Immich met versleuteling, één repository, zeven bewaarde dagelijkse archieven en zonder -t in de dumpopdracht. Met -t kreeg onze dump 242.266 wagenteruglooptekens (CR) mee. De dump liet zich nog steeds zonder fouten herstellen, maar een taak die vanuit cron draait heeft geen terminal om mee te praten, dus lieten we de vlag weg. Het script van Immich bewaart alleen wekelijkse en maandelijkse archieven, waardoor een foto die je in dezelfde week toevoegt en verwijdert uit elk archief kan verdwijnen. Daarom hebben we --keep-daily=7 toegevoegd. Maak vóór de eerste run één keer de map database-backup aan in de uploadmap.

   bashKopiëren

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

   Op een Immich-server van DreamHost voer je immich-backup uit in plaats van de regel met docker exec en voeg je de dump die het schrijft toe aan de regel met borg create. We hebben de helper in onze test niet gedraaid, dus controleer in de uitvoer waar de dump en de bibliotheekmap staan en laat UPLOAD_LOCATION daarnaar verwijzen.

6. Voeg de kopie thuis toe

   Herhaal de regels met create, prune en compact voor een tweede repository op een computer thuis, zoals het script van Immich zijn lokale en externe kopieën afhandelt. De server moet die computer via SSH kunnen bereiken, via een doorgestuurde poort op je thuisrouter of via een privé-netwerktunnel tussen de twee. Wij vinden de tunnel het makkelijkst, omdat je er geen vast thuisadres voor nodig hebt.

7. Voer het één keer uit en plan het daarna in met cron

   Voer het script met de hand uit en lees de uitvoer. Voer daarna sudo crontab -e uit en voeg een regel toe die het elke nacht draait, hier om 4:00 uur, na de eigen nachtelijke dump van Immich.

   bashKopiëren

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

8. Krijg een melding als een nacht mislukt

   Voeg aan het script een laatste regel toe die een check-in-URL aanroept, zodat je het hoort als een back-up 's nachts niet is afgerond. Volgens de Uptime Kuma-pagina van DreamHost kunnen je eigen cron jobs via push-monitors inchecken. Na de eerste twee nachten zou borg list voor elke nacht een nieuw archief moeten tonen. De eerste keer is dat ongeveer zo groot als je bibliotheek, daarna veel kleiner.

Haal één foto terug uit een ouder archief

Als je het opslagsjabloon van Immich niet hebt ingeschakeld (standaard uit), staan je foto's in upload/ onder willekeurige namen die Immich heeft gegenereerd. Om er een te vinden, pak je de platte SQL-dump uit hetzelfde archief uit en zoek je daarin naar de oorspronkelijke bestandsnaam van de foto. Het opgeslagen pad staat op dezelfde regel. Haal daarna alleen dat ene bestand eruit.

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

Eén origineel uitpakken uit het archief van onze eerste nacht duurde 0,5 seconde. De SHA-256 kwam overeen met die van het bestand van vóór de back-up. Upload het opnieuw via de Immich-app of de webpagina. We hebben niet getest wat een opnieuw geüploade foto behoudt, dus reken erop dat je hem zelf weer aan de juiste albums toevoegt.

Maak een back-up vóór elke Immich-update

Immich ondersteunt geen downgrades, zelfs niet binnen een minor-versie, dus de back-up die je vóór een update maakt, is je enige weg terug. Volgens de Immich-pagina van DreamHost voer je vóór het updaten immich-backup uit voor de database. Noteer ook welke versie je draait. Immich zet die in de naam van elke automatische dump, vlak vóór de Postgres-versie, en bij een herstel naar een andere versie probeert Immich de databasemigraties automatisch uit te voeren.

Voer om de paar maanden een testherstel uit. borg check slaagde op onze repository in 1,8 seconde, maar alleen een echt herstel laat zien dat Immich er ook echt mee terugkomt. De test die telt, is het herstel hierboven op een testserver, gevolgd door de integriteitscontroles van Immich, die v3 elke nacht om 3:00 uitvoert. Je ziet ontbrekende miniaturen voor alles in de prullenbak, en dat is normaal. Open daarna een gedeeld album en een paar bewerkte foto's en controleer of ze eruitzien zoals je ze achterliet.

Hoe we hebben gemeten

DreamHost voerde deze oefening uit op 19 en 20 oktober 2026, met Immich v3.3.3. De test-VM draaide Ubuntu 24.04.4 op arm64 met 2 vCPU's en 7.922 MB geheugen, onder Colima op een Mac met Apple silicon. Dat is geen DreamHost-server, en hij heeft half zoveel cores als Stack 16. Immich draaide vanuit zijn eigen compose-bestand en example.env, alleen aangepast voor paden, tijdzone, de vastgezette versie en het databasewachtwoord. Borg 1.4.0 draaide in een Debian 13-container. De bibliotheek bestond uit synthetische JPEG's met datums en gps-gegevens in de EXIF-data, plus vier korte 1080p-videoclips, in wegwerpaccounts. Elke stap is één keer uitgevoerd.

De test omvat niet de Immich-image van DreamHost of de bijbehorende helper immich-backup, geen overdracht via een echt netwerk (de externe repository was een map op dezelfde Mac), geen bibliotheek van honderden gigabytes en geen back-up van een oudere Immich-versie die op een nieuwere is teruggezet. Immich v3.3.4 verscheen op 20 oktober. De releasenotes noemen snellere zoekopdrachten naar personen en een ontbrekende vertaling, maar niets over back-up of herstel. Op die versie hebben we de oefening niet uitgevoerd.

Veelgestelde vragen over back-ups van Immich