Anyone Using VMWare vStorage with TSM?

[DanGiles]

1st: VCB will be out of support shortly, but that's not vsphere with vcb framework.
2nd: Only being able to do file-level backups is a restriction with vcb (framework). TSM documentation says that restriction still holds with the vstorage api, and in that case, it's a TSM restriction.

If there are using the vstorage api, I suspect that file-level backups for linux guest machines would actually work, but since IBM hasn't had time to do a full compatibility test, it's not supported.

"not supported" is not the same thing as "will not work"!

 

[mmaliakas]

If there are using the vstorage api, I suspect that file-level backups for linux guest machines would actually work, but since IBM hasn't had time to do a full compatibility test, it's not supported.

"not supported" is not the same thing as "will not work"!

it doesnt work !!


i have tried. Vstorage Api from TSM Client 6.2 is only for FileLevel Windows Backup and nothing else. That means that even they have integrated the vstorage api you cannot take a Full VM Backup with it. you have to use VCB

in features version i hope that it will work.

they are crazy !!

 

[Jeff_Jeske]

So what you are saying is that soon.... VCB will be unsupported and IBM has yet to provide a replacement solution for full VM dsk backups?

 

[mmaliakas]

correct but this is not the only problem

with vcb you need a disk stagging area with the size of at least your largest vm and twice the time needed because of that.

with vstorage you dont need that. the backups can go directly to tape

 

[Jeff_Jeske]

We recently had a TSM health check from external vendor. They slammed us for not using VCB. We treat VMs just like Physical boxes as each get their own client. This works well except it take longer to recover because we don't have the raw DSK files.

So ... what is the solutoin to backup live VMs by means of single file image?

 

[mmaliakas]

only VCB at this time

 

[Jeff_Jeske]

So what direction is everyone hoping IBM goes?

 

[mmaliakas]

they need to implement full vstorage support

 

[GregE]

Agreed. I would think that that is in the works. It has to be. VMWare has stated their direction already and everyone knows what it is. I would look for IBM to put full VM backup into the 6.2.x client code soon, though I've not seen indications of when that would be or what exact patch would have it. Maybe 6.3.x, but since 6.2.x just recently was released, I wouldn't think they'd wait for a 6.3.x timeframe to add this. Anyone seen/heard anything?

 

[HajoEhlers]

In our ESX v3.5 environment i backup the images including config files by the following procedure:
- Login to the ESX Srv holding that VM
- Create a snapshot of the VM
- Determine path to the VM
- Backup the VM via tar - cpio or TSM client ( installed on the ESX srv ) can be used as well.
- Remove snapshot.

In case you have SANmontion it might be an idea to use SANmotion to move the VM to a dedictaed Backup ESX server , doing the image backup , move the VM backup to its original server.

Never used VCB and have image backups for LX,SUNOS and MS VMs.

hth
Hajo

 

[Andrew14]

Hello everybody. I think that it is a bad idea to implement VCB on my new ESX 4.1 hosts. But where can I find documentation on installing and configuring vStorage?

 

[DanGiles]

You don't implement VCB (VCenter) ON ESX servers -- it goes on its own server to off-load the ESX servers.

 

[Jeff_Jeske]

I'm really surprised so many people want to move to Vstorage. These days most ESX boxes are heavy duty and running a client backup doesn't really tax the host at all. Our ESX servers are really blades servers and they are hosting 40 clients each. The nightly incremental backups barely show up on the VM radar.

I prefer to have one backup and restore process for both VM and Physical machines. A backup process that allows me to restore individual files as well perform a full DR if need be (rarely).

I'd really like to know what the true benefit of the Vstorage approach is.

 

[TonyB]

Hi Jeff,

We're running two different strategies to do different types of recovery. Just like yourself we run a native client inside VMs to guard against logical corruption. We currently run VCB image backups (storing 1/7th of the VMs per day) with a zero version retention (i.e. only the active copy) for DR imaging - but only until we've weeded out the SRM (site recovery manager) config. Once that's in place we'll disable VCB and drop-kick it, relying on SAN based metromirrors.

I just don't see the point of trying to protect against logical corruption using a VCB. Then again - we tend not to run bulk data stores in our ESX, preferring external database farms with higher I/O bandwidth available for bulk data flow.

hth,

T

 

[Jeff_Jeske]

In the world of disaster recovery its always nice to have belt and suspenders but you have to be a realist as well. What is the most likely event that will happen and what is the impact. We've been running VMWare for about 10 years and have only had a couple VM BMR requests. In most cases these are development boxes and not customer facing app servers. If a VM takes a digger we can use PXE boot to assist with a system state restore or we can perform a BMR with the BAC. Either approach is the same that we would use for a physical machine. (If you don't have image backups of your physical servers why would you go the extra mile for your VMs?)

We do have SAN replication in place but the remote copies would only be used to recover in the event of a complete site disaster. That is perhaps the most unlikely DR scenario we face.

I'll probably test the Vstorage option to see if its more than just hype. But considering we have over 700 VM's I don't think the proxy server approach is going to be worth our while.

 

[O.Schmidt]

Hi,

where can I find documentation on installing and configuring vStorage?

 

[TykneeTym]

You don't configure vStorage, it's an API. You configure your backup application to work with vStorage.

Currently, TSM doesn't (really) do it. You can grab the virtual disk but you'd have to restore it the "old" way and it doesn't grab the guest VM properties.

 

[bartman]

Pancetera Unite is an option that allows you to leverage the vStorage API with your existing TSM agents. Unite provides a consolidated view of all of your VMs in a directory structure. You can then export the directory structure via CIFS or NFS so that you can back it up with any TSM agent.

 

[Masonit]

TSM is light years behind Netbackup on vstorage. We are looking at both options and TSM has nothing interesting at all on Vmware backup.

Netbackup has full vstorage support. Netbackup talks directly to the ESX server. Just choose what Vm:s to backup. You get incremental block level backup using dedup. You can do full vm restore and file level restore using the same backup data! Netbackup also has the capability to stop Microsoft databases (sql, exchange) during the backup. So you don't have to worry about corrupt databases after a full vm restore.

What the hell are IBM doing? Maybe the have their hands full solving all APARS. :down:
Technically I see no reason to stick with TSM.

\Masonit

 

[Jeff_Jeske]

If all you have are VMs and you are unhappy with the current backup approach TSM offers then maybe Netbackup is better for you at this point in time.

But things change and I'm sure IBM will have something more integrated in the near future. We still treat our VMs like physical machines so having vstorage tools provides no benefit for us.

Honestly.... I'm not sure what all the Vstorage hype is all about anyway. The newest blade servers are so powerful that you can run client side backups with compression, dedupe, or encryption without issue. Using PXE boot recoveries make full BMRs a thing of the past and even if you are old school we've always been able to backup the DSK files and we've always been able to perform file level restores.

So.... what is it that you expect to gain from vstorage restores that you don't already have? Please don't tell me your hardware is to slow or that TSM overloads the VM processor because that is simply a design issue not a TSM issue.