Wesley Levels's Blog

I was checking for a good back-up solution for my ESXi VM’s, because of the lacking Exchange-aware back-up solution in Windows Server 2008. I checked some 3rd party solutions, but wasn’t exactly convinced.
I then came by a VMWare thread with a back-up solution using a script on your ESX(i) server, automatically creating a live (or offline) back-up of one or more VMs.
The script has it’s pros and cons, like:

Pros:

• Free.
• Back-up at the top layer, you can restore a back-up to another ESX(i) server without any problems and without the need to manually creating a second VM or anything.

Cons:

• If using the script for exchange, it’s not possible to restore specific e-mails or users. You could restore a back-up next to the “original” VM, and restore e-mail or users, however that won’t be an efficient way of a restore.
• Had some problems with using compression. It’s no problem using compression with the script, worked like a charm. However I wasn’t able to restore the VM. I’m sure I’m doing something wrong. Couldn’t figure it out in the spare time I had. Will get into it, and update this post with my findings.
• Using compression will use pretty some CPU resources. I personally don’t mind this, because my experience with Virtualization servers are that the CPU isn’t used that much. Most of the time the limit of a Virtualization Server is reached by the amount of memory in the Virtualization Server.
• When using compression to save space on your back-up volume, you will need enough space for the script to store the uncompressed back-up. The script will clone the VM(s) and put them on the back-up volume. When cloning is complete the script will compress the newly created uncompressed clone. When a second clone (compressed) is created from the first (uncompressed) clone, the uncompressed clone will be removed and the compressed clone will stay at your given back-up location.

I won’t get into the installation or anything of the back-up script, because there’s a great how-to at the VMWare thread from the actual owner of the script.

Check this link for the script itself and some FAQs and how-to for using the script

There’s also a thread with a restore script for restoring back-ups made with the back-up script. This is just a script to automate things. You could also just restore manually.

Check this link for the restore script

Something the thread lacked (or I didn’t saw this) was some performance data. I did some testing with offline and live back-ups and the following were the results:
(Just for the record, I will state my ESXi config because the performance data can be different on ESX(i) configurations with different hardware)

• ASUS P5Q-VM Mainboard
• Intel Q6600 Core 2 Quad
• 8GB PC6400 DDR2 Kingston memory
• Intel PRO 1000PT Network adapter
• 3WARE 9650SE-2LP
• 2x 1TB Samsung Spinpoint F1 HD103UJ drives for the 3WARE RAID
• 1x 1TB Samsung Spinpoint F1 HD103UJ drive
• 1x old SATA1 drive for testing purposes

I made back-ups from VMs on the third SATA2 drive (no raid) to the fourth drive (SATA1 no raid), and restored back to the SATA2 (no raid) drive because of space limitation on the RAID configuration.

ESXi CPU usage; (7 VMs running) +/- 350 Mhz = 5%
ESXi CPU usage; during backup/restore +/- 800 Mhz = 10%
ESXi CPU usage; during backup compressing/restore uncompressing +/- 2600 Mhz = 30%

I tested the scripts only with one VM for now. It was an Ubuntu Nagios VM with one VHDD (+/-10GB)

ESXi backup uncompressed; 2,9 mins cloning disk, 4 mins total
ESXi backup compressed; 2,9 mins cloning, 19 mins compressing, 22 mins total.

The compression was nice, the back-up was 1 GB after compression. 10% of the original size. However this can differ for each VM.

ESXi restore uncompressed; 3 mins total
ESXi restore compressed; Couldn’t get it to work for now, however, I timed uncompression, it was 6 mins, and the move from the SATA1 “backup” drive to the SATA2 “operational” drive was about 1 min.

If you could do some guessing, you could say:

• 10GB VM = 4 minutes
• 50GB VM = 20 minutes
• 100GB VM = 40 minutes
• 200 GB VM = 80 minutes (1 hour and 20 minutes)
• 250 GB VM = 100 minutes (1 hour and 40 minutes)

Note: between offline back-up and live back-up is no difference in performance or anything. Your VM can stay on while processing the live back-up. I did not notice any delays on the VM while doing a live back-up, however, my testserver is just a Nagios Monitoring server
When making a live back-up, your ESX(i) server will create a live snapshot and the script will use the snapshot to create the back-up. Afterwards the snapshot will be deleted by the script.

The tests I made are pretty basic. This is the first part of this post. I will check the problems I had while manually restoring compressed back-ups. I will update this post when I have the time to test scripts some more!

UPDATE:

I found out that the default config isn’t good enough for (most) Exchange servers. The ghettoVCB script will attempt to shutdown your VM(s) using the installed VMWare Tools. It will then check for 5 minutes (5 times every 60 seconds) if the VM is shut down, and perform the back-up. If the server isn’t offline after 5 minutes (5 checks), the script will ignore the specific VM.
My exchange server (and pretty much every Exchange server I think) won’t make it to shutdown in 5 minutes. My exchange takes about 10 minutes to shutdown.

I changed  the “POWER_DOWN_TIMEOUT=*” value from it’s default (5) to 15, allowing every VM to have a shutdown time of 15 minutes.