Immich back-up en restore handleiding voor VPS

Waaruit een Immich-back-up moet bestaan

Een Immich-back-up bestaat uit drie onderdelen die op exact hetzelfde moment zijn vastgelegd. De originelen onder UPLOAD_LOCATION. Een SQL-dump van de Postgres-database. De .env en docker-compose.yml die de stack beschrijven. Herstellen betekent dat u die dump in een verse database inlaadt terwijl de Immich-server is gestopt, en de rest van de stack pas daarna opstart. Hanteert u de verkeerde volgorde, dan eindigt u met een werkende Immich die een lege tijdlijn toont bovenop een volle schijf.

Deze splitsing is essentieel omdat Immich de status op twee plekken bijhoudt die niet van elkaar op de hoogte zijn. Postgres bevat elk album, elke gezichtscluster, elke gedeelde link, elk gebruikersaccount en elke API-sleutel, evenals het opgeslagen pad van elk asset. Het bestandssysteem bevat de pixels. Herstelt u de bestanden zonder de database, dan toont Immich niets. Herstelt u de database zonder de bestanden, dan opent elk asset als een defecte afbeelding.

De commando's in deze handleiding zijn geschreven voor Immich v3.1.0, de versie die begin augustus 2026 actueel was. Het project brengt snel updates uit en de gedocumenteerde back-upprocedure is al meermaals gewijzigd; controleer daarom welke versie u daadwerkelijk draait voordat u commando's kopieert. Als de stack nog niet actief is, begin dan bij de installatiehandleiding van Immich en keer daarna terug.

Weet waar uw paden naar verwijzen

Twee variabelen in .env bepalen alles op deze pagina. UPLOAD_LOCATION is de bovenliggende map waarin Immich alle media opslaat. DB_DATA_LOCATION is de datamap van Postgres.

De standaard example.env stelt UPLOAD_LOCATION=./library in, wat een verwarrende standaardinstelling is, omdat Immich vervolgens een map genaamd library binnen die map aanmaakt. Uw originelen komen terecht in ./library/library. Stel in plaats daarvan een absoluut pad in, zodat een back-upscript nooit afhankelijk is van de map van waaruit u het uitvoert.

UPLOAD_LOCATION=/srv/immich/data
DB_DATA_LOCATION=/srv/immich/postgres
DB_USERNAME=postgres
DB_DATABASE_NAME=immich
IMMICH_VERSION=v3.1.0

Binnen UPLOAD_LOCATION maakt Immich verschillende mappen aan. Drie daarvan bevatten gegevens die door geen enkele taak kunnen worden herbouwd:

• library: de originelen, ingedeeld volgens uw opslagsjabloon
• upload: originelen die nog niet naar de sjabloonindeling zijn verplaatst, plus uploads die nog in behandeling zijn
• profile: profielfoto's van gebruikers

Raakt u library kwijt, dan is de foto weg. Immich bewaart nergens een tweede kopie van een origineel.

Waarom het kopiëren van de Postgres datamap geen back-up is

DB_DATA_LOCATION lijkt een eenvoudig doelwit. Het is een map, rsync kopieert deze, en de kopie wordt zonder foutmelding voltooid. Toch is dit geen back-up, om twee redenen die u kunt zien mislukken.

De eerste reden is 'tearing'. Postgres schrijft elke wijziging eerst naar de write-ahead log (WAL) en past deze pas later toe op de tabelbestanden tijdens een checkpoint. Op elk willekeurig moment bevinden de bestanden op de schijf zich dus in een tussenfase. Een doorlopende kopie die vier minuten duurt, leest het eerste bestand om 02:00 en het laatste om 02:04. Deze twee bestanden behoren niet tot dezelfde transactie. Wanneer u Postgres op het resultaat start, weigert het programma bij het opstarten met PANIC: could not locate a valid checkpoint record, of het start en crasht vervolgens bij de eerste leesactie van een beschadigde pagina met invalid page in block 1234 of relation base/16384/.... Geen van beide is herstelbaar vanuit die kopie.

