File-level versus image-level data backup: Chapter excerpt from "VMware VI3 Implementation and Admin
Learn about file-level backup versus image-level backup, and attaching tape drives to ESX hosts in our chapter excerpt from "VMware VI3 Implementation and Administration."
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.
Download the entire chapter, Backing up your virtual environment, from "VMware V13 Implementation and Administration."
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.
Attaching tape drives to ESX hosts
Although it is best to avoid doing this, sometimes it is necessary, especially in smaller environments that do not have a dedicated tape backup server. By installing a tape drive in your ESX host, you can use a VM to access it to back up the VMs on your host or other hosts. If you want to do this, you should follow a few guidelines to ensure success:
- Your tape device must use an Adaptec SCSI I/O adapter. (A dedicated one is recommended.) You cannot use an IDE or FC tape device, because even though the host may see it the VM will be unable to because it supports only virtual SCSI controllers.
- Make sure that the Adaptec SCSI controller that you are using is listed on the ESX hardware compatibility list for I/O devices.
- To check whether ESX can see the tape drive, use the following command in the Service Console: cat /proc/scsi/scsi. This command will list all attached SCSI devices. When you can see the tape device in the ESX Service Console, install a backup agent that supports ESX. If one is not available, use a backup agent that supports Red Hat Linux Enterprise version 3.
- When selecting a SCSI controller for your VM, make sure to choose LSI Logic rather than BusLogic.
For more information about using a tape device in your ESX host, see VMware knowledgebase article 1000024.
One risk of attaching a tape drive to an ESX host is that if the tape drive gets hung up, which is not uncommon, you will need to reboot the ESX host to clear it so that you can use it again.
Backups are important, so make sure you choose a solution that will work for the needs of your environment. Backups are like having good insurance policies: You pay your premium each month, and you hope you never need to use them; but if something happens, you are real glad that you have them. Restoring your data is even more important than backing it up. You need to make sure the solution that you use can easily restore files as needed in your environment. You should also plan your backup strategy around your current or future disaster recovery strategy because good backups are the foundation for any disaster recovery plan. If you plan on doing disaster recovery, look for a backup strategy that supports your disaster recovery requirements for recovering from an event. In addition, you may look into some of the products that can replicate your VMs from your production environment to a disaster recovery environment. When you implement a backup solution in your virtual environment, make sure you test the restore capability so that you don't run into any surprises later when trying to restore critical data.
For more information about backing up and restoring your environment, check out these resources:
- Virtual Machine Backup Guide
- Consolidated Backup in VMware Infrastructure 3
- Using VMware Infrastructure for Backup and Restore
- VMware Consolidated Backup
- VMware Consolidated Backup: Improvements in Version 3.5
- VMware Consolidated Backup -- Partner Integration Guide
- Best Practices for Architecting VCB Enabled Solutions (VMworld 2007 presentation, free registration required)
About this author:
Eric Siebert is an IT industry veteran with over 25 years experience covering many different areas but focusing on server administration and virtualization. Eric has been heavily involved with VMware ESX over the last three years and enjoys dealing with the opportunities and challenges that virtualization offers. He is a very active member in the Vmware Vmtn support forums and has obtained the elite Guru status by helping others with their own problems and challenges. He is also a Vmtn user moderator and maintains his own VMware VI3 information website, http://vmware-land.com. In addition, he is a regular blogger and feature article contributor on TechTarget's SearchServerVirtualization and SearchVMware websites.