ADSM-L

Re: [ADSM-L] TSM+VCB against TSM+TBMR on each VM

2010-05-24 08:31:57
Subject: Re: [ADSM-L] TSM+VCB against TSM+TBMR on each VM
From: "Prather, Wanda" <wPrather AT ICFI DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 24 May 2010 07:28:56 -0500
TSM+VCB vs TSM+TBMR

1) For file-by-file backups, the difference is that TSM+VCB offloads the
work of the backup from the guest to the "proxy" server.
That may be important or not, depending on your environment.
The hardest thing to virtualize is I/O - if you have many guests on an
ESX server, the load from the backups might be a performance issue.
If your VM's are test/development, you probably don't care.
If your VM's are critical production machines, backups may have an
impact.

2) Be aware that in the next release of VMWare, VCB will no longer be
supported by VMWare.
That probably need not concern you, as the TSM 6.x clients support the
new VMWare storage API for backups, and it's pretty transparent to you.

3) Most of my customers who are implementing VMWare for production
servers are using image-level backups, as well as file level.
Using TSM+TBMR gives you a way to do bare metal recovery of your VM's.
But the restore is still very time-consuming, and you still have to do
significant work to deal with unlike hardware issues. (I.e., injecting
drivers, restoring from multiple tapes) 
If you have a VCB  image-level VM backup, your VM is a) contained in 1
file, and b) independent of the hardware, as you will be restoring it
back to an ESX server, not to a physical machine. The advantages in
restore times are significant.  OTOH, it increases your backup load
again, as you are backing up the entire .vmdk instead of just the
changes to it.

4) An excellent alternative is VDR, which is built into VSphere4.  It
backs up your .vmdk files to disk, and dedupes them as it does so.  The
VDR storage area is also formatted into files that are less than 2GB,
which makes them an excellent candidate for TSM subfile backup.  That
gives you the best of both worlds - VM image backups for DR, without the
cost of doing "full" images each day.  My customers that are using
VDR+TSM are having good success with it.  If you have a license for
VSphere 4 that includes VDR,  I suggest you look into using it.


W

 
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Grigori Solonovitch
Sent: Monday, May 24, 2010 4:24 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] TSM+VCB against TSM+TBMR on each VM

Hello Everybody,
I am TSM Server admin, but I am a beginner in VMWare backup/restores.
I am trying to understand some basic things like VCB.
In my opinion, VCB backup/restores are a little bit complicated.
Would it be possible to give main advantages and disadvantages for two
different ways of backup/restore for VMs:
1)     TSM + VCB based on "dsmc backup vm";
2)     TSM + TBMR on each VM with direct backups to TSM Server.
I do not need very detailed information - main ideas what is better and
why.
Thank you very much in advance.
Kindest regards,


Grigori G. Solonovitch

Senior Technical Architect

Information Technology  Ahli United Bank Kuwait
http://www.ahliunited.com.kw

Phone: (+965) 2231-2274  Mobile: (+965) 99798073  E-Mail:
Grigori.Solonovitch AT ahliunited DOT com<mailto:Grigori.Solonovitch@ahliunited
.com>

Please consider the environment before printing this Email


________________________________
CONFIDENTIALITY AND WAIVER: The information contained in this electronic
mail message and any attachments hereto may be legally privileged and
confidential. The information is intended only for the recipient(s)
named in this message. If you are not the intended recipient you are
notified that any use, disclosure, copying or distribution is
prohibited. If you have received this in error please contact the sender
and delete this message and any attachments from your computer system.
We do not guarantee that this message or any attachment to it is secure
or free from errors, computer viruses or other conditions that may
damage or interfere with data, hardware or software.

Please consider the environment before printing this Email.