Virtualization Pro

Jan 5 2009   4:17PM GMT

More on restoring ESX from backup

Rick Vanover Rick Vanover Profile: Rick Vanover

In reading fellow 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.

1  Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • Sbeaver
    Running the support script is a great idea and I also recommend running that script as soon as the ESX server is built so you have a base line to refer to. I am one of the true believers that ESX should never be restored and should always be rebuilt. I like to preach that ESX is an appliance and should be treated as such. If you have the a solid build process in place you should never really need to restore the server itself. Most of my documentation is in the form of comments on my scripts. If I make any changes to ESX I first add the change to my build scripts and then make the change in production. Automation is the key to great success Steve Beaver
    0 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: