The new integration with TSM V6 and the new vStorage API is the
"recommended" way to go with TSM. Replaces VCB and is supported going
forward. Integrates with your Virtual Center server. Haven't implemented
this yet. But unless they've changed things my VMware-guy told me that
recovery using this method is 2-phase. You first restore the backup
snapshot, but then you have to run it through the converter to get an actual
running VM again. Just about doubles your recovery time.
You can still back them up from the console using the client
(http://www-01.ibm.com/support/docview.wss?uid=swg27009931) but I've heard
that this capability will be unavailable in future releases of ESX.
The new VDR appliance is OK, but as others have said it does have
limitations.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Storer, Raymond
Sent: Tuesday, June 22, 2010 3:12 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: ESXi and ESX
Tim, when it comes to VCB backups so long as your VCB Proxy can "see" the
disk the VM is on you can perform a VCB backup of it. If not, you can't.
Ray
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Timothy Hughes
Sent: Tuesday, June 22, 2010 11:48 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] ESXi and ESX
Question,
Is there any documentation on backing up a VM that's on a different TSM
Server that the PROXY or the VCB server? Both the Proxy and the VCB server's
are Windows boxes.
Tim
Prather, Wanda wrote:
>HI Alan.
>
>Most of my customers who are moving into VM for production systems
>need/want "full" VM backups as well as TSM-type file-level backups.
>The "full" VM backup is an image backup of the .vmdk file containing
>the VM guest.
>
>The horror of running production apps on Windows is the dreaded DR
>situation.
>Since MS doesn't have a supported method for doing Bare-metal recovery
>to different hardware, recovery of a Windows system to different
>hardware at DR is a slow, multi-step process prone to complications.
>However, if you have a copy of the .vmdk, you can drop it back onto an
>ESX server at DR, in one step, and you DON"T have to deal with the move
>to unlike hardware and the universe of issues dealing with Windows
>system state.
>
>And you can't get those .vmdk images with the TSM client. While it is
>possible to do file-by-file BMR for a VM guest, it's not something I'd
>recommend if .vmdk images are available.
>
>TSM file-level backups are still useful for versioning. I have 2
>customers using TSM (installed on the guest in the normal way) for the
>VM file-level backups, and full VM's for DR.
>
>The problem with using VCB, is that doing those full VM's puts you back
>into the business of dumping LOTS of data every week.
>
>I much prefer the use of VDR, which is VM's replacement tool for
>backups in V4. With VDR you get your fullvm's, but deduped into a disk
>repository. Then you back up the repository using TSM subfile backup.
>Your first step then at DR, is to restore the repository from TSM tape.
>Etc.
>
>If you need more info, feel free to contact me directly.
>
>Wanda
>
>-----Original Message-----
>From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
>Of Allen S. Rout
>Sent: Tuesday, June 22, 2010 11:14 AM
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Re: [ADSM-L] ESXi and ESX
>
>
>
>>>On Tue, 22 Jun 2010 13:41:48 +0200, louw pretorius <louw AT SUN.AC DOT ZA>
>>>
>>>
>said:
>
>
>
>>1. VCB is still officially the "right" way for backing up VM's from
>>VMware's (and IBM's) perspective and TSM 6.2 has some nice
>>
>>
>enhancements
>
>
>>to get this done.
>>
>>
>
>
>I'm aware that using VCB permits you to shift backup work from "the
>real server" to some proxy. Is there any other reason to prefer VCB to
>simply managing your guests like any other machine?
>
>
>- Allen S. Rout
>
>
CONFIDENTIALITY NOTICE: This email and any attachments are for the
exclusive and confidential use of the intended recipient. If you are not
the intended recipient, please do not read, distribute or take action in
reliance upon this message. If you have received this in error, please
notify us immediately by return email and promptly delete this message
and its attachments from your computer system. We do not waive
attorney-client or work product privilege by the transmission of this
message.
|
