Immich back-up maken en herstellen op een VPS

Waaruit een Immich-backup moet bestaan

Een Immich-backup bestaat uit drie onderdelen die op hetzelfde moment worden 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 terugplaatst terwijl de Immich-server is gestopt, en de rest van de stack pas daarna start. Als u de volgorde verkeerd uitvoert, eindigt u met een werkende Immich die een lege tijdlijn toont bovenop een volle schijf.

De splitsing is van belang omdat Immich zijn status op twee plaatsen bijhoudt die niets van elkaar weten. Postgres bevat elk album, elke gezichtscluster, elke gedeelde link, elk gebruikersaccount en elke API-sleutel, evenals het opgeslagen pad van elk bestand. 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 bestand als een defecte afbeelding.

De commando's hier zijn geschreven voor Immich v3.1.0, de release die actueel was begin augustus 2026. Per 2026-10-21 is de huidige release v3.3.4, gepubliceerd op 2026-10-20, en het compose-bestand, de database-image en de gedocumenteerde backup- en herstelstappen komen overeen met wat deze pagina gebruikt. Het project brengt snel updates uit en de gedocumenteerde backup-procedure is meer dan eens gewijzigd, dus controleer de versie die u daadwerkelijk draait voordat u iets kopieert. Als de stack nog niet draait, begin dan bij de Immich installatiehandleiding en kom 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. Als u deze kopieert terwijl Postgres actief is, is de kopie geen back-up. Als u deze kopieert terwijl Postgres is gestopt, is het wel een back-up, maar een fragiele. Hier zijn de twee redenen, en u kunt beide zien mislukken.

De eerste is tearing. Postgres schrijft elke wijziging eerst naar de write-ahead log (WAL) en past deze 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. Die twee bestanden behoren niet tot dezelfde transactie. Wanneer u Postgres op het resultaat start, weigert het ofwel 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 betreft de kopie die u maakt terwijl alles is gestopt. PostgreSQL documenteert een volledige kopie van een afgesloten datamap als een geldige back-up, maar die map opent alleen onder binaries die hetzelfde opslagformaat delen. 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 de ingebouwde VectorChord, pgvector en pgvecto.rs vector-search extensies. Een latere Postgres 14 minor-release kan de map ongewijzigd openen, maar een andere Postgres major-versie niet. De extensies waarvan uw tabellen afhankelijk zijn, moeten ook aanwezig zijn in compatibele versies. Uw herstel-host moet een compatibele image draaien. Een SQL-dump maakt dit niet uit: het is tekst en elke compatibele server kan deze opnieuw uitvoeren.

pg_dump omzeilt het tearing-probleem volledig. Het leest de gehele database binnen één enkele MVCC-snapshot (multi-version concurrency control), waardoor de database precies wordt gezien 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 uit de back-up kunt weglaten

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

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

Ze overslaan is een afweging, geen gratis winst. Het opnieuw opbouwen van miniaturen en transcodes voor een grote bibliotheek kost op een kleine VPS uren aan CPU-tijd, en de tijdlijn toont gedurende die tijd grijze tijdelijke aanduidingen. U start ze opnieuw vanuit Administration > Jobs, met "Generate Thumbnails" en "Transcode Videos" ingesteld om te draaien op ontbrekende assets. Als uw back-updoel voldoende ruimte heeft, neem ze dan op en vermijd het wachten. Als u bijna aan uw opslaglimiet zit, laat ze dan weg en houd rekening met de herbouw. Het dimensioneren 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 zelf, die dagelijks om 02:00 worden geschreven waarbij de laatste 14 worden bewaard; dit is configureerbaar onder Administration > Settings > Database Dump Settings. Ze kosten u niets en zijn zeer nuttig. Ze staan 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 initieert op exact 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 DB_DATABASE_NAME en DB_USERNAME als u deze heeft gewijzigd. --clean --if-exists plaatst een DROP ... IF EXISTS voor elke 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 geruisloos 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 perfect geldig gzip-bestand en sluit af met 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 release de dump heeft gemaakt, naast de dump zelf, door dit aan de draaiende server te vragen:

curl -fsS http://localhost:2283/api/server/version > /srv/immich/backup/immich-version.txt

Dat endpoint vereist geen login en retourneert de draaiende release als major-, minor- en patch-nummers, dus 3, 1 en 0 betekenen v3.1.0. Vertrouw hiervoor niet op .env, of op docker inspect --format '{{.Config.Image}}' immich_server, die alleen de image-referentie echo't die u heeft geconfigureerd. Het standaardbestand stelt IMMICH_VERSION=v3 in, een zwevende tag die elke 3.x-release volgt, dus een record dat eindigt op :v3 vertelt u niets over welke build de dump daadwerkelijk heeft geschreven. Pin de exacte tag ook 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 herstelvolgorde is het punt waar goede backups kunnen veranderen in lege tijdlijnen. Volg deze reeks op de nieuwe host.