De tweede reden blijft bestaan, zelfs als u eerst alles stopt. Een Postgres datamap is gebonden aan de exacte binaries die deze hebben geschreven. Immich koppelt zijn database-image aan een digest, momenteel ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0. Dat is Postgres 14 met twee gecompileerde vector-search extensies. Een datamap die door die build is geschreven, opent niet onder een andere major-versie van Postgres, en opent niet onder een build met andere extensieversies. Uw herstelhost moet de image exact reproduceren. Een SQL-dump heeft hier geen last van: het is tekst, en elke compatibele server kan deze opnieuw afspelen.

pg_dump omzeilt het 'tearing'-probleem volledig. Het leest de gehele database binnen één enkele MVCC (multi-version concurrency control) snapshot. Hierdoor ziet het de database exact zoals deze op één moment was, terwijl andere schrijfacties ondertussen doorgaan. Daarom hoeft u Postgres niet te stoppen om een dump te maken.

Wat u kunt weglaten uit de back-up

Deze bestanden worden opnieuw gegenereerd, dus u kunt ze overslaan:

• thumbs: voorbeelden en miniatuurafbeeldingen
• encoded-video: getranscodeerde video
• DB_DATA_LOCATION: opnieuw opgebouwd vanuit de dump
• het model-cache Docker-volume: machine learning-modellen, deze worden op verzoek opnieuw gedownload

Het overslaan hiervan is een afweging, geen gratis winst. Het opnieuw opbouwen van miniaturen en transcodes voor een grote bibliotheek kost uren aan CPU-tijd op een kleine VPS, en de tijdlijn toont gedurende die tijd grijze tijdelijke aanduidingen. U start deze processen opnieuw via Administration > Jobs, waarbij "Generate Thumbnails" en "Transcode Videos" worden ingesteld om te draaien voor ontbrekende assets. Als uw back-updoel voldoende ruimte heeft, neem ze dan op om het wachten te voorkomen. Als u bijna aan uw opslaglimiet zit, laat ze dan weg en houd rekening met de tijd voor het opnieuw opbouwen. Het bepalen van de grootte van een Immich-bibliotheek beschrijft hoe groot deze mappen worden in verhouding tot de originelen.

Er is nog één map die het vermelden waard is. UPLOAD_LOCATION/backups bevat de automatische database-dumps van Immich, die dagelijks om 02:00 worden geschreven, waarbij de laatste 14 worden bewaard; dit is configureerbaar onder Administration > Settings > Backup. Ze kosten u niets en zijn zeer nuttig. Ze bevinden zich echter op dezelfde schijf als de bibliotheek die ze beschermen, dus ze helpen bij een mislukte migratie, maar niet bij een defecte server. Maak hoe dan ook uw eigen dump, omdat een dump die u zelf activeert op hetzelfde moment plaatsvindt als de bestandssnapshot die erbij hoort.

Maak de database-dump

docker exec -t immich_postgres pg_dump --clean --if-exists \
  --dbname=immich --username=postgres \
  | gzip > /srv/immich/backup/immich.sql.gz

Vervang immich en postgres door uw eigen DB_DATABASE_NAME en DB_USERNAME als u deze heeft gewijzigd. --clean --if-exists plaatst een DROP ... IF EXISTS voor elk CREATE, zodat de dump wordt ingelezen in een database die al objecten bevat in plaats van te stoppen bij het eerste object.

Nu het detail dat back-upscripts ongemerkt onbruikbaar maakt. Dat commando is een pipeline, en een shell rapporteert de exit-status van het laatste commando in een pipeline. Als pg_dump faalt, door een onjuist wachtwoord of een container die niet draait, ontvangt gzip een lege stream, schrijft een volledig geldig gzip-bestand en sluit af met status 0. Uw script logt een succesvolle actie en u heeft een back-up van 20 bytes. Plaats pipefail bovenaan elk back-upscript:

#!/usr/bin/env bash
set -euo pipefail

Controleer vervolgens het resultaat in plaats van te vertrouwen op de exit-code:

ls -lh /srv/immich/backup/immich.sql.gz
gunzip -c /srv/immich/backup/immich.sql.gz | head -n 3

De eerste regel van een gezonde dump bevat -- PostgreSQL database dump. Een bestand van enkele honderden bytes is een mislukte dump, ongeacht wat het script rapporteerde.

Leg vast welke build de dump heeft geschreven, naast de dump zelf:

