Så här återställer du Immich på ett säkert sätt efter en inkompatibel version

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

How to Roll Back Immich Safely After an Incompatible Release - Zima Store Online

Rulla endast tillbaka Immich efter att ha bevarat det aktuella tillståndet och fastställt om den nyare versionen ändrade databasen eller konfigurationen på ett sätt som den äldre avbilden inte kan läsa.

En containeravbild kan ersättas, men dess beständiga tillstånd kan redan ha migrerats. Om en uppgradering börjar gå fel ska du stoppa automatiska uppdateringar och nya skrivningar, dokumentera båda versionerna, skydda den aktuella databasen och mediefilerna och sedan välja mellan en enkel återställning av avbilden och en återställning av återställningspunkten före uppgraderingen.

Frys den misslyckade uppgraderingen innan mer tillstånd ändras

Inaktivera automatiska avbildsuppdateringar och hindra klienter från att lägga till nya foton medan du samlar in bevis. Dokumentera de exakta versionerna eller digest-värdena för de gamla och nya Immich-avbilderna, PostgreSQL-versionen, Compose- och miljöfilerna, monteringssökvägarna samt det första start- eller migreringsfelet.

ZimaSpaces guide om gränserna för återställning av containrar tydliggör den viktiga skillnaden: beständiga volymer överlever när avbilden ersätts, men det är bara säkert när den äldre applikationen fortfarande är kompatibel med tillståndet i volymerna.

Ta en databasintern säkerhetskopia av det aktuella misslyckade tillståndet om databasen kan läsas och bevara säkerhetskopian från före uppgraderingen separat. Skriv inte över någon av dem med upprepade experiment. Den aktuella kopian kan behövas för att gå vidare senare även om det omedelbara målet är att återgå till den äldre versionen.

Fastställ om versionen passerade en databasgräns för migrering

Granska det första felet efter uppgraderingen och identifiera om det inträffar före eller under databas-migreringen, efter migreringen medan applikationen startar eller endast under ett användarflöde. Tidpunkten ändrar planen för återställning, eftersom en äldre avbild kanske inte förstår ett schema som redan har ändrats av den nyare versionen.

En aktuell Immich-rapport där tjänsten misslyckades efter en uppgraderingsväg visar varför migreringsvägar som inte stöds eller hoppas över kan göra ett enkelt versionsbyte opålitligt. Se tråden som en fallstudie och verifiera den exakta migreringssekvensen för dina versioner.

Om den nyare applikationen aldrig rörde databasen och felet är begränsat till kompatibilitet med avbilden eller körmiljön kan en återställning till en låst avbild räcka. Om migreringar slutfördes ska du anta att databassäkerhetskopian från före uppgraderingen är den säkrare partnern för den äldre avbilden, såvida du inte har tydliga kompatibilitetsbevis.

Återställ en matchande databas och körmiljö i stället för att blanda versioner

Bygg återställningsmålet från den senast kända fungerande applikationsversionen, dess kompatibla distributionskonfiguration och databasens återställningspunkt från före den inkompatibla ändringen. Behåll medieträdet intakt om inte versionen ändrade mediefiler på ett dokumenterat sätt; kopiera inte om terabyte enbart för att applikationsavbilden ändrades.

Diskussionen om databasåterställning i planering för databas-kompatibla återställningar förklarar den allmänna risken med att distribuera äldre kod mot ett schema som den inte längre förstår. Den principen är viktigare än om själva containern startar korrekt.

Starta återställningsinstansen isolerat så att mobilklienter och schemalagda jobb inte kan skriva innan valideringen är klar. Om den gamla versionen omedelbart rapporterar schemafel ska du stoppa. Tvinga inte manuellt tillbaka migreringar i den enda databaskopian om du inte har en testad, versionsspecifik återställningsprocedur.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Lås den exakta fungerande avbilden och återskapa dess konfiguration

Använd en specifik version eller en oföränderlig avbildsreferens i stället för en rörlig tagg. Återställ den matchande miljön, tjänsteberoendena, enhetsmappningarna, nätverken, portarna och omvända proxy-målet från den senast kända fungerande distributionen. En återställning som i det tysta ändrar flera infrastrukturlager skapar en andra incident.

Bevara den misslyckade nyare avbilden och konfigurationen tillsammans med anteckningarna om återställningen. Då blir en kontrollerad återställning framåt möjlig när inkompatibiliteten har förståtts. Om du tar bort alla nya artefakter omedelbart kan det bli svårare att jämföra de misslyckade och fungerande tillstånden eller återskapa uppgraderingen i en testmiljö.

Om den äldre tjänsten startar mot det återställda tillståndet ska du granska loggarna innan du aktiverar klienterna. Bekräfta att ingen oväntad migrering, initiering av en ny installation, saknad lagringsmontering eller omskrivning av behörigheter sker. En inloggningssida ensam bevisar inte att återställningen använder avsedda data.

Validera den gamla versionen under den ursprungliga utlösaren och behåll en väg framåt

Testa representativa användare, gamla och nyligen tillagda tillgångar, album, delning, sökning, en ny kontrollerad uppladdning, bakgrundsjobb, skapande av databassäkerhetskopior och den omvända proxy-rutten. Starta om stacken en gång och bekräfta att samma monteringar och databas återkommer utan manuella åtgärder.

Pausa nya uppladdningar tills kontrollerna har godkänts, öppna sedan åtkomsten igen och övervaka det normala arbetsbelastningsfönstret. Bevara både säkerhetskopian från före uppgraderingen och säkerhetskopian av det misslyckade nyare tillståndet, så att du senare kan försöka uppgradera igen i en isolerad kopia när kompatibilitetsproblemet har förståtts.

Återställningen har misslyckats om den äldre versionen rapporterar schemainkompatibilitet, kända data saknas eller skrivningar hamnar på en oväntad sökväg. Stoppa och återställ den bevarade återställningspunkten igen i stället för att lägga reparationer ovanpå varandra. Eskalera med exakta versioner, migreringsloggar, tidsstämplar för databassäkerhetskopior, en Compose-diff och det första verifieringssteget som misslyckas.