Haal eerst de configuratie terug. 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

Pin de versie voordat er iets start. Lees immich-version.txt, stel IMMICH_VERSION in .env in op die exacte release (v3.1.0 voor major 3, minor 1, patch 0), en laat de nieuwste release voor nu met rust. Immich ondersteunt geen downgrades, zelfs niet tussen patch-releases, dus als een nieuwere server start tegen een oudere dump en zijn 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 bindt aan een vast pad binnen de container. De indeling daarbinnen kan niet veranderen.

Start de database op zichzelf. Laat DB_DATA_LOCATION leeg zodat Postgres een verse 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 print accepting connections zodra de eerste configuratie is voltooid, wat enkele seconden duurt. 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 start tegen een lege database past zijn migraties toe, maakt een vers schema aan en vraagt u om een nieuw admin-account te maken, waarna u een dump terugplaatst onder een draaiende applicatie.

Speel 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 voeren het eigenlijke werk uit. De sed bestaat omdat pg_dump als veiligheidsmaatregel een lege search_path in zijn output schrijft, zodat niet-gekwalificeerde namen in de dump niet naar een onverwacht schema kunnen verwijzen. De vector-zoektypes van Immich bevinden zich in public, dus 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. Het terugplaatsen van public op het pad lost dit op.

--single-transaction --set ON_ERROR_STOP=on verpakt het gehele herstel in één transactie die afbreekt bij de eerste fout. U krijgt ofwel een complete database of een onaangeroerde. Zonder dit laat een fout halverwege een database achter die wel start en uw login accepteert, maar waarbij een onbekend aantal albums ontbreekt, 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, omdat gebruikersaccounts met de dump zijn teruggekomen. Als de inlogpagina in plaats daarvan aanbiedt om het eerste admin-account aan te maken, is de database niet hersteld. Stop en lees de psql-output opnieuw.

Eén waarschuwing over de officiële command-line herstelinstructies, die beginnen met docker compose down -v. De -v verwijdert benoemde volumes. In het standaard compose-bestand zijn UPLOAD_LOCATION en DB_DATA_LOCATION bind-mounts, dus die overleven dit. Als u een van beide heeft gewijzigd naar een benoemd volume, verwijdert dat commando uw foto's. Lees uw compose-bestand voordat u het typt.

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 vanuit éé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 storage template-taak verplaatst bestanden tussen mappen. Hierdoor kan een back-uptool een bestand halverwege een schrijfactie lezen en een afgebroken kopie opslaan zonder foutmelding. docker stop immich_server voor de snapshot en docker start immich_server erna elimineert deze raceconditie.

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

Niet terwijl Postgres actief is. Een doorlopende kopie van een actieve datamap leest verschillende bestanden op verschillende momenten. Het resultaat is geen consistente staat, waardoor Postgres bij het opstarten weigert met PANIC: could not locate a valid checkpoint record of later faalt door een beschadigde pagina. Een volledige kopie die is gemaakt terwijl Postgres is gestopt, is een geldige back-up, maar deze opent alleen onder dezelfde Postgres-hoofdversie met compatibele extensies. Immich gebruikt een Postgres 14-image met VectorChord, pgvector en pgvecto.rs; de map opent niet onder een andere hoofdversie. Een SQL-dump is platte tekst en kan worden ingelezen in elke compatibele server; dit is daarom de kopie die u moet bewaren.

Waarom is mijn Immich-tijdlijn leeg na een herstel?

Omdat de tijdlijn is opgebouwd uit databaserijen en u de bestanden hebt hersteld zonder de database. Immich scant upload/ nooit om foto's opnieuw te ontdekken, dus bestanden zonder bijbehorende rijen blijven onzichtbaar. De foto's zelf zijn ongewijzigd. Stop de server, voer de dump in een vers geïnitialiseerde Postgres in en start daarna de stack. Als de tijdlijn wel vol is, maar elke foto niet opent, is het probleem omgekeerd: library, upload en profile bevinden zich niet direct in de map die aan de container is gekoppeld. 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, maar kost tijd na een herstel, 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 is 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 release bij elke dump met curl -fsS http://localhost:2283/api/server/version, omdat docker inspect alleen de geconfigureerde image-referentie toont en de standaard IMMICH_VERSION=v3 een variabele tag is die geen informatie geeft.