This article was originally published in 2010. It is preserved as part of the site’s technical history, so some products, links and procedures may no longer be current.
The problem
In an effort to automate backups of some of my VMWare ESXi virtual machines, I configured a Windows Services for Unix (WSFU) share as a datastore, and set up GhettoVCB to backup the machines to the share. The problem that I discovered with this approach is that WSFU does not retain the “thin” provisioning the virtual machines were built with. My example vm was a 40GB installation of Ubuntu 10.04 (highly recommended).
A solution
A solution that I arrived at was to simply enable Windows compression on the share itself. This is accomplished simply by right-clicking on the shared folder, click Advanced, check Compress contents to save disk space, then OK.
The only downside I could see with this approach (besides it being a bit kludgy) was that the backup would take longer. This would not be a big deal to me as the backups occur in the dead of night and would be complete long before I would be on the machines. The plus would be it should take up space very equivalent to that on the VMFS datastore, if not less.
The rest of the post details my observations working with the Ubuntu virtual machine.
The before numbers
The virtual machine uses 13.5GB of the provisioned 40GB. The backup took 27 minutes to complete before compression. The CPU utilization on the Windows machine hovered around 40% (this is an older, single-core).
After enabling compression
The CPU utilization was much higher during the backup with compression on. It ranged between 73 and 95%.
Surprising to me, the new job didn’t take much longer at all. The backup ran for 28.72 minutes, less than two minutes longer than the previous job, and resulted in a file size of just 8.25GB. Not a bad trade-off at all.
What I did find was strange, though, was the filesizes of two folders I had created prior to compressing. When I flipped the compression setting to on, Windows did its thing on the existing data. The folders compressed down to 7.33GB. The vmdk was exactly the same. A higher level of compression must be possible on closed files than on data being compressed on the fly. It is not a problem for me at all, it just seemed an interesting tidbit.
In summary, if you are using a WSFU storage device for your backups, turning folder compression on is definitely worth your effort.
Leave a Reply