Varför förlorar Immich åtkomsten till beständiga data efter att stacken har återskapats?

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.

Why Does Immich Lose Access to Persistent Data After Stack Recreation? - Zima Store Online

När Immich ser tomt ut eller inte kan läsa sitt bibliotek efter att stacken har återskapats bör du först anta att de gamla beständiga data är frånkopplade eller oläsbara, innan du antar att de har raderats.

Återskapning av containrar kan ändra Compose-projektets identitet, källan för bind-mounten, anslutningen till namngivna volymer, tidpunkten för nätverksdelningens tillgänglighet eller det UID/GID som läser data. Stoppa den nyskapade instansen innan den hinner skriva mycket nytt tillstånd, hitta de gamla databas- och mediesökvägarna på värden och jämför den återskapade stacken med den senast fungerande mappningen. Målet är att återansluta det befintliga tillståndet först; återställ från säkerhetskopia först när du har bevisat att tillståndet faktiskt saknas eller är skadat.

Stoppa den nya instansen och bevisa att de gamla data fortfarande finns

En installationsguide, en tom tidslinje eller ett saknat externt bibliotek direkt efter återskapningen är en varning om beständig lagring. Stoppa Immich och kontrollera databasens och mediernas platser på värden innan du laddar upp nya filer eller godkänner en ny tom konfiguration. Nya skrivningar kan göra senare sökvägsjämförelser svårare.

Kontrollera de gamla katalogerna efter förväntat antal filer, ändringsdatum, databasfiler eller dumpfiler samt representativa originalbilder. Om data finns på värden är problemet åtkomst eller mappning, inte att data har försvunnit. Skapa en skrivskyddad ögonblicksbild eller säkerhetskopia av tillståndet innan du ändrar ägarskap eller flyttar kataloger.

Om de gamla data inte kan hittas på de förväntade sökvägarna söker du igenom lagringspoolen och Docker-volyminventeringen innan du raderar något. Beslutet är binärt: det befintliga tillståndet har hittats och skyddats, eller så är det verkligen otillgängligt och återställningen går vidare till en känd fungerande säkerhetskopia i stället för att reparera monteringen.

Jämför de återskapade monteringspunkterna med den tidigare stacken

Kontrollera de faktiska monteringspunkterna för de återskapade Immich-server- och databaskontainrarna, inte bara den Compose-text du minns att du redigerade. En relativ bind-sökväg kan lösas från en annan projektkatalog, och ett namnbyte av Compose-projektet kan ansluta en ny namngiven volym samtidigt som den gamla finns kvar men inte används.

En misslyckad, ändrad eller saknad montering kan visa en tom katalog inuti en container, även när de förväntade data fortfarande finns någon annanstans på värden. Använd kontroller av Docker-volymmonteringar för att jämföra Source, Destination, monteringstyp och identitet för namngivna volymer för varje beständig Immich-sökväg. En avvikelse här förklarar direkt varför instansen ser ny och tom ut.

Korrigera endast den felaktiga monteringsmappningen och skapa eller starta sedan containern utan att ta bort volymer. Om de förväntade filerna visas på samma containersökväg efter ändringen låter du data ligga kvar. Om monteringslistan är korrekt men åtkomsten fortfarande misslyckas behåller du mappningen och går vidare till kontroll av värdens lagring och behörigheter i stället för att skapa ännu en volym.

Verifiera att extern lagring var monterad innan Immich startade

Om Immich-data finns på en hårddiskpool, NAS-resurs, sammanslagningslager eller annan extern montering ska du bekräfta att lagringen faktiskt är monterad på värden innan Docker startar stacken. En sökväg som /mnt/photos kan fortfarande finnas som en vanlig lokal katalog när den riktiga enheten saknas.

Beständiga Docker-data överlever byte av container endast när den avsedda volymen eller bind-mounten återansluts korrekt. Den underliggande modellen för beständighet hos Docker-volymer gör inte att en saknad värddisk eller nätverksresurs dyker upp automatiskt. Kontrollera därför lagringsenheten och en känd fil på värden innan du testar samma sökväg inifrån Immich.

Om du upptäcker reservfiler som skrivits till den tomma monteringspunkten medan den riktiga lagringen saknades ska du stoppa Immich innan du monterar enheten ovanpå dem. Hantera dessa filer separat, lägg till ett startberoende eller en hälsokontroll för lagringsmonteringen och starta sedan om stacken. Om värdens lagring är stabil och containersökvägen fortfarande inte kan läsas går du vidare till behörighetsgrenen.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Kontrollera UID, GID och katalogbehörigheter utan att skriva om allt

En återskapad stack kan köra en tjänst med en annan numerisk identitet, användarnamnrymd eller säkerhetskontext än den gamla. Resultatet skiljer sig från en saknad montering: sökvägen finns och filer är synliga från värden, men Immich-loggarna visar behörighetsfel eller Immich kan inte skapa de förväntade filerna.

Jämför numeriskt ägarskap och lägesbitar på de berörda katalogerna på värden med användaridentiteten inuti den återskapade containern. Testa först en ofarlig läsning och därefter en återställningsbar skrivning i en tillfällig plats under samma montering. Undvik att ändra ägarskap rekursivt för hela fotoarkivet innan du vet vilken tjänst som behöver skrivåtkomst och vilka originalfiler som ska lämnas orörda.

Åtgärda den minsta katalog- eller identitetsavvikelse som förklarar felet, starta om en gång och kontrollera loggarna igen. Om åtkomsten fortfarande misslyckas trots matchande monteringar och behörigheter ska du sluta göra ändringar i filsystemet och undersöka den databasanslutning, miljövariabelsubstitution eller säkerhetslager som ändrades vid återskapningen.

Återanslut det ursprungliga tillståndet och validera en ny återskapning

När de gamla databas- och mediesökvägarna är anslutna och läsbara startar du Immich och letar efter de gamla användarna, albumen, personerna och representativa tillgångarna. Förklara inte reparationen som klar bara för att startsidan laddas; verifiera att programmet läser det ursprungliga tillståndet och inte en nyinitierad databas bredvid det.

Den viktiga gränsen är att containrar kan vara förbrukningsbara, medan programmets tillstånd måste finnas på stabil lagring utanför containerns livscykel. Dokumentera de korrigerade monteringsnamnen och värdsökvägarna och använd beständiga lagringsroller på filservern för att hålla nästa återskapning av stacken ansluten till samma data.

Återskapa slutligen stacken en gång till under kontrollerade förhållanden och upprepa de ursprungliga kontrollerna. Åtgärden är bevisad först när samma databas och medier visas igen efter återskapning och efter en omstart av värden. Om det gamla tillståndet försvinner igen, eller om databasen rapporterar korruption i stället för åtkomstfel, återgår du till den skyddade kopian och går över till databas- eller säkerhetskopieåterställning i stället för att fortsätta experimentera med monteringar.