Image Based Backup: How Images are Collected on Virtual Systems

Author: Jason Mattox


The foundation for Backup 2.0 technologies is image-based data protection. Which begs the question: what is image-based data protection, in detail?

This is the first blog entry in a three-part series that answers the question. In this series, I describe the detail of how images are collected and recovered. I describe this first for virtual machines, and then in the final entry I describe how the same approaches can work on physical systems.

Image-Based Data Collection on Virtual Systems

VMware naturally creates images for Virtual Machines because the OS is encapsulated into the VMDK file. The image includes the OS, patches, applications, and data. On Windows, for example, this means that all Registry Keys and System State are included in the image.


When we make a backup copy of an image, we grab the VMDK and the virtual hardware through the VMware API. When we grab the virtual hardware, what we really preserve in the backup is a control file or metadata for the Virtual Machine.
To collect the VMDK and virtual hardware, we use the VMware snapshot process. We trigger the VMware snapshot through the API call. This freezes the disk to a specific Point In Time (PIT). This is critical, because it means that the image collected in the snapshot is coherent and usable. The process of collecting an image is very fast; it is done on a running ESX system and does not require that the system be shut down. End-users and applications running in the Virtual Machine don’t even notice.


How fast is our collection process? It depends on a lot of factors, but we average 30 to 60 MB/sec over LAN and 90 to 150 MB/sec on fibre.


We describe our image collection process as being Agent-less. I define an Agent as being a piece of software that must be installed and which must be running, present in system memory, to operate and do its job. By their nature, Agents constantly impact the system on which they are running. They also require administrators to install them, manage them, track them, upgrade them, maintain them, and do whatever is required to keep them running. This adds up to a lot of extra work.


In contrast, with our Agent-less approach, we inject binaries for backup and restore at runtime. When the backup or restore process starts, we inject the binaries. When the process is finished, the binary files is turned off and completely removed. There is no installation process, no on-going resource consumption, and no maintenance. Our system queries the local environment, and always selects the right version of the binary file that will work for the system.


Agent-less backup is obviously a lot easier and less time-consuming to manage and maintain. Our backup method also naturally supports an environment with mixed versions of file systems and applications very easily. Agent-based backup systems, in contrast, often have different processes for different application and system versions – and may not support mixed versions of some systems at all.


Also, in the case of a virtual system, the binaries are installed at the physical level and work the same for all of the Virtual Machines on the ESX system. So, instead of a lot of Agents which are installed individually in each Virtual Machine, you get a much more efficient process which is simple to operate and has little impact on the system.


In the next blog entry, I will talk about how images are restored on virtual systems. Look to hear more from me soon.

Other Resources:

Backup 2.0 home page: