Backing up ESX Host with Tivoli Client

[tsmhelum]

Hi All,

We have a Client who has a ESX host (OS: VMWare ESX vSphere 4) running a form of Red Hat Linux (Linux VM) Can we use the normal Tivoli Linux Client to back it the physical machine kernal up if so anything special we need to know especially as for as dsm.opt include/exclude statements?

2.6.18-128.ESX

If anyone can point to some specific documentation or link regarding this feel free to add.

Thanks in advance for any help!

 

[Jeff_Jeske]

We treat the ESX host as an appliance. We do not backup the host.

For us.... the VM's would VMotion off and the host would be rebuilt from scratch.

 

[tsmhelum]

The Client would like both full and incremental backups. they want all the ESX Hosts backed up. Entire server. Also, they would like clients installed on all the VMs and those backed up (so far, all Windows)

The ESX servers (HOSTs) are very small and would only require a full backup once a week. For the most part, these servers will not have VMs (VMDK) files on them. There ESX boxes are full ESX and have a Service Console which would be the Linux client. Currently 3 servers will need the linux client installed.

Thanks, for the information regarding the Linux client install on ESX, I will inform the client not sure if that will make a difference to them or not .

 

[Jeff_Jeske]

What is the exposure of not backing up the ESX host?
What is value add of backing up the ESX host?
Couldn't the customer recover a host from scratch faster than from TSM?

Sounds to me like your customer needs some gentle political DR guidance.

 

[tsmhelum]

Jeff thanks for your responses! I will check with the customer and higher ups. You may be correct but ultimately its not going to be up to me.


What is Vmotion off mean?


f.y.i - I am still kind of new at this VCB/VM stuff and this is the first time I even have to work with ESX servers.

 

[Jeff_Jeske]

Check this out:
http://www.vmware.com/products/vmotion/

We have a total of 1200 servers and more than half are running on VMWare. We do not use VCB. We backup each client as if it were a physical server.

The newest VSphere technology provides additional options for VM backup but it will require TSM 6.2 to take advantage. For now we have zero issues with treating them like physical machines.

 

[philteale]

I agree with Jeff here. We treat our ESX hosts pretty much as dumb boxes. All our hosts are connected to VSphere Centre, and as long as we have a good backup of the VSphere Centre database, we don't care about the hosts themselves. We can recover the entire platform by rebuilding the hosts from scratch and recreating the VSphere Centre datastore (and then restore the individual VMs, of course!)

 

[TykneeTym]

It's not a matter of backing up the hosts as it is backing up the VM configuration and not just the guest OS.

Currently (as far as I know) TSM doesn't support VADP but I think you can still use VCB it's just "depreciated".

 

[bartman]

We've recently been testing integrating the TSM Linux client with our virtual appliance and have gotten some pretty compelling results. This combination allows you to make image copies of your running VMs with any TSM client version. - Bart

http://www.pancetera.com/blog/2010/11/tivoli-with-pancetera-a-virtual-appliance-for-tsm/

 

[Jeff_Jeske]

I'm still confused by the whole VM image backup thing..... one of the largest TSM perks is the incremental forever backup. Now why on earth would you want to change direction and take an image backup of an entire VM? Do you take image backups of your important physical servers? Are you really blowing up VMs so fast that you need an image to recover? If you are really burning down VMs faster than you can put them up I don't feel TSM image backups is the answer. Maybe the root cause of the problem should be identified.

 

[wpinegar]

Image backups of machines (whether physical or virtual machines) are only needed when you need to recover from some of the most severe disasters. You MAY never need an image backup of a machine but WHEN you do there is NO adequate substitute. Windows Servers can often be difficult to restore quickly without an image backup -- if you lose an entire server or just the boot volume. However with an image backup you simply restore the image of the disk from the last full backup and then (depending on the particular server) you can selectively restore files or other components (such as databases, etc) that may have changed since the image backup was taken. We use Storagecraft to backup our critical physical servers (which allows us to perform hardware independent restores) and we use a combination of TSM 6.2.2's new VADP support as well as VCB to take an image of our virtual machines. Image backups are usually taken once weekly (and daily incremental) on our physicals and every 12 days for our virtuals so the image is not as current as a daily (or even hourly incremental) file-level or database backup. Some machines may require a two-step recovery (restore image -- followed by file or database restore) but some machines may be current enough to run from the last image.

We can say from recent practical experience that machine image backups are indispensable and should be included as an integral part of system recovery. The speed at which we can recover when we have a full system image cannot be disputed. For example we recently lost a Server 2008 64-bit SQL 2005 database cluster node due to a hardware issue. The boot volume in on RAID-1 and the cluster resources are on the FC SAN. This particular cluster runs two SQL database instances. Unfortunately the RAID-1 boot volume became corrupt when the server hardware failed (blame IBM, blame the environment, blame the tech or blame the RAID controller -- whatever floats your boat -- whatever the cause the boot volume was indeed gone and could not be recovered through any conventional means) so we had no choice but to resort to a full system recovery. Without a image backup the process could have taken a while and caused downtime for the entire cluster. However since we had a full image backup of the cluster node we waited for the IBM tech to correct the hardware issue that caused the server to die and then we discovered there was no joy when the system wouldn't boot. However we simply restored the image and we were back in business an hour later. I can also name several other occasions within the past year where a full system image was indispensable.

Even in a virtual environment there may be some occasions where a full system image would be needed. Is it possible for a SAN LUN to become corrupted or a virtual disk becomes corrupted. While you would hope this would never happen -- while hope may spring eternal -- hope unfortunately isn't a recovery plan and when you need a full system image there is no substitute.

What's really fun about full system images is that WHEN a system FAILS we can mount any physical and virtual machine as a "recovery" VM image in a lab environment, run through several recovery steps to see how we would like to handle the issue before we commit the changes to the server. That's nifty...

Anyway, just my 2 cents...