docker inspect --format '{{.Config.Image}}' immich_server > /srv/immich/backup/immich-version.txt

Vertrouw hiervoor niet op .env. De standaard set bestanden bevat IMMICH_VERSION=v3, een variabele tag die elke 3.x release volgt; dit vertelt u dus niets over welke build de dump daadwerkelijk heeft geschreven. Pin ook de exacte tag vast in .env.

Pauzeer de server en maak een snapshot met restic

Bestanden onder UPLOAD_LOCATION zijn niet onveranderlijk terwijl Immich actief is. De server schrijft nieuwe uploads en de opslag-template-taak verplaatst bestanden tussen mappen. Als een back-uptool een bestand leest terwijl het nog wordt geschreven, slaat deze de bytes op alsof het het volledige bestand is, zonder dat er een foutmelding volgt. Stop de servercontainer voor de duur van de uitvoering:

docker stop immich_server

Laat immich_postgres draaien, omdat de dump dit vereist. De webinterface en de mobiele app zijn offline totdat u de server opnieuw start, wat om 03:00 uur op een thuisomgeving meestal geen probleem is.

restic is hier geschikt omdat het ontdubbelt en versleutelt voordat er gegevens de server verlaten. Wijs het naar een repository die zich niet op deze server bevindt:

export RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/immich
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic init

Object storage werkt op dezelfde manier en is de betere oplossing als u de kopie volledig buiten uw eigen hardware wilt opslaan:

export RESTIC_REPOSITORY=s3:https://s3.example.com/immich-backup
export AWS_ACCESS_KEY_ID=your-access-key
export AWS_SECRET_ACCESS_KEY=your-secret-key
restic init

Dat eindpunt kan een door uzelf beheerde MinIO bucket op een tweede machine zijn, of elke S3-compatibele provider. Een repository op dezelfde schijf als de bibliotheek beschermt u tegen een per ongeluk verwijderd bestand, maar tegen niets anders.

Maak vervolgens de snapshot en specificeer precies wat belangrijk is:

restic backup \
  /srv/immich/backup/immich.sql.gz \
  /srv/immich/backup/immich-version.txt \
  /srv/immich/data/library \
  /srv/immich/data/upload \
  /srv/immich/data/profile \
  /srv/immich/.env \
  /srv/immich/docker-compose.yml
docker start immich_server

restic leest bij elke uitvoering de volledige boomstructuur, maar uploadt alleen blokken die het nog niet eerder heeft gezien. De eerste snapshot verplaatst dus uw volledige bibliotheek en elke daaropvolgende snapshot verplaatst alleen de nieuwe foto's van de dag.

Retentie, en de sleutels die elders moeten worden bewaard

restic forget --prune --keep-daily 7 --keep-weekly 5 --keep-monthly 12

forget verwijdert snapshots uit de index. --prune is het onderdeel dat de data verwijdert waarnaar deze snapshots als laatste verwezen. Voer forget uit zonder --prune en uw opslagkosten zullen nooit dalen.

Structuurcontroles zijn goedkoop, voer er daarom wekelijks een uit:

restic check

Dit verifieert of de metadata van de repository consistent is. Het leest uw data niet. Controleer één keer per maand een steekproef door deze opnieuw te lezen en te vergelijken met de opgeslagen hashes:

restic check --read-data-subset=5%

Dit is de enige controle die stille corruptie op de opslagbackend detecteert, omdat het daadwerkelijke blokken downloadt en de checksums opnieuw berekent. Een volledige --read-data op een fotobibliotheek betekent het downloaden van de volledige repository, wat bij objectopslag met datalimieten geld kost. Daarom voeren mensen in de praktijk een roterende subset uit.

Nu het onderdeel dat mensen vaak overslaan. Een restic repository-wachtwoord is niet herstelbaar. Er is geen reset mogelijk en er is geen ondersteuningsteam voor. Als de enige kopie zich in /root/.restic-password op de server bevindt die u probeert te herstellen, zijn uw back-ups versleutelde ruis. Hetzelfde geldt voor de toegangssleutel van de objectopslag en voor DB_PASSWORD van .env. Bewaar ze allemaal op een plek die niet afhankelijk is van het functioneren van deze machine: geprint in een lade, of in een wachtwoordmanager die op andere hardware draait. Als die manager ook zelf gehost wordt, vereist deze dezelfde behandeling, en het back-uppen van Vaultwarden is een taak op zich.

