Een veilige Immich-migratiechecklist voor een nieuwe homeserver

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

Een veilige Immich-migratie begint met vaststellen wat behouden moet blijven voordat je iets kopieert: de fotobestanden, de database en de implementatie-instellingen die ze op de nieuwe host opnieuw met elkaar verbinden.

Op een thuisserver ontstaat het migratierisico meestal doordat die onderdelen op verschillende momenten worden verplaatst of doordat de bestemming met de verkeerde paden wordt gestart. Beschouw de oude server als terugvalkopie, voorkom waar mogelijk nieuwe schrijfacties, noteer de huidige versie en opslagkoppelingen en verplaats vervolgens één gecontroleerde gegevensset naar de nieuwe machine. Met de onderstaande checklist blijft het proces omkeerbaar totdat de nieuwe instantie kan inloggen, de oorspronkelijke bibliotheek kan vinden, taken kan verwerken en een herstart kan doorstaan zonder terug te vallen op een lege toestand.

Bevries de bron en leg de bekende goede toestand vast

Begin op de werkende server, niet op de nieuwe. Noteer de Immich-versie, de Compose- of appstore-definitie, de omgevingswaarden die database- en opslagpaden bepalen, de locatie van de fotobibliotheek, de databaselocatie en eventuele mounts voor externe bibliotheken. Noteer ook de huidige server-URL en het gebruikersaccount dat je voor de validatie gebruikt.

Het doel van deze inventaris is te voorkomen dat een migratie ongemerkt tegelijk een upgrade, een nieuw padontwerp en een netwerkwijziging wordt. Houd de applicatieversie en de logische opslagindeling zo stabiel mogelijk totdat het herstel is bewezen; versie wijzigingen kun je uitvoeren nadat de bestemming is gevalideerd.

Stop of pauzeer nieuwe uploads voordat je gaat kopiëren als je huishouden dat aankan. Als dat niet praktisch is, bepaal dan een omschakelvenster en plan een laatste korte synchronisatie. Deze fase is afgerond met een schriftelijke bronkaart waarmee je kunt beantwoorden waar de originelen staan, waar de databasetoestand staat en welke configuratie dezelfde relaties opnieuw tot stand brengt.

Leg database, assets en configuratie vast als één migratieset

Behandel de database en mediabestanden als één herstelset in plaats van als twee onafhankelijke back-ups. Huidige Immich-databaseback-ups bevatten metadata en bestandsverwijzingen, maar niet de foto’s of video’s zelf. Daarom moet de databaseback-up samen worden verplaatst met de bijbehorende inhoud van UPLOAD_LOCATION en eventuele gegevens uit externe bibliotheken die je afzonderlijk beheert.

Een bruikbare migratieset bevat de assets, de PostgreSQL-toestand en de configuratie die ze opnieuw met elkaar verbindt. Een complete Immich-back-upset bevat geüploade assets, een ondersteunde databaseback-up en implementatieconfiguratie, waarbij hersteltests aantonen dat de set werkt. Houd deze onderdelen bij elkaar, zodat de bestemming aan één herstelpunt kan worden gekoppeld.

Controleer de migratieset voordat je de bestemming aanraakt. Bevestig dat de database-dump niet leeg is, neem steekproeven van verschillende originele bestanden uit de gekopieerde bibliotheek en bewaar de Compose- en omgevingsbestanden in dezelfde migratiemap of documentatieset. Als een onderdeel niet kan worden gecontroleerd, stop dan hier en maak een nieuwe kopie in plaats van dit op de nieuwe server te compenseren.

Bereid de nieuwe host voor zonder concurrerende toestand te creëren

Maak eerst de bestemmingsmappen en mounts aan en controleer vervolgens of de nieuwe host de bedoelde schijven of netwerkshares ziet op exact de paden die je wilt gebruiken. Een ontbrekende NAS-mount kan ongemerkt een gewone lege map achterlaten, waarna een container die fallbacklocatie probleemloos kan initialiseren.

