Varför så mycket lagring?

Du motsäger dig själv lite, om inte "enbart det man vill ska finnas på miljön" är väldigt stort.
Throwaway webserverimages jag skapar ligger fortfarande på 60 GB för Windows och 20 GB för Linux, och är generellt sett tunt provisionerade, så verklig diskanvändning ligger ofta runt 15 GB för mina Windows-VM:ar (vanlig Core - 20-25 GB för dem som av någon anledning behöver köra Desktop Experience) och storleksordningen 8-10 GB för Linux.

Om man inte behöver spara innehållet från varje miljö utan bara behöver ett skelett att fylla med testdata är något som exempelvis Ansible en bra genväg till mindre diskanvändning: Miljöer jag inte använder består av en VM-template på ett arkivområde som kan läsas av min hypervisor, en katalogstruktur med textfiler (Ansibleroller/-playbooks) i git, plus ett filområde för eventuella installationsfiler som kan behövas av de olika rollerna.

Men naturligtvis: Har du behov av att köra multipla stora miljöer för multipla samtidiga kunder så är det ju bara den verklighet du lever i.

Jo, det är ju sant - vilket iofs inte hindrar att man gärna besparar sig jobbet att sätta upp infrastrukturen på nytt om man självhostar den.

Om man kör KVM i linux-miljöer kan kika på https://www.anteru.net/blog/2020/qemu-kvm-and-trim/

Linux/unix använder sig av sparse-filer även för sina VM-miljöer och ovanstående gör att dessa 'thin' provisioned VM-filer växer och krymper i upptagen diskutrymme på värddatorns filsystem beroende om OS: inne i VM skriver filer eller raderar filer då om OS (tex. windows) använder TRIM/unmap när den raderar filer så kommer det göra samma sak med VM-filen att den minskar i allokerad utrymme på disken genom att göra sparse-sektorer av de sektorer som man gjorde 'unmap/TRIM' på i VM-maskinen.

Hemligheten för att det skall funkar (och några parametrar i VM-maskinen sätts som discard och zero i SCSI-kortadaptern ) är att windows tycker sig ligga på en SCSI-disk och då börja använda sig av 'unmap' vid radering av filer som är en SCSI-kommando som tex. skickas över iSCSI på en SAN att den här bunten sektorer används inte längre och SAN bakom kulisserna minskar då på iSCSI-imagens diskförbrukning genom att göra 'punch holes' på diskimagen och helt enkelt omvandla icke använda sektorer till sparse-segment (som är virtuella sektorer med bara värdet '0' i sig) som inte finns på diskytan och utrymmet frigörs för andra processer.

med VM-maskin gör man på samma sätt som i en SAN fast man gör det på den virtuella VM-imagen

det som många åker på vid kopiering av sparse-files är att när man kopierar över till annan lagring så sker en 'ballooning' - dvs filen blir fullskriven där även tom-utrymme med bara '0' skrivs ned på den mottagade disken vilket händer med 100% om kan kopierar via windows kopiering då windows helt enkelt inte stöder hanterande av sparse-filer även om NTFS gör det.

kort sagt man måste i princip använda Unix/linux-kommando och i linux-miljö för kopieringen med flagga '--sparse' och om man vill konvertera uppblåsta filer till sparsefiler igen med '--sparse=always'

har man hela träd med diskimages och VM-images som har stora områden med '0' (vilket ofta är om dessa är tagna från SSD/NVMe då raderade områden efter filborttagning och körts TRIM på av OS och efter detta läses sektorerna ut som innehållande bara '0' )

Så kan man prova med 'rsync -avxWSHAXI . .' så går den rekursivt från där den står och ned i filträdet och gör alla filer den ser till sparse-versioner om möjligt med bibehållande av alla tidstämplar och rättigheter.

på diskimages kan det spara mycket plats på lagringen - och det spar plats även på filsystem med kompression då områderna med bara '0' skrivs inte på disken alls över huvud taget och heller inte behöver komprimeras med blockindelning och kompressions-headrar, som också tar plats - det kan vara över 5 GB per TB som sparas för att man inte komprimerar '0'-sektorer mha. sparse-filer i ett komprimerade filsystem som med BTRFS med kompression påslagen.

observera att ovanstående görs på egen risk och efter prov då det kan finnas VM-format som inte tål att bli 'sparse' och måste expanderas fullt ut igen för att fungera rätt i tex. en VM-maskin.

sparse-fil har dock samma hashvärde som orginalet som den skapades ifrån så filen är inte ändrad - bara att alla sektorer med enbart '0' aldrig skrivs till diskytan utan hanteras i filsystemets metadata enbart.

Eller så är man tvärtom
https://xkcd.com/598/
"can you try to look ... blockier"