Immich herstellen in de juiste volgorde

De volgorde van herstel bepaalt of een goede back-up resulteert in een werkende tijdlijn of een lege database. Volg deze reeks op de nieuwe host.

Herstel eerst de configuratie. Deze vertelt u welke versie u moet draaien en waar de paden naar verwijzen.

restic restore latest --target /restore \
  --include /srv/immich/.env \
  --include /srv/immich/docker-compose.yml \
  --include /srv/immich/backup

Zet de versie vast voordat u iets start. Lees immich-version.txt, stel IMMICH_VERSION in .env in op die exacte tag en laat de nieuwste release voorlopig met rust. Immich ondersteunt geen downgrades, zelfs niet tussen patch-releases. Als een nieuwere server opstart met een oudere dump en de migraties uitvoert, is er geen weg terug.

Herstel de media.

restic restore latest --target /restore --include /srv/immich/data

Verplaats vervolgens library, upload en profile zodat ze direct in de map staan waar UPLOAD_LOCATION op deze host naar verwijst. Het hostpad zelf kan veranderen, omdat het compose-bestand die map koppelt aan een vast pad binnen de container. De interne structuur mag echter niet wijzigen.

Start de database afzonderlijk. Laat DB_DATA_LOCATION leeg zodat Postgres een nieuwe cluster initialiseert.

cd /srv/immich
docker compose pull
docker compose create
docker start immich_postgres
docker exec immich_postgres pg_isready --username=postgres

pg_isready geeft accepting connections weer zodra de eerste configuratie is voltooid; dit duurt enkele seconden. docker compose create bouwt elke container zonder deze te starten, en dat is precies het doel van deze stap: de Immich-server mag nog niet draaien. Een server die opstart met een lege database voert migraties uit, maakt een nieuw schema aan en vraagt u om een nieuw beheerdersaccount. U zou dan een dump terugzetten terwijl de applicatie al draait.

Zet de dump terug.

gunzip --stdout /restore/srv/immich/backup/immich.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

Twee onderdelen hiervan zijn essentieel. De sed is nodig omdat pg_dump als veiligheidsmaatregel een lege search_path in de uitvoer schrijft, zodat niet-gekwalificeerde namen in de dump niet naar een onverwacht schema verwijzen. De vector-zoektypen van Immich bevinden zich in public. Met een leeg zoekpad bereikt het herstel de eerste kolom die is gedeclareerd met een vector-type en stopt psql met ERROR: type "vector" does not exist. Door public terug op het pad te plaatsen, wordt dit opgelost.

--single-transaction --set ON_ERROR_STOP=on verpakt het volledige herstel in één transactie die bij de eerste fout afbreekt. U krijgt ofwel een volledige database, of een onaangeroerde. Zonder deze optie laat een fout halverwege een database achter die wel opstart en uw inloggegevens accepteert, maar waarbij een onbekend aantal albums ontbreekt; iets wat u pas weken later ontdekt.

Start nu alles.

docker compose up -d
docker compose ps
docker logs -f immich_server

Wacht op een opstartregel zoals Immich Server is listening on, open vervolgens poort 2283 en log in met uw oude inloggegevens, aangezien de gebruikersaccounts met de dump zijn teruggezet. Als de inlogpagina in plaats daarvan vraagt om het eerste beheerdersaccount aan te maken, is de database niet hersteld. Stop en lees de psql-uitvoer opnieuw.

Een waarschuwing over de officiële herstelinstructies, die beginnen met docker compose down -v. De -v verwijdert benoemde volumes (named volumes). In het standaard compose-bestand zijn UPLOAD_LOCATION en DB_DATA_LOCATION bind mounts, dus die blijven behouden. Als u een van beide heeft gewijzigd in een benoemd volume, verwijdert dat commando uw foto's. Lees uw compose-bestand voordat u het commando uitvoert.

Waarom de tijdlijn leeg is na een herstel