Installeer de runtime en herstel de implementatiedefinitie, maar laat een lege Immich-instantie geen uploads of configuratie verzamelen voordat de oude toestand is teruggezet. Houd inloggegevens, databasenaam, opslagvariabelen en mountdoelen voor externe bibliotheken gelijk aan de bron, tenzij het migratieplan uitdrukkelijk een gecontroleerde padwijziging bevat.

Als de nieuwe server andere paden aan de hostzijde vereist, koppel die dan doelbewust en houd daarbij de zichtbare containerpaden en databaseverwachtingen consistent. De bestemming is pas klaar wanneer de effectieve mounts naar de gekopieerde datalocaties wijzen en je elke padvertaling kunt uitleggen voordat de volledige applicatie wordt gestart.

Herstel de toestand en verbind elk opslagpad opnieuw

Herstel de database via de herstelmethode die past bij de Immich-versie waarmee de back-up is gemaakt en start de overige services pas nadat de database gereed is. Voer geen destructieve databaseopdrachten uit een oude handleiding uit als een nieuwere installatie een andere herstelprocedure gebruikt.

Houd tijdens de omschakeling de relatie tussen database en opslag intact voordat het normale gebruik wordt hervat. Een geteste Immich-migratiereeks volgt hetzelfde principe: de applicatie moet openen met de herstelde databasetoestand en de bedoelde mediapaden, niet een lege bibliotheek initialiseren en een volledige heropbouw vanaf nul afdwingen.

Controleer na het opstarten de toegang tot de opslag voordat je zware achtergrondtaken start. Open verschillende oude assets uit verschillende datums, controleer of miniaturen worden geladen, bevestig een album en een persoon of zoekresultaat die vóór de migratie bestonden en controleer of externe bibliotheken leesbaar zijn als je die gebruikt. Een nieuw introductiescherm of een lege tijdlijn is een stopsignaal: controleer de database- en mountkoppelingen opnieuw voordat je nieuwe toestand wegschrijft.

Valideer de oorspronkelijke werklast voordat je de oude server buiten gebruik stelt

Een geslaagde eerste aanmelding is niet het einde van een migratie. Upload één wegwerp-testfoto via de gebruikelijke client, controleer of deze op de verwachte hostopslag verschijnt, verwijder hem vervolgens via Immich en controleer of de bibliotheek gezond blijft. Hiermee controleer je het volledige schrijfpad en bewijs je niet alleen dat oude gegevens leesbaar zijn.

Herstart de nieuwe thuisserver en herhaal de controles die voor je huishouden belangrijk zijn: aanmelden via de browser, verbinding met mobiele back-ups, verschillende oude foto’s, zoeken, een representatieve video, taakwachtrijen en externe toegang als die onderdeel is van de normale configuratie. De migratie is pas voltooid wanneer dezelfde toestand een herstart van de host overleeft en de opslagmounts beschikbaar zijn voordat Immich start.

Houd de oude server gedurende een terugvalperiode uitgeschakeld maar ongewijzigd, in plaats van hem meteen te wissen. Als de nieuwe instantie naar een onverwachte lege map begint te schrijven, de oude bibliotheek na een herstart niet kan reproduceren of onverklaarbare databasefouten toont, stop dan nieuwe uploads en keer terug naar de bekende goede bron terwijl je de migratieset vergelijkt. Stel de oude host pas buiten gebruik nadat de bestemming normaal gebruik en een nieuwe back-uptest heeft doorstaan.

Ondersteuning & Tips

Meer om te lezen

Dubbele taken of imports in Immich voorkomen
Sep 08, 2026

Dubbele taken of imports in Immich voorkomen

Scheid herhaalde taken van dubbele assets. Gebruik één canoniek ingestiepad, beheer retries en padwijzigingen en test vervolgens opnieuw invoeren op een kleine groep.

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.