backup

Restoring individual files from image-level backups of virtual machines

Virtual environments can change the way you back up your servers by providing an additional backup method where you back up the single large virtual disk file instead of the individual files inside the VM operating system. There is sometimes confusion, however, when using this method as if individual file restores are possible and how difficult it might be to restore them back to a VM.

There are two methods for backing up a VM, traditional backup methods that install an agent inside the OS and back it up file-by-file and image-level backups that back up the single virtual disk VMDK file. Image-level backups are usually done by backup applications that are designed to specifically back up virtual machines, like Veeam Backup and Replication. These applications use the snapshot feature that is built in to VMware to stop disk writes to the virtual disk so it can be safely backed up. Backup applications read the original virtual disk file which is now read-only as new disk writes get written to a newly created delta virtual disk file. Once the backup application has read all the blocks from the original virtual disk file the snapshot is committed, which takes the data from the delta virtual disk and writes it to the original virtual disk. Once this is complete the delta virtual disk is deleted.

Continued »

More on restoring ESX from backup

In reading fellow SearchVMware.com IT Knowledge Exchange blogger Edward Haletky’s post on restoring the ESX host from a backup, I would like to say that I concur with all of his points and would like to add a few of my own.

I do not back up the ESX host in a way that I would ever want to restore it. Occasionally, there are needs for onetime backups of VMDK files or such that are well suited for an agent backup, but for the most part the hosts are a transient set of resources that I present vCenter.

There are some practice issues that can optimize how this preference can be used, and I’ll share a few of them here. Some of these I currently use in production, some I have used in lab functions only.

Before you locally destroy a server’s state, it may be a good idea to run the vm-support tool or generate diagnostic bundles before the system is gone forever. Of course, this is not always possible, but it is a nice way to have the critical logs available before the installation is replaced.

One of the first points is the server reinstallation time requirement. Simply installing ESX is quite easy and can be done in twenty minutes or so. Some large ESX environments may want to look into an ESX kickstart script. These scripts can provide a scripted out answer file for the ESX install and can be made to work on a PXE boot. This can not only slightly reduce the reinstallation time, but can also ensure configuration consistency.

Now that ESX is configured, you may have a wonderful time reconfiguring all of the virtual switches and port groups. ESX has some native help here with the use of the esxcfg-vswitch series of commands, (check out the link for a blog post I did earlier that can get you started using this command). I’ll also pass along a site I recently came across with some good tools from Richard Garsthagen, a Netherlands-based VMware evangelist who has a cool blog with some good ESX tools that can help in this area, especially with the ITQ VLAN and portgroup manager tool.

The last series of configuration in a re-installation can revolve around storage pieces, such as multipath policies, iSCSI, or host bus adapter (HBA) information and configuration may also be optimized by making scripts with the esxcfg series of commands.

Finally, again echoing Edward’s comments, the best tool to have is good documentation and a confidence in the installation. This will permit the reinstallation to succeed smoothly and in a timely fashion.