File-level versus image-level data backup: Chapter excerpt from "VMware VI3 Implementation and Admin

In the first part of our chapter excerpt about backing virtual machines from Eric Siebert's new book "VMware VI3 Implementation and Administration" (Prentice Hall, 2009), you learned about backing up your virtual environment with traditional backup methods and with third-party VI3-specific backup products. In this part, learn about file-level backup versus image-level backup, and attaching tape drives to ESX hosts.

When it comes to backing up virtual machines (VMs), you have two options: back up the large VMDK virtual disk file (known as image-level backups) at the virtualization datastore level or back up the individual files (known as file-level backups) at the guest operating system level. Both options have advantages and can be used jointly to provide different restoration alternatives for your VMs.

File-level backups allow for individual file restores, which are useful when you have just a few files to restore to a VM and do not need to restore all the data just to restore the individual files. File-level backups can be done using traditional backup methods by running a backup agent inside the guest operating system of a VM. In addition, many backup applications that have support for virtualization can perform file-level backups through nontraditional methods such as using VMware's Consolidated Backup application. File-level backups are great for restoring a small number of files, but restoring a whole VM can be more time-consuming because you typically need to install a guest operating system and backup agent before you can restore the rest of the VM data.

Image-level backups allow for whole VM or bare-metal restores and are useful when you need to quickly restore a VM to a previous state or for disaster recovery purposes, which require bare-metal restores rather than individual file restores. To perform an image-level backup, you need to use a product or method that supports it rather than traditional backup agents, which work inside the guest operating system and do not have access to the virtualization layer and the VMDK virtual disk file. You can still do individual file restores with image-level backups, it just typically takes a few more steps to do it. To do this, you can restore the disk image and mount it on another VM to access the file and then copy it back to the source VM. In addition, VCB can make use of vCenter Converter to restore individual files.

So, which method should you use? It really depends on the backup method you plan to use. If you are going to use traditional backup methods that will enable you to restore individual files, you might also look to use one of the scripts or third-party products that can copy the image to disk storage so that you have that available as another restore option. This is a good way to make use of local disk on your hosts that you might otherwise not use or a low-cost NFS or iSCSI system or server. You might back up your VMs every day using the file-level method and back them up once a week using the image-level method. If you instead plan to use VCB or a third-party backup product, many of them will already provide you with the ability to do both file- and image-level backups. Image-level backups are great when you want to retire a physical or virtual server so that you have a bare-metal copy of it if you ever need it later.

Another question that is often asked is whether you should install a backup agent inside the ESX Service Console to back it up and the VM files from the VMFS datastores. Generally this is not a good idea for several reasons. The first is that it can have a big impact on the performance of the host when backups are running, which will also affect the VMs on that host. Second, you should avoid installing any software or utilities on the Service Console (with the exception of hardware management agents) because it could cause instability, which could lead to your host crashing. The last reason is that it is easier to rebuild an ESX host if there is a problem with it rather than try to restore it. When you rebuild an ESX host, you have the option to leave all the VMFS datastores intact so that your VMs can be re-registered with the host after it has been rebuilt. You will lose some configuration information (for example, vSwitches), but you can back up certain key files from your host to restore this. If your configuration is fairly simple, you can reconfigure your host instead. It is also a good idea to periodically run the vm-support script on your ESX hosts, which will provide detailed information about the host configuration and much more that you can later use as a guide to reconfigure it.

To back up the key ESX Service Console configuration files, just back up the /etc/vmware directory. You can do this with the tar command by typing tar -cvf esxhostnamebackup.date.tar /etc/vmware. This will create a single tar file with the contents of that directory that you can copy to another location for safekeeping. You can do this periodically for each of your hosts to use if you ever need to restore them. VMware has a knowledge base article that covers how to back up and restore ESX host configurations (KB article 1000761). To back up the configuration of ESXi hosts, you can use the vicfg-cfgbackup.pl script that is part of the RCLI.