Hoe voorkom je verlies van de Immich-configuratie tijdens upgrades

Voorkom verlies van de Immich-configuratie tijdens upgrades door het Compose-bestand, omgevingswaarden, database, uploadbibliotheek en mountdefinities voor externe bibliotheken te behandelen als afzonderlijke persistente assets die samen moeten worden vastgelegd en hersteld.

Een container is vervangbaar; de configuratie eromheen niet. Een upgrade kan de indruk wekken dat Immich is gewist wanneer een relatieve bind-mount vanuit een andere projectmap wordt opgelost, een wijziging in de omgeving de opnieuw aangemaakte container nooit bereikt, of de nieuwe stack start met een lege database. Breng eerst de actieve implementatie in kaart, bewaar versies buiten de host en bewijs een gecontroleerde recreatie voordat je naar productie overschakelt.

Leg de actieve implementatie vóór elke upgrade vast

Exporteer de effectieve Compose-configuratie met geredigeerde geheimen, noteer imageversies of digests en kopieer de Compose- en omgevingsbestanden naar versiebeheer. Inspecteer de mounts van de actieve containers in plaats van aan te nemen dat het bestand in je editor de huidige containers heeft gestart. Geslaagd betekent dat elk runtimepad naar een bekende locatie op de host verwijst.

Noteer paden naar externe bibliotheken, reverse-proxy-instellingen, de URL voor machine learning, databaseverbindingswaarden, de gebruikers- en groepsidentiteit, netwerk­namen en eventuele apparaten voor hardwareversnelling. Een ontbrekend item wordt later een onverklaarbaar verschil na de upgrade.

Vragen uit de community over upgrades laten herhaaldelijk zien dat beheerders uit het oog verliezen welke Compose-generatie of omgevingsindeling van toepassing is. De nuttige les uit één discussie over upgradeconfiguratie is dat je de huidige werkende definitie moet bewaren voordat je die vertaalt.

Maak afzonderlijk back-ups van database, media en implementatiebestanden

Maak een database-eigen back-up plus een back-up of momentopname van het bestandssysteem met de uploadbibliotheek en implementatiemap. Noteer begin- en eindtijden, archiefgroottes en checksums. Een back-up die alleen Compose-YAML bevat, kan containers opnieuw opbouwen, maar geen accounts, metagegevens, albums of assetrecords herstellen.

Gebruik een back-up met gestopte services voor de eenvoudigste consistentiegrens, of coördineer een live database-dump en opslagmomentopname zodat hun onderlinge relatie is gedocumenteerd. Houd externe bibliotheken in de inventaris, ook als Immich niet de eigenaar is van de oorspronkelijke bestanden, omdat paden en toegangsregels nog steeds invloed hebben op de herstelde service.

Een door de community onderhouden procedure voor een upgrade naar een nieuwe hoofdversie benadrukt het bewaren van database, media, Compose en omgevingsinvoer. Beschouw de volgorde als praktijkervaring van beheerders en controleer elke stap aan de hand van de release die je daadwerkelijk implementeert.

Bereid de upgrade voor met vastgezette versies

Lees de releaseopmerkingen voor elke overgeslagen versie en werk de opgeslagen implementatiedefinitie doelbewust bij. Zet de doelrelease vast, haal die binnen zonder oude images te verwijderen en valideer de gerenderde Compose-configuratie. Onbekende variabelen, lege mounts of gemengde serviceversies betekenen dat de stagingcontrole mislukt.

Herstel de back-up, waar de capaciteit dat toelaat, naar een geïsoleerde teststack met andere poorten en zonder schrijfrechten voor productie. Start die op de doelversie en controleer migraties, gebruikers, opslagpaden en achtergrondtaken. Alleen het succesvol starten van containers bewijst niet dat de oorspronkelijke bibliotheek is gekoppeld.

De gerelateerde ZimaSpace-gids voor een veilige zelfgehoste NAS helpt om implementatiebestanden en back-ups buiten de enkele host en referentiegrens te plaatsen die door een upgrade kan worden verstoord.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Bewijs dat de configuratie behouden blijft na recreatie

Maak vóór de omschakeling de testcontainers opnieuw aan vanuit de opgeslagen bestanden in plaats van ze ter plekke opnieuw te starten. Controleer gebruikers, serverinstellingen, opslagsjablonen, bibliotheken, taken, proxietoegang en effectieve omgevingswaarden. Geslaagd betekent dat de configuratie een vervanging overleeft omdat die in gedocumenteerde persistente componenten staat.

Upload na de omschakeling naar productie één testasset, voer een zoekopdracht uit, open een origineel bestand en maak een nieuwe databaseback-up. Start de stack en de host opnieuw op en herhaal dit. Bewaar de oude versie, back-up en implementatiedefinitie totdat de normale werklast gedurende de observatieperiode stabiel blijft.

Als de upgrade al leeg is gestart, stop die dan voordat onboarding of nieuwe uploads conflicterende toestand creëren. Koppel alleen een geverifieerd persistent pad opnieuw of herstel naar een schoon doel. Draai terug wanneer verwachte gebruikers of assets ontbreken; escaleer met opgeschoonde effectieve Compose-configuratie, mounts, versies en tijdstempels van back-ups als de identiteit onduidelijk blijft.