Free ESXi Backup Solution for Windows

[ChrisInTexas]

I have spent the last few days trying to find a free backup solution to the newly free ESXi for windows only enviroments (in particular Windows XP). The solution for me was the following:

1. Installing Windows Services for UNIX (WSFU)

2. Copying the ESXi Server password and group files to Windows

3. Configuring WSFU for accepting ESX Server connections

4. Sharing the Windows folder for NFS compatibility

5. Configuring the ESXi Server to mount the Window NFS Share as Datastore.

6. Setup Backup Script

Attached is the complete steps.

I take NO credit for any of this. This is just a complation of others work formated to suit my needs and felt others could benift from it as I have.

by Jason Mattox from Vizioncore (direct copy of his work, I just added more information to make it work in Windows XP)

(NFS Server port information)

by robink (The backup script)

(ssh on ESXi)

[solutiond]

Hi s1xth,

I'm falling behind due to other work that has come up but soon as I finish testing I'll add to this thread with all my findings, results and scripts.

Yeah your exactly right. kpc references a nfs share in his backup variable. Of cource, we don't want this as we want to scp to another esxi host. So yeah as a phase one test add your destination scp syntax in the backup variable.

Remember though, after you add and test your scp auth keys the backup variable will change as will need to add the certicate information.

sd

[webbmeister]

Thanks for the script - works well.

[ReverendJ1]

Khaliss, how are you able to restore a backup from NFS? What I have been doing is copying all files from the backup on my backup datastore, to my live datastore under a folder with the name of the VM. I then have to create a new VM and use that hard drive recovered from the backup. This works okay, but then I end up with two folders for the VM, i.e. VMServer & VMServer_1, and it doesn't keep any of the settings. Is there a way to just import the VM from the backup datastore?

[solutiond]

Hi Kpc,

Is a limitation with your script that you can only clone and therefore backup one vmdk file?

Anyone else have a script which clone muiltple vmdk files?

[lamw]

http://communities.vmware.com/docs/DOC-8760

Try this, supports multiple VMDK(s) and also it doesn't break up the VMDK into 2gb sparse files.

[kpc]

Hi solutiond

There's no reason why you can't do a vmdk export on multiple vmdk files, it's just another IF statement in the FOR loop - I just haven't got round to including it into my old script as I'm creating a new one at the moment.

Elazar wrote a script I seem to remember that allowed for two vmdk files, page 6 of this thread I think....

[elazar]

http://communities.vmware.com/message/1084212#1084212

I updated the script so that you no longer need to pass the vmid. Keep in mind that this script will only run on the ESXi host.

elazar

Edit: The script has been updated to pull file names and paths from vim-cmd...

[webbmeister]

We would prefer to shutdown the virtual machines, copy the vmdks then start up again.

Does anybody know an easy way of shutting down using a perl script. We have tried VMCONTROL.PL, but this fails to wait long enough for the machine to shutdown before reporting a failure. We have also tried VMWARE-CMD.pl, but the syntax on this is a little obtuse. Also, these commands won't accept spaces in names.

[lamw]

If you would like to shutdown your VMs and then backup, that is fine, there are many systems out there that cannot take an impact like that for backups.

Nonetheless, you can standard "vmware-cmd", if you have spaces or other odd characters in your displayName, first off, bad! ...I had to deal with VMs that had horrible naming convention and I think it's partly due to user's used to using spaces in Windows environment, you should use "underscores,dashes,etc" to seperate a name, especially in a UNIX environment. Anywho, all you need to do is redefine the IFS vairable in bash:

#!/bin/bash

IFS='\n'

for VM in `vmware-cmd -l`;

do

echo "$VM"

done

unset IFS

This simple example shows you that instead of looking at spaces as your deliminiter, you would redefine it as the newline, which would help protect against displayNames with spaces and the double quotes around the "VM" will help ensure you pass it to command you're looking for. So in your case you would do 'vmware-cmd "$VM" stop trysoft'. This will try to power down the VM gently as you would with a normal shutdown, else it’ll try to hard power it off. It also takes some time to power down a VM depending on the number of VMs you’re trying to power down and also if you’re doing this within the script, you can always do “getstate” and make sure it’s set to off. This should get you in the right direction

You probably dont' have to re-write a new script, there's plenty that people have already done, you can probably use the one I wrote or the other one that's floating on this thread.

