Hur mycket lagringsutrymme för miniatyrbilder och maskininlärning behöver Immich för säkerhetskopiering av familjefoton?

Immich har ingen tillförlitlig lagringskvot enbart för miniatyrbilder, så familjebibliotek bör mäta genererade byte per objekt och reservera separat utrymme för ML-modeller.

Ett familjearkiv med foton på 2 TB säger inte hur stor Immichs miniatyrbildskatalog kommer att bli, eftersom antalet objekt, källupplösning, inställningar för miniatyrbilder, videomix och aktiverade modeller alla påverkar det härledda utrymmesbehovet. Den säkrare dimensioneringsmetoden är att bearbeta ett representativt urval, mäta miniatyrbilder och modellcache separat, beräkna bibliotekets tillväxt och sedan lägga till operativt utrymme i stället för att behandla en viss procentandel som ett universellt krav.

Separera original från Immich-genererad lagring

Börja med en tydlig avgränsning: originalfoton och videor är bara en del av det diskutrymme som krävs för ett Immich-bibliotek. Servern sparar också genererade objekt som används för bläddring och kompatibilitet, medan maskininlärningstjänsten sparar nedladdade modellfiler i sin egen cache. Dessa kategorier växer av olika orsaker, så om de slås ihop till en vag procentandel blir det svårt att se vilken inställning eller arbetsbelastning som faktiskt förbrukar utrymme.

En långvarig referens för storleksplanering i Immich-communityn noterar att miniatyrbilder och omkodad video tillsammans i genomsnitt kan lägga till ungefär 10–20 %. Den siffran är endast användbar som en övergripande riktlinje: den kombinerar två genererade kategorier och får därför inte presenteras som en kvot enbart för miniatyrbilder. En familj med främst foton och lite video kan hamna mycket annorlunda än ett arkiv med mycket video.

Arkitekturen spelar också roll när du avgör var det extra utrymmet ska placeras. ZimaSpaces genomgång av AI-baserad fotoorganisering behandlar indexering och genererade data som tjänster runt originalbiblioteket, inte som ersättningar för det. För kapacitetsplanering bör du hålla original, området för miniatyrbilder/förhandsvisningar, videoderivat, databas och ML-cache som separata poster även om de delar samma fysiska disk.

Mät kostnaden för miniatyrbilder per objekt innan du skalar upp

Välj ett representativt urval ur familjebiblioteket i stället för de tusen enklaste filerna. Det bör innehålla olika generationer av telefoner, kamera­upplösningar, porträtt, skärmbilder, panoraman och andra bildtyper som ingår i normal användning. Låt jobb som rör miniatyrbilder slutföras, registrera antalet bearbetade objekt och mät miniatyrbildskatalogen. Genom att dividera de uppmätta bytena med antalet bearbetade objekt får du en lokal planeringskvot som redan avspeglar dina valda inställningar för miniatyrbilder och förhandsvisningar.

Verkliga installationer visar varför den lokala kvoten spelar roll. I en Immich-diskussion rapporterades 21 GB miniatyrbilder tillsammans med 58 GB omkodad video i just det systemet. Siffran är anekdotisk och inget mål, men den visar att härledda kataloger kan ha väsentligt olika storlek och bör mätas separat i stället för att uppskattas utifrån originalbibliotekets terabytevolym.

Om exempelvis 10 000 representativa bilder ger 12 GB miniatyrbilder och förhandsvisningar är din uppmätta takt cirka 1,2 MB per objekt. Ett beräknat bibliotek med 60 000 bilder skulle då kräva ungefär 72 GB med samma inställningar, innan tillväxtmarginalen läggs till. Kör om urvalet efter att ha ändrat upplösning eller kvalitet för miniatyrbilder, eftersom sådana ändringar gör den gamla kvoten per objekt ogiltig även om originalfilerna inte har ändrats.

ML-cache beror mer på modeller än på antalet foton

Maskininlärningslagring fungerar annorlunda än miniatyrbilder. Modellcachen innehåller främst modellfiler som ML-tjänsten laddar ned och återanvänder, så dess utrymmesbehov styrs mer av vilka modeller för smart sökning och ansiktsigenkänning du väljer än av om biblioteket har 20 000 eller 200 000 foton. Bibliotekets storlek påverkar hur mycket bearbetning som sker, men kräver inte en ny kopia av modellen för varje objekt.

