Wanneer moet je een Immich-installatie opnieuw opbouwen in plaats van repareren?

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.

Repareer Immich wanneer de fout gelokaliseerd is en de persistente gegevens aantoonbaar intact zijn; bouw de runtime opnieuw op wanneer de configuratiedrift omvangrijk is, maar een geverifieerde database, mediabibliotheek, implementatiedefinitie en terugrolkopie de service veilig kunnen reconstrueren.

Opnieuw opbouwen is niet hetzelfde als alles verwijderen. Containers en netwerken zijn vervangbaar, terwijl de database en originelen het archief van de bibliotheek vormen. Classificeer eerst de integriteit, omvang en reproduceerbaarheid. Als de enige database of enige kopie van de foto's mogelijk beschadigd is, bewaar die dan en stop—op basis van dat bewijs opnieuw beginnen kan een diagnosticeerbaar incident in permanent gegevensverlies veranderen.

Repareer wanneer de fout lokaal en omkeerbaar is

Kies bij voorkeur voor reparatie wanneer één mount, machtiging, omgevingswaarde, afhankelijkheid, taak of vastgezette image de fout verklaart en het systeem vóór een bekende wijziging normaal werkte. Leg logboeken vast, maak een back-up, wijzig alleen die ene laag en herhaal de trigger.

Een geslaagde reparatie herstelt de defecte functie zonder ontbrekende assets, databasefouten of nieuwe waarschuwingen bij het opstarten te veroorzaken. Als dezelfde fout na opnieuw aanmaken terugkeert, kan de oorzaak in de implementatiedefinitie of persistente status liggen; herhaaldelijk containers vervangen is dan geen op bewijs gebaseerde reparatie meer.

Een bespreking over databasecorruptie laat zien hoe snel herstelkeuzes risicovol worden wanneer de database de vermoedelijke probleemlaag is. Gebruik de les om vóór reparatie gegevens veilig te stellen, en niet een onbewezen destructief commando.

Bouw de runtime opnieuw op wanneer de drift onbeheersbaar is

Kies voor een schone herbouw van de runtime wanneer imageversies, netwerken, omgevingswaarden, mounts en handmatige containerwijzigingen niet langer reproduceerbaar zijn, maar geverifieerde persistente onderdelen intact zijn gebleven. Bouw naast de oude instantie met vastgezette versies en geïsoleerde poorten, in plaats van deze te wissen.

Een herbouw is ook gepast na een compromittering van de host of wanneer een niet-ondersteunde installatie onbekende wijzigingen heeft opgestapeld, omdat het herstellen van vertrouwde implementatie-invoer een nieuwe auditgrens creëert. Roteer blootgestelde inloggegevens en inspecteer back-ups voordat je ze aan het schone doel koppelt.

Het overzicht van ZimaSpace over implementatie van zelf gehoste apps biedt bredere context over de servicestack; bij Immich moeten de relatie tussen database en media echter afzonderlijk worden gevalideerd.

Bouw niet opnieuw op onzekere persistente gegevens

Stop wanneer de database en uploadbibliotheek mogelijk niet synchroon lopen, de enige back-up niet is getest of onduidelijk is welke kopie de bron van waarheid is. Maak snapshots of klonen van alle kandidaten en leg tijdstempels vast voordat je databaseherstel of mediareconciliatie probeert.

Een Unraid-herstelthread laat zien hoe lastig het operationeel is om Immich te herstellen wanneer back-upcomponenten en versies niet overeenkomen. De bespreking over de herstelgrens ondersteunt testen in isolatie in plaats van de productie­paden te overschrijven.

Als de originelen intact zijn maar de database niet herstelbaar is, bewaar dan beide en leg de gevolgen vast voordat je een nieuwe bibliotheekimport overweegt. Dat is een beslissing over gegevensreconstructie, geen routineonderhoud, en kan albums, deelstatus, gezichten, favorieten of historische metadata verliezen.

Valideer persistente gegevens op een schoon doel

Herstel of koppel gekopieerde persistente gegevens aan het schone doel en test vervolgens gebruikers, aantallen in de tijdlijn, steekproeven van originelen, albums, zoeken, gezichtsgegevens, externe bibliotheken, een nieuwe upload, taken en een nieuwe databaseback-up. Vergelijk de resultaten met het bewaarde bronbewijs.

Vergelijk het aantal assets in de database met steekproefsgewijs gecontroleerde bestanden verspreid over meerdere datums, gebruikers en mediatypen. Bevestig paden naar externe bibliotheken, afgeleide taken en een nieuwe database­dump voordat je het productieadres toewijst. Alleen een aanmeldscherm bewijst niet dat de gegevens integer zijn.

Start de containers en de host tweemaal opnieuw op. Voor een geslaagde test zijn stabiele mounts, reproduceerbare configuratie, geen migratielus en de oorspronkelijke werklast vereist. Als het schone doel dezelfde database- of bestandsfout reproduceert, was runtime-drift niet de oorzaak en blijft gespecialiseerd gegevensherstel de veiligere route.

Schakel over met een terugrolgrens

Draag het productieadres pas over nadat de geïsoleerde controles zijn geslaagd en houd het oude systeem gedurende een afgesproken observatieperiode uitgeschakeld maar herstelbaar. Voorkom dat beide instanties tegelijk uploads accepteren of dezelfde automatisering uitvoeren.

Voer na de omschakeling de normale workflow voor uploads, bladeren, zoeken, delen en back-ups van het gezin uit. Een geslaagde test behoudt de aantallen en originelen na de volgende herstart; bij een afwijking stuur je het verkeer terug naar het bewaarde doel zonder een van beide datasets te overschrijven.

Keer terug naar reparatie of gespecialiseerd herstel als het schone doel dezelfde database- of bestandsfouten reproduceert; de runtime was niet de oorzaak. Draai de omschakeling terug als aantallen of originelen verschillen. Escaleer met versies, checksums, tijdstempels van back-ups, de eerste fout en de exacte grens tussen gekopieerde en nieuw aangemaakte status.

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.