There’s a new “feature” that shipped with ESX 2.5 – that’s the capacity to use a perl script to backup your VMs...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
from one ESX host (production) to another (backup). The script takes all the files that encapsulate a VM (virtual disk, log, vmx. Nvram), coverts them to a COW format (previously with a VMDK extension) on the source server, and then Secure Copies (SCP) them to the destination (backup) server. It utilizes the REDO file to allow on-line backups of a VM. Here’s how it’s done:
- Introduced with ESX 2.5 – two perl scripts named vmsnap.pl and vmres.pl
Backup all the files associated with VM – virtual disks, vmx, nvram, and log files
- It converts the monolithic virtual disk file into a COW format on a local partition – before transferring them to the archive server
- It can cope with any power state including powered on by setting the virtual disk to being undoable, creating a redo file, and a redo of the redo file. There is a -r switch to commit the redo file if it already exists
- There is a switch to force the system just to do a local backup
- VM must not have spaces in its names or directories
- Enough space to hold virtual disk in /vmimages – on BOTH source and destination
- Assumes a vmimages directory but you can specify alternative locations for local and remote backup directories using -f and -R switches for local and remote locations respectively
- IP communications between the servers and name resolution from a DNS server or Host File
- SSH Key Authentication Files on Source/Destination (archive server)
- There must not be a huge time gap between the servers
Setting up SSH Key Authentication ON EACH ESX Server
- Logon to the Service Console as ROOT
ssh-keygen -t dsa
ssh-keygen allows you to create public and private key pairs. -t allows you to specify the type of key you wish to generate, in this case a dsa key.
Accept the default location for the files and do not specify a passphrase. If you do you will have to type this in every time you run vm.
Check that the files have been created by using:
This should list all the files id_dsa and id_dsa.pub – the -la switch list all files, even ones that are hidden.
Copy your .pub file into an authorized_keys file with:
cp id_dsa.pub authorized_keys
You can check if this copy was successful with:
diff id_dsa.pub authorized_keys
To Test “local” authentication, type:
In my case, esxinstructor1.education.vmw and esxinstructor2.education.vmw
- Choose Yes to accept the key
Run, ssh yourservername again, to check you are NOT prompted for your user credentials again.
When you choose "Yes" – to these kind of prompts you’re accepting the identity of the server for the first time. These prompts get “cached” to a file called known_hosts. This file is located also in /root/.ssh – it is a text file. Entries should be removed, as when servers are removed or renamed
Setting up SSH Key Authentication BETWEEN EACH ESX Server
Copy the public key to each server using SCP like so:
scp /root/.ssh/id_dsa.pub firstname.lastname@example.org:/root/.ssh/id_dsa_esx1.pub
Here I am copying the .pub file from esxinstructor1, to esxinstructor2 renaming it on the way to include the name of the source server so it can be clearly identified. I reverse this command to copy esx2instructor pub file to esx1instructor.
Add the new .pub file to your list of authorized_keys with
cat /root/.ssh/id_dsa_esx1.pub >> authorized_keys
Verifying that SSH Authentication Works FROM EACH ESX Server
- You should be able to get to ssh servername without any prompts for login name
- You will have to choose Yes to add the host key to your list of known and trusted hosts
- But after that, an ssh session should be established
Backup with VMsnapl.pl
You can find out the syntax of vmsnap.pl by typing:
You can find a list of VMs, perhaps to confirm there are no spaces in the file paths with:
To start a backup type:
vmsnap.pl -a esxinstructor2.education.vmw
-a specifies the “archive” server, and -c specifies the vmx configuration file – which is how the script knows what virtual disks to backup
There also exists a vmsnap_all which backs up all the running virtual machines
System should respond with these status messages:
vmsnap: ‘esxinstructor2.education.vmwwas selected as the archive server.
vmsnap: VM config file is ‘/home/lavericm/vmware/server1/server1.vmx’
vmsnap: Disks found that are in use:
vmsnap: Disk found: scsi0:0 (local:server1.vmdk)
vmsnap: 1: scsi0:0
vmsnap: Creating the RedoLogs for cfg : home/vmware/server2/server2.vmx
vmsnap: scsi0:0:Adding REDO
vmsnap: Backing up the cfg : /home/lavericm/vmware/server1server1vmx
server1nvram 100% |*****************************|
server1vmx 100% |*****************************|
vmware.log 100% |*****************************|
To confirm the backup was successful
On the archive server, navigate to /vmimages/archivebackup/server1/
and check the files are thereâ€¦
Restoring a VM with VMrest.pl
For testing purposes, simply rename the VM and its Virtual Disk before doing a test restore.
To Restore the backup type:
vmres.pl -a esxinstructor2.education.vmw
-a specifies the archive server; -d specifies the location of the backup files, and -v tells the system to which VMFS partition can restore the virtual disk
-g to do a group of vms
-o to specify the owner of the imported disks/files
-p to power down the vm after restoring it