Efficient, Portable and Extensible Back up of VMs - Page 2

Just like the data they process, virtual machines should be backed up and stored regularly to avoid having to redo all of your work, writes Kamalkumar Mistry of Infosys Labs.

Print Article

Service instance

We define service instance as a set of VMs having a set of specific software products and applications already installed. A running service instance provides a specific service to the specific set of users. The number of VMs in a service instance varies and keeps changing during runtime based on service level agreements (SLAs) and the number of user requests the service is handling from time to time.

An example of the service instance can be a set of VMs hosting an application server in a virtualized environment. As part of this service instance, one or more application engines, a load balancer, request scheduler and other supporting software may be running in one or more than one virtual machines at a time. The information about the service instance, such as name, ownership information, target environment information, temporal information and the information about all the VMs that belong to the service instance is stored either in database or in form of a metadata file (preferably an XML document) or in both.

The following section describes the procedure to back up the service instances and restore backed up service instances. The procedures are explained in form of two algorithms, each for respective operations.

Taking a back up of service instance

Once a service instance is created and configured, it is advisable to take a back up of it and store it as a master copy outside the virtualized environment. Taking periodic back ups is also equally important. The master copy of the service instance and the periodic back ups are very helpful to quickly recover from unwanted situations, which can be:

  • Datacenter crash due to natural calamities or human activities.
  • Moving to a different virtual infrastructure provider.
  • One or more VM crashes or VM file system get corrupted in the service instance.

It is very important to have the back up not tied to any particular hypervisor or processor architecture. The back up should be done periodically without disturbing the running service instance. Such requirement can best be served by taking back ups in form of OVFs, since OVF is independent of any hypervisor or processor architecture.

We propose the following algorithm for efficient backup mechanism in the VMware environment, but the same can be applied to other virtualization platforms also based on the availability of the features needed for the OVF backup:

Algorithm-1: Backup Service Instance


For each VM in the service instance, repeat steps 2 and 3.


If (VM is not a template and VM power state is “Powered On” or “Suspended”)




1.     Convert the running VM into a template (since it is not possible to export OVF of a running VM in a VMware environment).

2.     Export the OVF of the VM template to the target location.

3.     Delete the template after the OVF got exported successfully.


else if (VM is a template or VM power state is “Powered OFF”)


1.     Export the OVF of the VM template to the target location.


end if


Update the information for the backed up VM such as user name, VM name, target location, time, backup version number and other custom information into the service instance metadata.


Export the service instance metadata to the target backup location. The same will be used at the time of restoring the service instance.

Restoring backed up service instance

The following algorithm describes the steps for restoring the backed up service instance to the target virtualization environment.

Algorithm-2: Restore Service Instance


Let user specify the version number of the service instance to be restored from the available backup versions.


From the service instance metadata, find out the previous backup information and check the existence of OVFs corresponding to all the VMs in the service instance.


For each VM in the selected service instance, repeat step 4.


If (VM is not a template and VM power state is “Powered On” or “Suspended”)




1.     Store the VM power state.

2.     Power off the VM.

3.     Delete the powered off VM from the virtualized environment.

4.     Import and deploy the OVF corresponding to the deleted VM from the backup location.

5.     Either power on or suspend the VM based on the stored power state as in (1).


else if (VM is a template or VM power state is “Powered OFF”)


1.     Delete the VM from the virtualized environment.

2.     Import and deploy the OVF corresponding to the deleted VM from the backup location.

3.     If VM was a template, then convert VM into template.


end if



Update the restore information into the service instance metadata.

Kamalkumar Mistry is a technology analyst at Infosys, Ltd. India. Kamal holds master’s degree in Information and Communication Technology (ICT) from DA-IICT, Gandhinagar, India. He has around five years of industry experience designing and developing software across a variety of industries such as Aerospace network system simulation, Cloud computing, Big Data Analytics and applications based on various virtualization technologies. His research interest includes designing routing protocols and algorithms in Mobile Ad hoc Network and Delay Tolerant Networks, Network simulations and various virtualization technologies. 

This article was originally published on Mar 13, 2012
Get the Latest Scoop with Networking Update Newsletter