[kpc]

some nice work there Elazar, not tried it out yet myself but did have a quick look, you say you don't need to enter the vmid's and datastores however you still have the env vars at the top:

backupDataStore=<backupdatastore>

vmsToBackup="VM1 VM2 VM3"

Am I missing something?

Also how do you get round the problem of getting the export to overwrite the existing one that's already there?

ta

[lamw]

He's just querying from vim-cmd to pull those values out, you still need it but he's just automating, assuming your old script required that as manual step. The problem with that still is you're doing that lookup each time you backup a new VM, that command is not a fast one. Also you guys should look at using the vmkfstools -i and not specifying the -d 2gb sparse file, it's more of a hassle to combine the VMDK where as you can just mount up the NFS volume and register the VMs and bring them online.

[kpc]

My old and new script uses vmware-cmd to pull out the names and locations of the VM's so you never had to manually enter anything, the downside to that is you have to use RCLI, the plus side if you have multiple ESXi servers in your environment you can properly schedule all backups to kick off one after another from the same controlling server, reducing disk contention and times. Ideally what I would like to see is a way you can use the vim-cmd command from the ESXi server to pull out the names and locations without having to manually update your backup script.

[lamw]

Check out this script, I haven't had time to clean it up but it does what you're asking for:

http://communities.vmware.com/docs/DOC-8760

1)

It can run on both ESX w/SC and ESXi with the caveat that you're running at least 3.5, but with some modification you can probably make it work up to 3.0.x

2)

It allows you to backup on any type of storage medium (LOCAL/SAN/NFS), so long as it's residing under /vmfs/volume

3)

Note on point #2, NFS still works because I'm mounting the volume as you would via the VMware VIC, which enables vmkfstools to function properly as it would under VMFS filesystem to copy VMDK's without breaking the backup's into multiple 2gb sparse files

4)

By utilizing vmkfstools vs scp/cp as you've realized it will not fragment your filesystem and this is the actual tool that should be used when moving VMware Virtual Machine disks

5)

Script can handle multiple VMDK(s), I guess your earlier revision of the script did not support that

6)

If you don't have persistent NFS volumes mounted, this script will check and mount them for you and you have an added option of unmounting once the backup has completed

7)

script can be cron'd on both on ESX w/SC and ESXi

😎

only configuration you have to do to the script is whether you want to use normal backup which requires you to give the FQDN path of your backup directory or non-persistent NFS backup which will require the NFS Server IP, exported path, datastore displayname and whether or not you want to unmount afterwards

9)

finally, the script just accepts a flat text file with the displayname of your Virtual Machines

Good luck

Also if you just want to backup ALL VMs either on your ESX w/SC or ESXi Server, then that is a pretty easy tweak to the code to always generate that list and pass it to the script. If you need help with that, I can give you the sample code that does that.

[elazar]