De tijdlijn wordt opgebouwd uit database-records. Immich doorzoekt upload/ nooit tijdens het opstarten om foto's opnieuw te ontdekken, omdat een bestand zonder record geen eigenaar, datum of album heeft. Het meest voorkomende probleem bij een foutief herstel is dat de bestanden wel aanwezig zijn, maar de database ontbreekt. Immich start op, maakt een leeg schema aan en presenteert een werkende instantie zonder inhoud, terwijl de schijf vol staat met uw foto's. Er is niets verloren gegaan. Er is echter ook niets zichtbaar. De oplossing is om de dump opnieuw in te laden terwijl de server is gestopt, precies zoals hierboven beschreven.

De tweede variant is minder opvallend. De database wordt hersteld, de tijdlijn vult zich met items, maar elk asset kan niet worden geopend. Dit betekent dat de records verwijzen naar bestanden die de container niet kan zien. Dit komt meestal doordat library, upload en profile zich één niveau te diep bevinden na een restic restore --target /restore die niet naar de juiste locatie is verplaatst. Controleer dit vanuit de container in plaats van te gokken:

docker exec immich_server ls /data

Het standaard compose-bestand koppelt UPLOAD_LOCATION aan /data, dus die lijst zou library, upload en profile moeten tonen. Als de map leeg is of als er een verdwaalde srv map staat, wijst uw bind mount naar het verkeerde niveau en zijn de records in orde.

Versieovereenkomst tussen back-up en restore

Immich brengt regelmatig updates uit en het schema wijzigt hierbij mee. Een dump bevat daarom het schema van de server die de back-up heeft gemaakt.

Het terugzetten van een oudere dump op een nieuwere server werkt meestal, omdat de server bij het opstarten de openstaande migraties uitvoert en het schema bijwerkt. Dit pad wordt getest gedurende de release-reeks. Het in één stap overbruggen van meerdere grote versies leidt tot problemen; het project bewaart ingrijpende wijzigingen voor grote releases en documenteert deze in de changelog.

Het terugzetten van een nieuwere dump op een oudere server werkt in het geheel niet. De dump bevat tabellen en kolommen die de oudere code niet herkent. Immich geeft aan dat downgraden niet wordt ondersteund, zelfs niet tussen patch-releases. Er is geen rollback-commando beschikbaar.

Een veilige restore is daarom een saai proces. Draai exact de versie die de dump heeft gemaakt, voer de restore uit, log in, controleer of de tijdlijn volledig is en voer pas daarna een upgrade uit. Upgrade één release per keer, pas IMMICH_VERSION aan en voer docker compose pull && docker compose up -d uit na elke verhoging. Het bewaren van back-ups van een week helpt hierbij: als blijkt dat de nieuwste back-up is gemaakt tijdens een mislukte upgrade, is de back-up van gisteren nog beschikbaar in de repository.

Controleer de back-up elke maand

Een back-up die u nooit heeft hersteld, is slechts een aanname. Herstel deze eenmaal per maand naar een tijdelijke instantie en bekijk een foto. Deze oefening kost ongeveer twintig minuten en is het enige dat de rest van deze pagina verandert in een herstelplan.

restic snapshots
restic stats latest

snapshots hoort de uitvoering van afgelopen nacht weer te geven. stats latest hoort een grootte te rapporteren die in de buurt ligt van uw bibliotheek, niet slechts enkele megabytes.

Herstel naar een tijdelijke map, bij voorkeur op een reservehost:

restic restore latest --target /tmp/immich-drill

Kopieer docker-compose.yml en .env uit de herstelde set en wijzig vervolgens drie zaken in de kopie. Wijs UPLOAD_LOCATION en DB_DATA_LOCATION naar mappen onder /tmp/immich-drill. Publiceer de webpoort ergens anders, 12283:2283 in plaats van 2283:2283. Verwijder de container_name:-regels, omdat het standaard compose-bestand namen zoals immich_server hardcodeert; hierdoor botst een tweede stack op dezelfde host met de eerste en weigert Docker deze aan te maken.

Voer de herstelprocedure van hierboven uit: alleen de database, speel de dump opnieuw af en voer vervolgens docker compose up -d uit. Voer nu de vier controles uit die het succes aantonen.

