Hoeveel extra opslagruimte voegt Immich toe boven op de brongegevens?

Immich hanteert geen universeel opslagpercentage; de overhead hangt vooral af van het aantal assets, de videomix, instellingen voor afgeleide bestanden, databasegroei en bewaarde back-ups.

Een familiebibliotheek van één terabyte die voornamelijk uit foto’s bestaat, ziet er heel anders uit dan een bibliotheek die voornamelijk uit lange telefoonavideo’s bestaat. Plan de opslag door elke gegenereerde categorie na een representatieve import te meten en reserveer vervolgens aparte ruimte voor groei, tijdelijk werk en herstelkopieën.

Afgeleide media vormt meestal de grootste zichtbare overhead

Immich maakt kleinere afbeeldingen voor tijdlijnen en viewers en kan gecodeerde versies van video’s maken voor compatibele weergave. Deze uitvoer schaalt mee met het aantal assets, de resolutiekeuzes, kwaliteitsinstellingen en de duur of codec-mix van video’s. Ze komen boven op de oorspronkelijke bestanden, ook wanneer gebruikers ze nooit rechtstreeks downloaden.

Een meting door de community van een externe bibliotheek van 772 GiB rapporteerde ongeveer 18 GiB aan miniaturen en 65 GiB aan gecodeerde video. Die observatie van ongeveer 83 GiB is nuttig als uitgewerkt voorbeeld, maar niet als planningsratio, omdat de foto-videomix en instellingen van een andere bibliotheek beide componenten aanzienlijk kunnen veranderen.

Registreer de mappen met miniaturen en gecodeerde video nadat je een representatief deel hebt geïmporteerd met de echte foto’s, RAW-bestanden, korte clips en lange video’s van het huishouden. Deel elke categorie afgeleide bestanden afzonderlijk door het aantal assets en door het aantal bronbytes. Verhoudingen op basis van assets en bytes beantwoorden verschillende groeivragen.

Database en zoekstatus schalen mee met relaties

Database-overhead komt voort uit assetrecords, gebruikers, albums, metadata, gezichten, zoekrepresentaties, indexen en taakstatus. Een kleine afbeelding en een grote video kunnen voor sommige records vergelijkbare aantallen opleveren, ondanks hun sterk verschillende bronformaten. Daardoor hangt databasegroei nauwer samen met entiteiten en ingeschakelde functies dan met de oorspronkelijke terabytes.

Het Immich-back-upartikel van ZimaSpace maakt onderscheid tussen essentiële originelen en databasestatus enerzijds en afgeleide paden die opnieuw kunnen worden opgebouwd anderzijds. Dat onderscheid is belangrijk bij prognoses: het verwijderen van afgeleide bestanden kan tijdelijk ruimte vrijmaken, terwijl verlies van de database relaties verandert die miniaturen niet kunnen reconstrueren.

Leg de databasegrootte vast vóór en na het importeren van een bekende groep en noteer welke verwerkingsfuncties zijn voltooid. Herhaal dit nadat het gezichts- en zoekwerk is afgerond. Extrapoleer niet vanuit een onafgeronde wachtrij, want de schijnbare overhead per asset neemt toe zodra aanvullende representaties en relaties worden weggeschreven.

Back-ups en tijdelijk werk veranderen de minimale capaciteit

Een lopend totaal houdt geen rekening met de ruimte die nodig is tijdens het maken van back-ups, het dumpen van databases, het klaarzetten van imports of het vervangen van afgeleide bestanden. Tijdens een upgrade of hergeneratie kunnen oude en nieuwe artefacten naast elkaar bestaan. Een schijf die precies op het gebruik in stabiele toestand is afgestemd, kan daarom tijdens normaal onderhoud vollopen, zelfs wanneer de jaarlijkse mediagroei beperkt is.

Een essay over opslagplanning beschrijft hoe Immich een eerder ongebruikte SSD vulde met originelen, miniaturen, metadata en machinelearningwerk. De bredere les is dat applicatiegroei en herstelkopieën concurreren om operationele speelruimte. Een vrijeruimtecijfer moet daarom de drukste onderhoudssituatie dekken, niet alleen de huidige inactieve toestand.

Houd de bewaartermijn van back-ups als een afzonderlijke post bij, omdat kopieën buiten de host bescherming bieden tegen een ander type storing. Reserveer ook een gemeten werkmarge op basis van de grootste import, hercodering of upgradetest. Meer ongebruikte ruimte is niet automatisch beter, maar een marge van nul tijdens piekbelasting maakt capaciteitsproblemen voorspelbaar.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Maak een overheadwerkblad voor jouw bibliotheek

Maak regels voor originelen, miniaturen en previews, gecodeerde video, de database, machinelearningartefacten, lokale back-updumps en tijdelijke piekruimte. Meet een lege beginsituatie en importeer daarna een representatieve groep. Wacht tot de wachtrijen zijn verwerkt en leg elke regel opnieuw vast voordat je verschillen berekent.

Een discussie onder gebruikers over de plaatsing van SSD en HDD maakt onderscheid tussen gegenereerde gegevens die gevoelig zijn voor latentie en bulk-originelen. Voor capaciteitsplanning zorgt dat onderscheid ervoor dat overhead op de snelle opslaglaag zichtbaar blijft, ook wanneer de originelen elders staan. Anders kan het grote NAS-totaal verbergen dat een applicatie-SSD bijna vol is.

Herhaal de groep eenmaal om een bereik te krijgen in plaats van één verhouding. Prognosticeer elke regel met de juiste drijfveer: het aantal assets, videobytes of -duur, groei van gebruikers en relaties, het aantal bewaarde kopieën of piekwerk tijdens onderhoud. Voeg geplande groei van de bron pas toe nadat de behoeften voor afgeleide bestanden en herstel afzonderlijk zichtbaar zijn.