Hur mycket lagringsutrymme kräver Immich utöver källdatan?

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.

How Much Storage Overhead Does Immich Add Beyond Source Data?

Immich använder ingen universell lagringsprocent; overhead beror främst på antalet tillgångar, videomixen, inställningarna för härledda filer, databasens tillväxt och sparade säkerhetskopior.

Ett familjebibliotek på en terabyte som främst består av foton ser inte ut som ett bibliotek som främst består av långa mobilvideor. Planera lagringen genom att mäta varje genererad kategori efter en representativ import och reservera sedan separat utrymme för tillväxt, tillfälligt arbetsutrymme och återställningskopior.

Härledda medier utgör vanligtvis den största synliga overheaden

Immich skapar mindre bilder för tidslinjer och visning och kan skapa omkodade versioner av videor för kompatibel uppspelning. Dessa utdata skalar med antalet tillgångar, upplösningsval, kvalitetsinställningar samt videornas längd och kodekmix. De tillkommer utöver originalfilerna även när användarna aldrig hämtar dem direkt.

En mätning i communityn av ett externt bibliotek på 772 GiB rapporterade cirka 18 GiB miniatyrbilder och 65 GiB omkodad video. Observationen på ungefär 83 GiB är användbar som räkneexempel, inte som planeringskvot, eftersom en annan sammansättning av foton och videor samt andra inställningar kan förändra båda komponenterna avsevärt.

Registrera katalogerna för miniatyrbilder och omkodad video efter att ha importerat ett representativt urval som innehåller hushållets faktiska foton, RAW-filer, korta klipp och långa videor. Dela varje kategori av härledda filer separat med antalet tillgångar och källbyte. Tillgångsbaserade och bytebaserade kvoter besvarar olika frågor om tillväxt.

Databas och sökdata skalar med relationerna

Databasens overhead kommer från poster för tillgångar, användare, album, metadata, ansikten, sökrepresentationer, index och jobbstatus. En liten bild och en stor video kan skapa ungefär lika många poster av vissa typer trots mycket olika källstorlek. Därför är databastillväxt närmare kopplad till entiteter och aktiverade funktioner än till ursprungliga terabyte.

Den Immich-artikel om säkerhetskopiering från ZimaSpace skiljer viktiga original och databastillstånd från härledda sökvägar som kan återskapas. Den åtskillnaden är viktig vid prognoser, eftersom borttagning av härledda filer kan frigöra utrymme tillfälligt, medan en förlorad databas innebär att relationer går förlorade och inte kan återskapas av miniatyrbilder.

Mät databasens storlek före och efter import av en känd grupp och notera vilka bearbetningsfunktioner som har slutförts. Upprepa mätningen när ansikts- och sökbearbetningen är klar. Dra inte slutsatser från en ofullständig kö, eftersom den synliga overheaden per tillgång ökar när ytterligare representationer och relationer skrivs.

Säkerhetskopior och tillfälligt arbete förändrar den nödvändiga kapacitetsnivån

En löpande totalsumma utesluter det utrymme som behövs när säkerhetskopior skapas, databaser dumpas, importer förbereds eller härledda filer ersätts. Under en uppgradering eller återskapning kan gamla och nya artefakter finnas samtidigt. En disk som dimensionerats exakt efter användningen i stabilt läge kan därför misslyckas under normalt underhåll, även när den årliga medietillväxten är måttlig.

En artikel om lagringsplanering beskriver hur Immich fyllde en tidigare ledig SSD genom original, miniatyrbilder, metadata och maskininlärningsarbete. Den bredare lärdomen är att applikationstillväxt och återställningskopior konkurrerar med driftsmässigt reservutrymme. En uppgift om ledigt utrymme måste därför täcka det mest belastande underhållsläget, inte dagens inaktiva tillstånd.

Håll kvarhållning av säkerhetskopior som en separat post, eftersom kopior utanför värden skyddar mot en annan typ av fel. Reservera också en uppmätt arbetsmarginal baserad på det största import-, omkodnings- eller uppgraderingstestet. Mer oanvänt utrymme är inte automatiskt bättre, men en nollställd uppmätt toppmarginal gör kapacitetsbrist förutsägbar.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Skapa ett biblioteksspecifikt kalkylblad för overhead

Skapa rader för original, miniatyrbilder och förhandsvisningar, omkodad video, databas, maskininlärningsartefakter, lokala säkerhetskopior av databasen och tillfälligt topputrymme. Mät ett tomt grundläge och importera sedan en representativ grupp. Vänta tills köerna har tömts och registrera varje rad igen innan du beräknar skillnaderna.

En diskussion bland användare om placering på SSD och HDD skiljer latenskänsliga genererade data från stora mängder original. För kapacitetsplanering gör den skillnaden att overheaden på den snabba lagringsnivån förblir synlig även när originalen ligger någon annanstans. Annars kan den stora NAS-totalen dölja en nästan full applikations-SSD.

Upprepa gruppen en gång för att få ett intervall i stället för en enda kvot. Prognostisera varje rad utifrån rätt drivkraft: antal tillgångar, videobyte eller videolängd, tillväxt av användare och relationer, antal sparade versioner eller maximalt underhållsarbete. Lägg till planerad källtillväxt först när behovet av härledda filer och återställning syns separat.