1. Log in met het wachtwoord dat u vóór de oefening gebruikte. Werkende accounts betekenen dat de dump correct is hersteld.
2. Open de tijdlijn en scrol naar de oudste maand. Assets over het gehele datumbereik betekenen dat alle rijen zijn teruggekeerd, niet alleen de recente.
3. Open één foto op volledige grootte en download het origineel.
4. Vergelijk deze met hetzelfde bestand in uw actieve bibliotheek met sha256sum. Overeenkomende hashes betekenen dat de bytes de volledige cyclus door restic hebben overleefd.

Breek de oefening vervolgens af met docker compose down -v in de oefenmap en verwijder /tmp/immich-drill. Noteer de datum op een plek waar u deze zult zien, want de waarde hiervan zit volledig in het herhalen van deze oefening volgende maand. Als u nog beslist voor welke fotoserver u kiest, behandelt de vergelijking tussen PhotoPrism en Immich precies hoe de twee op dit punt verschillen.

FAQ

Moet ik Immich stoppen om een back-up te maken?

Stop immich_server en laat immich_postgres draaien. De database hoeft niet gepauzeerd te worden, omdat pg_dump leest binnen één MVCC-snapshot en een consistent moment ziet, ongeacht andere schrijfacties. De bestanden zijn de reden om te stoppen: de server schrijft nieuwe uploads en de opslag-template-taak verplaatst bestanden tussen mappen. Een back-uptool kan een bestand halverwege een schrijfactie lezen en een afgekapte kopie opslaan zonder foutmelding. docker stop immich_server vóór de snapshot en docker start immich_server erna elimineert dit race-conditie-risico.

Kan ik de Postgres-datamap kopiëren in plaats van pg_dump te draaien?

Nee. Een doorlopende kopie van een actieve datamap leest verschillende bestanden op verschillende tijdstippen. Het resultaat is geen consistente status en Postgres weigert dit bij het opstarten met PANIC: could not locate a valid checkpoint record of faalt later door een beschadigde pagina. Zelfs een kopie die wordt gemaakt terwijl alles is gestopt, is gebonden aan de exacte database-build: Immich gebruikt een Postgres 14-image met specifieke versies van de vector-search-extensie, en de map zal niet openen onder een andere versie. Een SQL-dump is platte tekst en kan worden ingelezen in elke compatibele server.

Waarom is mijn Immich-tijdlijn leeg na een herstel?

Omdat de tijdlijn wordt opgebouwd uit databaserijen en u de bestanden hebt hersteld zonder de database. Immich scant nooit upload/ om foto's opnieuw te ontdekken, dus bestanden zonder bijbehorende rijen blijven onzichtbaar. De foto's zelf zijn ongewijzigd. Stop de server, speel de dump terug in een vers geïnitialiseerde Postgres en start daarna de stack. Als de tijdlijn wel vol is, maar elke foto niet kan worden geopend, is het probleem omgekeerd: library, upload en profile bevinden zich niet direct in de map die in de container is gemount. Controleer dit met docker exec immich_server ls /data.

Welke Immich-mappen kan ik overslaan in een back-up?

thumbs en encoded-video worden opnieuw gegenereerd vanuit de originelen, en DB_DATA_LOCATION wordt opnieuw opgebouwd vanuit de dump, dus geen van deze hoeft in de back-upset te zitten. Het overslaan ervan bespaart opslagruimte vóór het herstel, maar kost tijd erna, aangezien het opnieuw opbouwen van previews en transcodes voor een grote bibliotheek uren aan CPU-tijd vergt, uitgevoerd via Administration > Jobs voor ontbrekende assets. Wat u nooit mag overslaan zijn library, upload en profile, aangezien deze de enige kopie van elk origineel bevatten.

Kan ik een Immich-dump herstellen in een nieuwere versie?

Meestal wel, omdat de server bij het opstarten de openstaande migraties toepast en het schema bijwerkt. Het omgekeerde werkt niet: Immich ondersteunt geen downgrades, zelfs niet tussen patch-releases. Een dump van een nieuwere release kan niet worden geladen in een oudere server. Herstel met IMMICH_VERSION vastgezet op de release die de dump heeft geschreven, bevestig dat de tijdlijn volledig is en voer daarna de upgrade uit. Noteer de versie bij elke dump met docker inspect --format '{{.Config.Image}}' immich_server, omdat de standaard IMMICH_VERSION=v3 een variabele tag is die geen informatie geeft.