I'm backing up some Windows Server 2019 using wbadmin to some Synology-NAS using SMB. Once in a while the logs created during those backups mention that one of the created VHDX files gets compressed/compacted. The server is using German language for these logs and those use a term which means "compressing" actually, so not sure which of both is really done, but I strongly guess it means "compacting".
Looking at the logs, that process is pretty fast for C:\ most likely, which only contains Windows itself and some installed applications. Most of the data is stored on D:\ instead and that data contains some databases, plain files available using network shares, a VM and stuff like that. So there's quite some amount of I/O on that volume.
Looking at the logs of the last time that was done for D:\, I recognized two interesting things: 1. that process took around an hour to succeed and 2. the logs start at 30 % and stopped at 69 %. I know that it took around an hour because without compressing/compacting the backup finishes mostly around 22:45 o'clock.
Von Volume "Daten(D:)" wird eine Sicherung erstellt. Kopiert: (100%). Die virtuelle Festplatte für das Volume "Daten(D:)" wird komprimiert. Abgeschlossen: (30 %). [...] Die virtuelle Festplatte für das Volume "Daten(D:)" wird komprimiert. Abgeschlossen: (69 %). Ende Datensicherung 13.11.2019 23:59:36,66
So what happens during that process, especially in case of storing to SMB?
From my understanding, one needs to first know which blocks of the VHDX are not used anymore. Because there's NTFS inside that image, I guess Windows simply knows that and doesn't need to scan the file in some expensive process? After knowing which blocks are not needed anymore, those can be freed to actually reduce the storage needed for the VHDX. If it would sit on NTFS itself, I guess this would be done by unallocating blocks from some sparse file or would it really write 0s to the not needed blocks? However, the VHDX is accessed using SMB with BTRFS underneath, so most likely doesn't know about any spare file. So it might move blocks from the end of the file to allocated, but free blocks and simply trims the file afterwards?
If large amounts of data really need to be copied, that would explain why the process takes pretty long and why 30 and 69 % are logged only, that being the copied range of data inside the VHDX maybe or even only copying the data itself and other operations before and after 30 and 69 % are pretty fast again.
