VMware workstation: Virtual Machine instance long-term storage (A 7-zip compression guide)

VMware + 7zip
VMware + 7zip

Do you want those big virtual machine (VM) instances stored for long-term storage? Well, if you are in the same boat as me (or you just wanted to find out what is the general difference between normal, maximum, and ultra 7-zip compression ratio and speed), I advise you to read on.

About this post: This post is driven by me being wanted to store a VM instance by using disk space efficiently. The compression study was inspired by Coding Horror’s post.

So I have this Windows Server 2012 virtual machine created as my IT playground and I wanted to save an instance of it in my drive so that when I do mess up my configurations, I can easily revert back into it. What should I do?

The first solution that will come into mind if you are using VMware workstation is to create a snapshot.

A VM snapshot (as personally defined by me) is a point in time checkpoint for your virtual machines. It means that if you have made a wrong move with your machine (like delete system files), you can easily revert back the VM snapshot as if nothing ever happened.

So I can just go and be trigger happy on snapshots right?

Short answer, no. Long answer, it depends mainly on:

  • Disk space
  • Disk speed (speedy read and write speeds)

VM snapshots can be easily created and managed in VMware workstation. However, according to my experience, they are harder to maintain since they take too much space in my disk drive. Also, I have read that VM snapshots are not mean for backups and could even slowdown the VM itself when there are too many snapshots created.

  • Is not meant to be a method of backup and recovery. If the files containing a virtual machine are lost, its snapshot files are also lost.
  • Negatively impacts the performance of a virtual machine. This is based on how long it has been in place and how much the virtual machine and its guest operating system have changed since the time it was taken. It is not recommended to run production virtual machines on snapshots on a permanent basis.

Heck, VMware does not even recommend to use snapshots as a backup method.

So in short, snapshots could potentially slow down your VM instance and should not be used as a backup method.

So which backup method should I use then?

There are backup tools VMware is recommending for enterprise users, but a hobbyist like me, I opt to use the crude redundancy via copy and paste.

But would that mean I would have to duplicate a large VM instance? I can’t afford storing a copy of a 30GB virtual machine. There must be another way right?

Yes. There is a way. Besides copying and pasting the VM instance folder in your local disk, you need to perform another step to further minimize its file size. For me, I opt to compress it using 7-zip. This is true specially on those instances which I wanted to preserve for a long time such as a point in time clean slate state of my virtual machines.

I get it. But which compression level should I use when compressing VM instances using 7-zip?

Now we’re talking. As of today (October 25, 2016), 7-zip have 2 upper bound compression levels (maximum and ultra) besides the normal compression level. One general rule to remember here is that the lower the compression level, the faster 7-zip can compress and decompress. The same is opposite whenever you choose a higher compression level.

I personally recommend to use the normal compression level for regular users.

Remember higher 7-zip compression levels can eat a lot of CPU, RAM, and disk utilization resources so keep an eye on your hardware before you use the higher compression levels.

But that’s just me. Will you just take my word for it?  Depends.

Now, let me present to you a simple experiment I made so that you guys can decide on yourself on which compression level you are to use when compressing your VMs.

The specs

First thing is first, here are the specs (c/o notebookcheck.net) of my machine (you can Google Asus G752VT for more info):

  • Processor: Intel Core i7-6700HQ 2.6 GHz  (4 cores, 4 logical processors)
  • Memory: 16384 MB , DDR4-2132 SDRAM, 1066.1 MHz, 15-15-15-36
  • Primary storage: Samsung PM951 NVMe MZVLV128, 128 GB (This is the OS drive and is not mainly used during the test)
  • Secondary storage: Hitachi HGST HTS721010A9E630 (where I installed 7-zip and saved the .7zips)

The data

And for the test data I have 25GB of data (27GB in disk size) (see below):

Windows Server 2012 virtual machine
Windows Server 2012 virtual machine

I ran the VM instance into three different compression levels (normal, maximum, ultra). Below are the results for your reference.

The results

Time to complete

Filetype Compression level Data to be compressed (MB) Estimated time to complete (mins) Variance (%)
7z normal 25973 30 0%
7z maximum 25973 38 27%
7z ultra 25973 40 33%

Compression speed

Filetype Compression level Speed (MB/s) Variance (%)
7z normal 14 0%
7z maximum 11 -21%
7z ultra 10 -29%

Compressed size

Filetype Compression level Estimated size (MB) Size variance (MB) Variance (%)
7z normal 6576 0 0%
7z maximum 6386 -190 -3%
7z ultra 6274 -302 -5%

Compression ratio

Filetype Compression level Compression ratio Variance (%)
7z normal 25.32% 0%
7z maximum 24.59% 3%
7z ultra 24.16% 5%

So which one to use? It’s up to you. With this data, I opt to use normal compression for VM instance backups. The additional 5% compression isn’t that much significant to me given that it would take another 10 mins to compress the instance using ultra compression.

How about you? Which one do you prefer? Share your opinion and lets discuss in the comments below!



Care to comment?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Powered by WordPress.com.

Up ↑

%d bloggers like this: