När bör du bygga om i stället för att reparera en Immich-installation?

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.

When Should You Rebuild Rather Than Repair an Immich Installation? - Zima Store Online

Reparera Immich när felet är lokalt och de beständiga data tydligt är intakta; bygg om körmiljön när konfigurationsavvikelserna är omfattande men en verifierad databas, ett mediebibliotek, en distributionsdefinition och en återställningskopia kan återskapa tjänsten på ett säkert sätt.

Att bygga om är inte samma sak som att radera allt. Behållare och nätverk kan ersättas, medan databasen och originalfilerna är bibliotekets källor. Klassificera först integritet, omfattning och återskapbarhet. Om den enda databasen eller den enda kopian av fotona kan vara skadad ska du bevara den och stoppa – att börja om från början utifrån dessa bevis kan förvandla en diagnostiserbar incident till permanent dataförlust.

Reparera när felet är lokalt och reversibelt

Föredra reparation när ett enda monteringsfel, behörighetsfel, miljövärde, beroende, jobb eller låst avbild förklarar felet och systemet fungerade normalt före en känd ändring. Samla in loggar, skapa en säkerhetskopia, ändra endast det lagret och upprepa utlösningen.

Ett godkänt test återställer den felande funktionen utan att skapa saknade tillgångar, databasfel eller nya varningar vid uppstart. Om samma fel återkommer efter återskapande kan orsaken finnas i distributionsdefinitionen eller den beständiga datan, så upprepade byten av behållare är inte längre evidensbaserad reparation.

En diskussion om databaskorruption visar hur snabbt återställningsval blir högrisk när databasen är det misstänkta lagret. Använd lärdomen att bevara data före reparation, inte något overifierat destruktivt kommando.

Bygg om körmiljön när avvikelserna är okontrollerbara

Välj en ren ombyggnad av körmiljön när avbildsversioner, nätverk, miljövärden, monteringar och manuella ändringar av behållare inte längre kan återskapas, men verifierade beständiga komponenter fortfarande är intakta. Bygg bredvid den gamla instansen med låsta versioner och isolerade portar i stället för att radera den.

En ombyggnad är också lämplig efter att värdsystemet har komprometterats eller en installation utan support har samlat på sig okända ändringar, eftersom återställning av betrodda distributionsindata skapar en ny granskningsgräns. Byt exponerade autentiseringsuppgifter och granska säkerhetskopior innan du ansluter dem till det rena målet.

ZimaSpaces översikt över distribution av självhostade appar ger ett bredare sammanhang för tjänstestacken; Immich kräver fortfarande att relationen mellan databasen och medierna valideras separat.

Bygg inte om ovanpå osäker beständig data

Stoppa när databasen och uppladdningsbiblioteket kan vara osynkroniserade, när den enda säkerhetskopian inte har testats eller när det är oklart vilken kopia som är den auktoritativa. Skapa en ögonblicksbild eller klon av alla kandidater och dokumentera tidsstämplar innan du försöker återställa databasen eller samordna medierna.

En återställningstråd för Unraid visar den praktiska svårigheten med att återställa Immich när säkerhetskopierade komponenter och versioner inte stämmer överens. Dess diskussion om återställningsgränser stöder testning i isolering i stället för att skriva över produktionssökvägarna.

Om originalen är intakta men databasen inte kan återställas ska du bevara båda och dokumentera konsekvensen innan du överväger att importera ett nytt bibliotek. Det är ett beslut om datarekonstruktion, inte rutinmässig reparation, och album, delningsstatus, ansikten, favoriter eller historiska metadata kan gå förlorade.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Validera beständig data på ett rent mål

Återställ eller anslut kopierad beständig data till det rena målet och testa sedan användare, antal objekt i tidslinjen, ett urval av original, album, sökning, ansiktsdata, externa bibliotek, en ny uppladdning, jobb och en ny säkerhetskopia av databasen. Jämför resultaten med den bevarade källan.

Jämför antalet tillgångar i databasen med ett urval av filer från flera datum, användare och medietyper. Bekräfta sökvägar till externa bibliotek, härledda jobb och en ny databasutdump innan du tilldelar produktionsadressen. En inloggningsskärm bevisar inte ensam dataintegritet.

Starta om behållare och värdsystem två gånger. Godkänt resultat kräver stabila monteringar, repeterbar konfiguration, ingen migrationsloop och den ursprungliga arbetsbelastningen. Om det rena målet återskapar samma databas- eller filfel var körmiljöavvikelser inte orsaken, och specialiserad dataåterställning är fortfarande det säkrare alternativet.

Gör övergången med en återställningsgräns

Överför produktionsadressen först när de isolerade kontrollerna har godkänts, och håll det gamla systemet avstängt men återställningsbart under en överenskommen observationsperiod. Förhindra att båda instanserna samtidigt tar emot uppladdningar eller kör samma automatisering.

Kör det normala arbetsflödet för familjens uppladdning, bläddring, sökning, delning och säkerhetskopiering efter övergången. Ett godkänt resultat bevarar antal och original efter nästa omstart; vid avvikelse skickas trafiken tillbaka till det bevarade målet utan att någon av datamängderna skrivs över.

Återgå till reparation eller specialiserad återställning om det rena målet återskapar samma databas- eller filfel; körmiljön var inte orsaken. Rulla tillbaka övergången om antal eller original skiljer sig åt. Eskalera med versioner, kontrollsummor, tidsstämplar för säkerhetskopior, det första felet och den exakta gränsen mellan kopierat och nyskapat tillstånd.