Källdatan verkade inte uppenbart förlorad. Efter en återställning av ZimaOS fanns RAID6 fortfarande kvar, liksom kataloger som upload, pgdata, thumbs, profile, och encoded-video fanns fortfarande kvar. Problemet var att den ominstallerade Immich-stacken inte var ansluten till det gamla databas-/bibliotekstillståndet på ett sätt som återställde den tidigare fotokatalogen.
Det säkraste rådet i källan var: radera eller flytta inte de gamla mapparna upload och pgdata ännu. Immich återskapar inte hela katalogen bara genom att hitta bildfiler på disken. Databasen innehåller filsökvägar, användare, album, metadata och applikationstillstånd. Den aktuella dokumentationen för Immich v3 tydliggör detta samband och rekommenderar säkerhetskopiering av både tillgångsfilerna och databasen.
Bekräfta först den faktiska RAID-monteringssökvägen
Källan använde:
ls -la /media
find /media -maxdepth 4 -type d \( -iname "immich" -o -iname "pgdata" -o -iname "upload" \)och hittade:
/media/photos/immich
/media/photos/immich/pgdata
/media/photos/immich/uploadDet fastställde att de gamla Immich-mapparna fortfarande fanns på RAID-enheten.
/media/ZimaOS-HD → /DATA bevisade inte att Immich använde OS-enheten
Användaren blev orolig av:
/media/ZimaOS-HD -> /DATAmen communityn förklarade korrekt att detta är en monterings-/symlinkrelation i ZimaOS. Att den finns visar inte vilka värdsökvägar Immich-containrarna faktiskt använder.
Inspektera Dockers effektiva monteringar
Tråden rekommenderade att kontrollera:
docker inspect immich-server --format '{{json .Mounts}}'
docker inspect immich-postgres --format '{{json .Mounts}}'Det är mer tillförlitligt än att anta att en skärmbild eller ett gammalt minne återspeglar den körande containerkonfigurationen.
Det gamla pgdata är lika viktigt som de gamla fotofilerna
Om ominstallationen initierade en helt ny databas i stället för den gamla kan filerna fortfarande finnas kvar, medan Immich verkar tomt.
Aktuell Immich använder UPLOAD_LOCATION och DB_DATA_LOCATION
Aktuell Immich v3 Compose separerar värdens resursplats och Postgres-plats med hjälp av UPLOAD_LOCATION och DB_DATA_LOCATION. Uppströmsprojektet säger uttryckligen att nätverksresurser inte stöds för databassökvägen.
Använd den aktuella lagringsmodellen i Immich.
En databassäkerhetskopia är säkrare än att återansluta en aktiv gammal pgdata-katalog mellan versioner
Källan använde Immich v2.7.2. Den aktuella versionen av Immich är v3. Vid återställning mellan versioner är uppströmsprojektets arbetsflöde för säkerhetskopiering och återställning av databasen säkrare än att anta att en gammal Postgres-datakatalog helt enkelt kan anslutas till en nyare databasavbildning.
Se den aktuella processen för säkerhetskopiering och återställning i Immich.
Flytta inte Immichs interna resursmappar manuellt
Den aktuella Immich-dokumentationen varnar för att mappar som library, upload, thumbs, profile, och encoded-video hanteras av programmet. Att flytta eller ta bort enskilda filer bakom Immich kan skapa saknade eller ospårade resurser.
Källanvändaren bekräftade inte en lyckad återställning
Communitymedlemmar föreslog flera mappningsmetoder, bland annat en enda överordnad montering, men jerlo lade till slut frågan åt sidan och började om på ett annat system. Därför bekräftar forumet inte någon enskild sökvägsmappning som den slutliga lösningen.
Aktuella Immich föredrar en hanterad uppladdningsrot framför att mappa varje underkatalog manuellt
Källans skärmbilder mappade manuellt upload, thumbs, profile, library, encoded-video, och säkerhetskopior en i taget. Aktuell Compose från uppströmsprojektet fokuserar i stället på värdkonfigurationen för UPLOAD_LOCATION, där Immich hanterar sina interna underkataloger under den roten.
När du bygger om på en nyare Immich-version bör du använda den aktuella Compose-/lagringslayouten i stället för att återskapa en historisk uppsättning mappningar av underkataloger, om inte paketet specifikt kräver dem.
Behåll Postgres-datasökvägen på lagring som stöds lokalt
Den aktuella Immich-dokumentationen anger uttryckligen att nätverksresurser inte stöds för DB_DATA_LOCATION. Ett lokalt anslutet RAID-/lagringsfilsystem kan vara lämpligt, men en SMB-/NFS-monterad databaskatalog är inte den databassökväg som stöds.
En fullständig återställning av Immich kräver både tillgångar och databas
Den aktuella dokumentationen för säkerhetskopiering av Immich anger att databassäkerhetskopior innehåller metadata och användarinformation, men inte foto- och videotillgångarna. Tillgångsträdet måste säkerhetskopieras separat och återställas tillsammans med en kompatibel databassäkerhetskopia.
Det förklarar varför ”uppladdningsfilerna finns fortfarande kvar” var lugnande men otillräckligt i källfallet.
Anslut inte en gammal aktiv pgdata-katalog till en annan Postgres- eller Image-version utan eftertanke
En rå Postgres-datakatalog är versionskänslig. Om den gamla miljön och det nya paketet använder olika Postgres- eller Immich-versioner bör du föredra en databasdump och återställning som stöds eller en dokumenterad migreringsväg. Skapa en säkerhetskopia av den gamla pgdata innan du experimenterar.
Vanliga frågor om återställning av Immich
Raderade återställningen av ZimaOS källans RAID6-fotomappar?
Nej. Användaren uppgav att RAID-enheten och befintliga kataloger och filer förblev intakta.
Räcker det att mappa gamla fotofiler för att återställa Immich-biblioteket?
Inte nödvändigtvis. Immich behöver även motsvarande databas- och katalogtillstånd.
Vad bör skyddas innan du experimenterar?
Den fullständiga lagringen av tillgångar samt databasen eller en verifierad säkerhetskopia av databasen.
