Så reparerar du Immich när dess databasvolym blir full

När Immich-databasvolymen blir full ska du stoppa nya Immich-skrivningar, bevara PostgreSQL-datakatalogen och skapa säkert arbetsutrymme innan du försöker återställa systemet. Ta inte bort filer från pg_wal eller andra PostgreSQL-interna kataloger bara för att de är stora.

Ett fullt databasfilsystem kan avbryta kontrollpunkter eller kraschåterställning, så upprepade omstarter kan fortsätta misslyckas även när själva fotoapplikationen verkar fungera. Fastställ först vilket filsystem som är fullt – PostgreSQL-data, Docker-rotlagring, delat minne eller en annan monteringspunkt – och återställ sedan det lagret utan att förstöra bevis som kan behövas för återställning.

Bekräfta vilket filsystem som är fullt och stoppa ytterligare skrivningar

Kontrollera tillgängligt utrymme i byte och inoder för PostgreSQL-monteringen, Dockers datarot, värdsystemets rotfilsystem och eventuell tmpfs-/delat-minne-sökväg som nämns i felet. Matcha tidsstämpeln mot PostgreSQL-loggarna. Meddelandet ”no space left on device” från pg_wal betyder något annat än en full bildcache eller miniatyrpartition.

En diskussion om databasåterställning i Immich visar hur PostgreSQL avbröt återställningen eftersom en tillfällig WAL-fil inte kunde skrivas när lagringsutrymmet tog slut. Fallet är gammalt och specifikt för en viss distribution, men visar varför ändrade filbehörigheter eller en omstart av stacken inte åtgärdar ett kapacitetsproblem.

Pausa uppladdningar och bakgrundsjobb och stoppa sedan de programkomponenter som genererar nytt databasarbete. Bevara det första felaktiga loggfönstret och monteringskartan. Om det fulla filsystemet faktiskt inte är PostgreSQL:s datafilsystem ska du åtgärda den verkliga platsen i stället för att flytta databasen i onödan.

Bevara PostgreSQL-tillståndet innan du skapar mer utrymme

När PostgreSQL är stoppat ska du ta en filsystemsnapshot eller en komplett kopia av databasens datakatalog när lagringsutrymme och verktyg tillåter det. Inkludera WAL-katalogen och eventuella tabellutrymmen som inte använder standardinställningarna som ett sammanhängande tillstånd. Denna säkerhetskopia gör att du kan återgå till läget vid incidenten om nästa återställningsförsök förvärrar situationen.

PostgreSQL:s vägledning för återställning efter slut på diskutrymme tydliggör den kritiska regeln: WAL är en del av databaskonsistensen, inte vanligt loggskräp, och manuell radering kan förstöra databasen. Skapa i stället kapacitet genom att utöka eller flytta volymen eller genom att ta bort annan säker och orelaterad data. Skriv inte omedelbart över den havererade databasen med den senaste säkerhetskopian om du inte har beslutat att det aktuella tillståndet inte kan återställas och accepterar att förlora ändringar sedan den säkerhetskopian. Genom att bevara den fulla instansen får du både en återställningspunkt och bevis på varför utrymmet försvann.

Återställ PostgreSQL först och avgör sedan om Immich behöver repareras

När tillräckligt med utrymme finns ska du starta PostgreSQL separat eller med den minsta nödvändiga stacken och följa återställningsloggarna. En ren uppstart, en lyckad hälsokontroll och normal läsåtkomst är starkare signaler än att en container har statusen ”running”. Ta en ny databasinbyggd säkerhetskopia så snart databasen är tillräckligt stabil för det.

ZimaSpace-guiden om underhåll eller ersättning av Immich-databasen anger nästa gräns: vanliga storleks- eller prestandaproblem bör inte leda till en ombyggnad, medan upprepade integritets- eller återställningsfel kan motivera att en verifierad databas kopieras tillbaka.

Starta Immich först när PostgreSQL förblir friskt.

Kontrollera användare, tidslinje, flera originalfiler, album, sökning och en kontrollerad ny uppladdning. Om databasen startar men programfrågor konsekvent misslyckas ska du bevara de nya loggarna och fastställa om det nu aktiva problemet är schema-/versionskompatibilitet eller dataintegritet – inte ledigt utrymme.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Åtgärda orsaken till tillväxten och bevisa att systemet kan fyllas säkert igen

Mät vilken del som växte: vanliga databastabeller, kvarhållna WAL-filer, säkerhetskopior som lagras på samma volym, loggar, Docker-lager eller en oväntad sökväg. Om incidenten berodde på ett misslyckat arkiverings-/replikeringsarbetsflöde eller på att en annan tjänst skrev till databasvolymen ska du åtgärda den orsaken i stället för att bara öka kapaciteten.

Ställ in aviseringar långt innan volymen når den punkt där PostgreSQL inte längre kan skapa kontrollpunkter eller återställa sig. Övervaka både procent och absolut ledigt utrymme, eftersom en stor volym kan ha en liten andel ledigt utrymme men ändå tillräckligt med arbetsutrymme, medan en liten databasvolym snabbt kan bli riskfylld. Förvara databassäkerhetskopior utanför samma felgräns som de ska skydda.

Upprepa slutligen en normal uppladdnings- och bakgrundsbehandlingscykel, skapa en ny databassäkerhetskopia, starta om stacken och starta om värden. Ett godkänt resultat innebär stabil minskning av det lediga utrymmet, inga WAL-/återställningsfel, läsbara gamla och nya tillgångar samt en dokumenterad tröskel som utlöser åtgärder innan skrivningarna misslyckas igen.