Thanks! You still need to specify the datastore to backup to(and the backup directory which is preset to YYYY-MM-DD) as well as the list of virtual machines to backup(if you wanted to backup all of them you could modify the script to just loop through all of the vm id's using awk and getallvms). The backup directory name is incremented by date(backupDirectory=$(date +%m-%d-%Y)), so you are never overwriting anything.

elazar

[elazar]

Granted vim-cmd is slow, but it is the only real way to get the information reliably. As far as the 2gbsparse format, this seems to be the preferred format when copying virtual disks to file systems other than VMFS, in fact, I believe VCB uses this same format. Basically, the formats are as follows:

Thick - This is the default format for ESXi, I believe it is only really supported on VMFS. Thick disks take up the amount of space allocated to the virtual disk, i.e. a 40GB virtual disk will equal a 40GB thick vmdk

Thin - This creates a disk based on the amount of space used on the disk, not based on what is actually allocated to the disk. In my experience, copying a thin provisioned vmdk over scp will result in a thick destination disk.

2gbsparse - This format creates multiple files up to 2GB in size, which in total are equivalent to the amount of space used on the virtual disk. I believe this is the format used by VCB and from what I have read, this format is not prone to fragmentation/corruption when cloning/copying virtual disks to other file systems like NTFS/FAT/EXT3 etc.

elazar

[lamw]

I agree vim-cmd is probably the most efficient way to pull out the data, but the comment is that you execute that command on every VM lookup, that is where the bottleneck is. In my script, I accept a list of VMs, you could make it all VMs, either way you’ll need to do the lookup as you know since VMware’s internal vimsh only uses the VMID after it’s been registered unlike traditional vmware-cmd where it passes in the .vmx configuration file. So I would recommend you dumping that output to a tmp file on each run so your lookups are faster.

In terms of the 2gb sparse, yes you’re correct VCB does implement that format but I still haven’t found a clear answer on why. From what I can find on the net, it all goes back to legacy systems that can’t read files that are larger than 2gb, this is probably a legacy Windows issue. VCB requires Win Server 2k3, so that limitation is out but I think there are other systems or utilities that can’t read files that are greater than 2gb, so this was implemented in case of that, I think. If anyone knows the actual answer, I would like to know.

Also to note on the fragmentation, I did not mean that the 2gb sparse would fragment more than doing a single vmdk copy but throughout this thread others were using standard UNIX cp and scp, which can fragment the filesystem as it’s not the right tool to use when dealing with VMware’s disk files.

[elazar]

"Also to note on the fragmentation, I did not mean that the 2gb sparse would fragment more than doing a single vmdk copy but throughout this thread others were using standard UNIX cp and scp, which can fragment the filesystem as it’s not the right tool to use when dealing with VMware’s disk files."

Thats why I went with 2gbsparse, it seems to play nicer with cp and scp. Keep in mind that the default thick format and the thin format are block level formats where as 2gbsparse is a file/stream level format...

[kpc]

nice script lamw thanks for that some nice options in there. Pretty much the same as what I did but everything is running from the server which I prefer in fact, since I'm going to be backing up around 10 or so ESXi server I need to be able to schedule each backup one after another so will look at running the script remotely, it also gives me the ability to send out completion/failure emails. I saw that you write the backups to a directory named from the VMID variable, is there any particular reason for this? I quickly changed this to the VM_NAME, makes it a little bit more readable, seems to be working ok.

The other problem I was thinking about looking at was performing safe backups, i.e not deleting the backup till a new one had successfully completed.

Good work ...

[lamw]

Hi kpc,

To answer you question about the naming, all my backups will create a directory which is the displayName for the Virtual Machine:

BACKUP_DIR=$/$ BACKUP_DIR=/vmfs/volumes/$/$

where VM_BACK_DIR is the full path of your backup selection and $i is just the name of the Virtual Machine, and the second line is for the non persistent NFS case, where we mount an NFS volume and "NFS_LOCAL_NAME" will be the datastore displayName and then again $i is just the name of the Virtual Machine

I think you might be referring to this line:

VM_ID=`grep "$" /tmp/vms_list | awk '{print $1}'`

If you look a few lines above you'll see that I actually accept a text file of VMs, that is read by a for loop and again, as you see I dump out all VMID at the very beginning to a tmp file so you can run lookups quicker and what I'm doing is verifying that I can find the VM and print out it's VMID, what I should also do is only check columen 2 since that is where the name should appear anyways, but yes, I'm not naming the directory the VMID but the actual displayName.

To your second comment, yea this was a quick script to get something working, we haven't been given the full specs on what the backups should be doing so right now it's just overriding since we're using our own personal storage to simulate these tests. I assume once it goes live, will be keeping x-amount of backups, I would like to see a few days if not a week if we can. The idea of not deleting until you've verified the backup is actually a good idea, perhaps if I get some time I'll modify the script and maybe allow to keep up to x-iterations of a given Virtual Machine

Thanks for the comments again, good luck

[JoSte]

@lamw: Nice script. It works, however I think the snapshot should be created from outside the loop like here in this code snippet:

cp $ $
VMDKS=`grep scsi $ | grep fileName | awk '{print $3}' | sed 's/"//g'`
echo "Taking backup snapshot for $ ..."
$ vmsvc/snapshot.create $ vcb_snap VCB_BACKUP_$_`date +%F` > /dev/null 2>&1
sleep 1
for j in $;
do
VMDK=$
vmkfstools -i $/$ $/$
done
sleep 2
$ vmsvc/snapshot.remove $ > /dev/null 2>&1

Else there is a new snapshot taken for each disk image, which may not be desired. I just added the sleep for giving the ESX some time to breath after each step. It might not be needed.

Maybe you want to change it that way on your page.

Regards