En aktuell självhostad Immich-installation beskriver en beständig modellcache som är monterad för maskininlärningstjänsten och uppger att modellerna där tog mindre än 1 GB totalt. Det gäller en konfiguration och är ingen garanti. Den viktiga mekanismen är beständighet och återanvändning: när de valda filerna väl finns på plats mångfaldigas inte modellbinärerna när antalet foton ökar.

För en familjeserver som kan byta modeller senare är det klokt att planera med en större reserv än den minsta cache som observerats för närvarande. En Immich-underhållare har föreslagit att lagring på omkring 10 GB i allmänhet räcker, beroende på modellval. Betrakta det som en konservativ startreserv snarare än ett krav och ersätt den sedan med den faktiska cachestorleken från din körande konfiguration efter att de första ML-jobben har slutförts.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Videomix och klientcache kan göra en uppskattning baserad på enbart foton missvisande

Uppskattningen för miniatyrbilder plus ML slutar vara en användbar beskrivning av den totala lagringen när biblioteket innehåller mycket video eller när du tittar på lokal lagring i enheten. Videokompatibilitet kan skapa stora serverbaserade derivat, medan cacheminnen i telefoner och webbläsare tar upp klientlagring som inte ingår i serverns miniatyrbildskatalog eller ML-modellcache. Om dessa siffror blandas ihop kan en normal uppskattning för miniatyrbilder verka orimligt felaktig.

En användarrapport från ett stort bibliotek visar gränsdragningen: ett bibliotek på ungefär 2,4 TB med 179 000 foton och 19 000 videor rapporterade 822 GB serverderivat för miniatyrbilder plus omkodad video, medan Android-appen dessutom samlade på sig tiotals gigabyte lokalt. Detta är en anekdot och ingen dimensioneringsregel, men det visar hur video och klientcache kan dominera en enkel modell baserad enbart på foton.

Håll kategorierna separata när du mäter: serverdata för miniatyrbilder/förhandsvisningar, omkodad video, ML-modellcache, databas och lokal klientcache. Om lagringen för miniatyrbilder verkar oväntat stor bör du granska själva miniatyrbildskatalogen i stället för hela Immich-dataträdet. Om omkodad video är den dominerande katalogen har den relevanta planeringsfrågan ändrats från omkostnad för fotoindexering till videokompatibilitet och policy för omkodning.

Använd en formel baserad på urval och tillväxt för familjelagring

Använd tre indata: uppmätta byte för miniatyrbilder per representativt objekt, beräknat antal bilder under de kommande ett till två åren och uppmätt storlek på ML-modellcachen. Multiplicera de två första värdena, lägg till modellcachen och lägg sedan till en operativ reserv för återskapande, ändrade inställningar och normal filsystemstillväxt. En reserv på 20–25 % är här en planeringsheuristik, inte ett krav från Immich; användare med små diskar bör mäta oftare i stället för att anta att reserven alltid räcker.

Ett konservativt tak för modellcachen kan utgå från underhållarens riktlinje att cirka 10 GB i allmänhet bör räcka beroende på modellval. Kombinera det med din egen mätning av miniatyrbilder, inte med siffran 10–20 % för miniatyrbilder plus omkodningar. För en beräknad miniatyrbildsvolym på 72 GB, en modellreserv på 10 GB och en reserv på 25 % blir den planerade reserven cirka 103 GB.

Räkna om när någon variabel som påverkar uppskattningen ändras: upplösning eller kvalitet för miniatyrbilder, ett stort skifte i kamera­upplösning, en annan ML-modell, kraftig videotillväxt eller en betydande ökning av antalet familjemedlemmar som laddar upp objekt. Beslutströskeln är enkel: om den beräknade genererade lagringen plus reserven närmar sig det lediga utrymmet på den avsedda snabba volymen bör du flytta sökvägen för derivat, lägga till kapacitet eller minska relevanta genereringsinställningar innan biblioteket når den nivån.