• Login
• Become a member
• RSS
• Part of the TechTarget network

There’s a new “feature” that shipped with ESX 2.5 – that’s the capacity to use a perl script to backup your VMs 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:

Notes:

• 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
• Requirements:
  
  • 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

1. Logon to the Service Console as ROOT

2. Type:

   ssh-keygen -t dsa

   Note:
   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.

3. Check that the files have been created by using:

   cd /root/.ssh
   ls -la

   Note:
   This should list all the files id_dsa and id_dsa.pub – the -la switch list all files, even ones that are hidden.

4. Copy your .pub file into an authorized_keys file with:

   cp id_dsa.pub authorized_keys
   
   Note:
   You can check if this copy was successful with:

   diff id_dsa.pub authorized_keys
    

5. To Test “local” authentication, type:

   ssh yourservername

   Note:
   In my case, esxinstructor1.education.vmw and esxinstructor2.education.vmw

6. Choose Yes to accept the key

7. Run, ssh yourservername again, to check you are NOT prompted for your user credentials again.

   Note:
   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

1. Copy the public key to each server using SCP like so:

   scp /root/.ssh/id_dsa.pub root@esx2instructor.education.vmw:/root/.ssh/id_dsa_esx1.pub

   Note:
   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.

2. 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

1. You can find out the syntax of vmsnap.pl by typing:

   vmsnap.pl -m
    

2. You can find a list of VMs, perhaps to confirm there are no spaces in the file paths with:

   vmsnap.pl -g
    

3. To start a backup type:

   vmsnap.pl -a esxinstructor2.education.vmw
   -c /home/lavericm/vmware/server1/server1.vmx

   Note:
   -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

   Note:
   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% |*****************************|
    

4. 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
Note:
For testing purposes, simply rename the VM and its Virtual Disk before doing a test restore.

1. To Restore the backup type:

   vmres.pl -a esxinstructor2.education.vmw 
   -d /vmimages/archivebackup/server1 
   -v local

   Note:
   -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

   Also supports:
   
   -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

Join the conversationComment

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.