Så konfigurerar du cache och tillfällig lagring i Immich

Konfigurera Immichs cache och tillfälliga lagring genom att först separera beständigt bibliotekstillstånd från genererade derivat, återanvändbar modellcache och verkligt tillfälliga skrapdata i containern.

Miniatyrer och kodade videor kan uppfattas som cache eftersom Immich kan återskapa dem, men de är beständiga arbetsresurser som kan bli stora och dyra att bygga om. Modellnedladdningar har en annan livscykel, medan loggar och skrapdata i det skrivbara lagret inte i tysthet bör förbruka startdisken. Tilldela lagring efter funktion och testa sedan rensning och omstarts­beteende.

Klassificera varje lagringsfunktion innan du flyttar den

Skapa en inventering med minst fyra klasser: original och nödvändigt programtillstånd; genererade miniatyrer och förhandsvisningar; genererade kodade videor; samt modell-, logg- eller tillfälliga kördata. Ange för varje klass aktuell sökväg, storlek, tillväxttakt, säkerhetskopieringspolicy, kostnad för att bygga om och vilken tjänst som skriver dit.

En användarrapport om tillväxt av genererade miniatyrer och videor visar varför miniatyrer och kodad video behöver mätas separat. Enskilda kvoter är inte universella, eftersom mediemix och bearbetningsinställningar påverkar mängden som produceras.

Märk inte en katalog som ”cache” enbart för att det frigör utrymme att radera den. Om förlusten leder till dagar av återskapande, bryter aktiv uppspelning eller tar bort tillstånd som din återställningsplan förutsätter ska bevaras, förtjänar den en uttrycklig beständig roll även om programmet tekniskt kan återskapa den.

Placera genererade data med hög förändringstakt där latens och uthållighet passar

Miniatyrer och förhandsvisningar används vid interaktiv bläddring och innebär ofta många små läsningar, medan kodade videor kan kräva betydligt större sekventiell kapacitet. En snabb SSD kan förbättra aktiviteter som använder mycket derivat, men bara om flytten av funktionen avlägsnar den uppmätta väntetiden i stället för att skapa ännu en liten volym som oväntat blir full.

Förklaringen av tillväxt av miniatyrlagring på ZimaSpace ger en överförbar lagringslärdom: aktiv applagring kan bli full även när originalen finns någon annanstans. Immichs specifika sökvägar skiljer sig, men kravet på att övervaka den faktiska skrivbara funktionen är detsamma.

Om stora mängder media ligger på HDD- eller NAS-lagring medan derivat flyttas till SSD ska du övervaka ledigt utrymme på båda nivåerna och verifiera varje montering efter omstart. En snabb derivatnivå är bara användbar när den är tillräckligt stor för normal tillväxt och ett fel där inte kan misstas för att de auktoritativa originalen har gått förlorade.

Beständiggör modellcachen medvetet men behandla den som återskapningsbar

Maskininlärningsmodeller laddas ned eller förbereds för upprepad inferens och kan ta upp betydande lagringsutrymme. Genom att beständiggöra modellcachen undviker du onödiga nedladdningar och startarbete, särskilt vid långsammare anslutningar, men den bör inte förväxlas med databasen eller familjens original i återställningshierarkin.

En communitydiskussion om Immichs lagringsarkitektur visar varför administratörer separerar snabb, cacheliknande data från storskalig fotolagring. Använd sådana layouter endast som exempel och verifiera aktuella sökvägar och monteringar i din egen Compose-definition innan du flyttar något.

Om modellcachen går förlorad är den normalt acceptabla återställningen att skapa om eller ladda ned den igen, förutsatt att tjänsten kan nå den nödvändiga källan och har tillräckligt med diskutrymme. Dokumentera detta beteende så att ett säkerhetskopieringsverktyg inte av misstag använder begränsad extern kapacitet för att skydda en stor återskapningsbar cache.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Begränsa skrivbara lager, loggar och skraputrymme

Skrivbara lager i containrar bör inte bli ett odokumenterat hem för beständiga derivat, tillfälliga omkodningar eller stora loggar. Kontrollera Dockers diskanvändning och containermonteringar så att varje stor växande sökväg antingen beständiggörs medvetet eller avsiktligt är tillfällig. En oförklarad ökning i det skrivbara lagret är ett konfigurationssymptom, inte något som automatiskt ska rensas.

Arbetsflödet från Docker HQ från 2026 för säker rensning av Docker-disk betonar granskning före beskärning och skydd av volymer som kan innehålla databaser. Tillämpa samma försiktighet här: kör aldrig generella rensningskommandon på en produktionsvärd för Immich innan du känner till ägarskapet för varje volym och lager.

Ställ in loggrotation, placera skrapsökvägar på lagring med tillräcklig marginal för tillfälliga toppar och övervaka även inode-användningen när många små filer skapas. Om en tillfällig sökväg blir full är den korrekta lösningen att begränsa eller flytta funktionen, inte att radera okända kataloger tills programmet råkar starta.

Validera lagringsändringar med tester av omstart, ombyggnad och ledigt utrymme

Efter att du har ändrat sökvägar ska du öppna gamla och nya resurser, bläddra i flera album, spela upp en video, köra ett miniatyr- eller maskininlärningsjobb och ladda upp en kontrollerad ny fil. Bekräfta att skrivningar hamnar på avsedda enheter och att databasen fortfarande hänvisar till läsbara medier.

Starta om containrarna och därefter värden. En fungerande konfiguration monterar varje funktion automatiskt igen, behåller förväntade derivat och modellcache, håller skrapdata tillfälliga och rapporterar tillräckligt med ledigt utrymme på varje aktiv nivå. Övervaka lagringen under ett normalt arbetsbelastningsfönster för att bekräfta att tillväxten uppstår där den planerats.

Återställ en sökvägsändring om Immich skapar dubbla kataloger, rapporterar saknade resurser eller i tysthet skriver till containerlagret eftersom en montering misslyckades. Eskalera med monteringskartor, sökvägsstorlekar, ägarskap, ledigt utrymme i filsystemet, containerns diskanvändning och det exakta jobbet som först skrev till fel plats.