Zo zet je Immich veilig terug na een incompatibele release

Rol Immich alleen terug nadat je de huidige toestand hebt behouden en hebt vastgesteld of de nieuwere release de database of configuratie zodanig heeft gewijzigd dat de oudere image deze niet kan lezen.

Een containerimage kan worden vervangen, maar de persistente gegevens zijn mogelijk al gemigreerd. Als een upgrade problemen oplevert, schakel je automatische updates en nieuwe schrijfbewerkingen uit, leg je beide versies vast, bescherm je de huidige database en media en kies je tussen een eenvoudige image-rollback en het herstellen van het herstelpunt van vóór de upgrade.

Bevries de mislukte upgrade voordat er meer gegevens wijzigen

Schakel automatische image-updates uit en voorkom dat clients nieuwe foto's toevoegen terwijl je bewijsmateriaal verzamelt. Noteer de exacte oude en nieuwe Immich-imageversies of digests, de PostgreSQL-versie, de Compose- en omgevingsbestanden, de mountpaden en de eerste opstart- of migratiefout.

De ZimaSpace-handleiding over rollbackgrenzen van containerimages maakt het cruciale onderscheid: persistente volumes blijven behouden wanneer je een image vervangt, maar dat is alleen veilig als de oudere applicatie compatibel blijft met de gegevens die erin staan.

Maak een database-eigen back-up van de huidige mislukte toestand als de database kan worden gelezen en bewaar de back-up van vóór de upgrade afzonderlijk. Overschrijf geen van beide met herhaalde experimenten. De huidige kopie kan later nodig zijn om vooruit te gaan, zelfs als het onmiddellijke doel is om terug te keren naar de oudere versie.

Bepaal of de release een databasemigratiegrens heeft overschreden

Bekijk de eerste fout na de upgrade en bepaal of deze optreedt vóór of tijdens de databasemigratie, na de migratie tijdens het opstarten van de applicatie of alleen tijdens een gebruikersworkflow. Dit tijdstip bepaalt het rollbackplan, omdat een oudere image mogelijk geen schema begrijpt dat al door de nieuwere release is gewijzigd.

Een recent Immich-rapport waarin de service na een upgradepad niet meer startte, laat zien waarom niet-ondersteunde of overgeslagen migratiepaden een eenvoudige versiewissel onbetrouwbaar kunnen maken. Gebruik de discussie als casestudy en controleer de exacte migratievolgorde voor jouw versies.

Als de nieuwere applicatie de database nooit heeft aangeraakt en de fout beperkt blijft tot image- of runtimecompatibiliteit, kan een rollback naar een vastgezette image voldoende zijn. Als migraties zijn voltooid, ga er dan van uit dat de databaseback-up van vóór de upgrade de veiligere combinatie is voor de oude image, tenzij je expliciet compatibiliteitsbewijs hebt.

Herstel een bijpassende database en runtime in plaats van tijdperken te mengen

Bouw het rollbackdoel op basis van de laatst bekende goed werkende applicatieversie, de bijbehorende implementatieconfiguratie en het databaseherstelpunt van vóór de incompatibele wijziging. Laat de mediamap intact, tenzij de release mediabestanden op een gedocumenteerde manier heeft gewijzigd; kopieer geen terabytes opnieuw alleen omdat de applicatie-image is veranderd.

De bespreking van database-rollback in de planning van databasecompatibele rollbacks legt het algemene gevaar uit van het implementeren van oudere code tegen een schema dat deze niet meer begrijpt. Dat principe is belangrijker dan de vraag of de container zelf succesvol start.

Start de rollbackinstantie geïsoleerd, zodat mobiele clients en geplande taken niet kunnen schrijven voordat de validatie is voltooid. Als de oude versie onmiddellijk schemafouten meldt, stop dan. Forceer geen migraties handmatig terug op de enige databasekopie, tenzij je over een geteste, versiespecifieke herstelprocedure beschikt.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Zet de exacte bekende werkende image vast en reconstrueer de configuratie

Gebruik een specifieke versie of een onveranderlijke imagereferentie in plaats van een meebewegende tag. Herstel de bijpassende omgeving, serviceafhankelijkheden, apparaattoewijzingen, netwerken, poorten en reverse-proxydoelen van de laatst bekende goed werkende implementatie. Een rollback die ongemerkt meerdere infrastructuurlagen wijzigt, veroorzaakt een tweede incident.

Bewaar de mislukte nieuwere image en configuratie naast de rollbacknotities. Zo blijft gecontroleerd herstel naar voren mogelijk nadat de incompatibiliteit is begrepen. Als je elk nieuw artefact onmiddellijk verwijdert, wordt het moeilijker om de mislukte en werkende toestanden te vergelijken of de upgrade in een testomgeving te reproduceren.

Als de oudere service met de herstelde toestand start, controleer dan de logs voordat je clients inschakelt. Bevestig dat er geen onverwachte migratiepoging, initialisatie van een nieuwe installatie, ontbrekende opslagmount of herschrijving van rechten plaatsvindt. Alleen een aanmeldpagina is geen bewijs dat de rollback de bedoelde gegevens gebruikt.

Valideer de oude versie onder de oorspronkelijke trigger en houd een pad vooruit open

Test representatieve gebruikers, oude en recente bestanden, albums, delen, zoeken, één nieuwe gecontroleerde upload, achtergrondtaken, het maken van databaseback-ups en de reverse-proxyroute. Herstart de stack eenmaal en controleer of dezelfde mounts en database zonder handmatige tussenkomst terugkeren.

Houd nieuwe uploads gepauzeerd totdat deze controles slagen, open daarna de toegang opnieuw en houd de normale werkbelasting in de gaten. Bewaar zowel de back-up van vóór de upgrade als de back-up van de mislukte nieuwere toestand, zodat je de upgrade later opnieuw kunt proberen in een geïsoleerde kopie nadat het compatibiliteitsprobleem is begrepen.

De rollback is mislukt als de oudere versie schema-incompatibiliteit meldt, bekende gegevens ontbreken of schrijfbewerkingen op een onverwacht pad terechtkomen. Stop en herstel het bewaarde herstelpunt opnieuw in plaats van reparaties op elkaar te stapelen. Escaleer met de exacte versies, migratielogs, tijdstempels van databaseback-ups, het Compose-verschil en de eerste verificatiestap die mislukt.