Hello Wanda,
Thank you very much for very valuable information.
It looks I have initiated some discussion, but I couldn't take a part in this
discussion because of very low level of own knowledge on subject.
I understood I need to read documentation very carefully and move in direction
ESX 4.0 + VDR + TSM.
We are going to have VMWare VSphere 4.0 Enterprise Edition and we have TSM
Clients 6.1.3.3 and 6.2.0 already.
Kindest regards,
Grigori So;onovitch
________________________________________
From: ADSM: Dist Stor Manager [ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Prather, Wanda [wPrather AT ICFI DOT COM]
Sent: Monday, May 24, 2010 5:35 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] TSM+VCB against TSM+TBMR on each VM
Actually, I've got customers in many different stages of
implementing/converting/updating with TSM+VM:
ESX 3.5 + Veeam + TSM
ESX 3.5 + VRanger + TSM
ESX 3.5 + TSM only (only in customers where the VM's are dev/test, not
production)
ESX 4.0 + VDR + TSM
In the first 2 cases, they are doing TSM file-level backups of many of
the VM's, doing the image backups with another product to disk, using
TSM to get the images to tape for offsite storage. The TSM support is
just not suitable for managing large numbers (> 20 IMHO) of VM backups.
VM creation is too dynamic in most shops I've run into - they breed like
rabbits. There is no way the TSM admin is going to be able to find and
manage all the VM's by creating the lists that are required to do proxy
or image backups with the TSM VCB support. 6.2 support is supposed to
do discovery, haven't played with that yet, but 6.2 support doesn't
include image backups.
The 3rd case is only suitable for small sites, or where the VM's are
dev/test i.e. non-critical.
ESX +VDR seems is the best solution I've seen so far from a resource
point of view. You get both file-level (incremental) and image backups
with VDR, they are deduped, and VDR thoughtfully keeps the chunks of
stuff in its repository less than 2 GB, which means you can back it up
with TSM's subfile backups. So you get image + file level coverage,
without the load of doing that image as a full dump again.
OTOH, if you have users on the VM's who are accustomed to being able to
open the TSM client and do their own restores, I'm not sure how much of
a culture shock that model would create.
W
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Timothy Hughes
Sent: Monday, May 24, 2010 10:10 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] TSM+VCB against TSM+TBMR on each VM
Hi,
Are you guys doing both TSM Backups and VM backups?
Thanks
Tim
Prather, Wanda wrote:
>>1) using VCB you take off the load from the ESX server (VCB proxy
>>
>>
>sends the data to TSM, ESX just creates the snapshot)
>
>
>>I am sorry, but I do not understand, how it is possible take off load
>>
>>
>from ESX server. After creating snapshot you still need to read full
>image or some files and send to proxy. Almost the same is with normal
>TSM backups excluding load, created by TSM Client. Maybe I am wrong,
but
>I really do not understand why?
>
>Files are not SENT to the proxy. Using a VCB function, the snapshot of
>the .vmdk file is just MOUNTED to the proxy machine across the san.
The
>proxy machine does all the work of the backup, it reads the snapshot
>files and sends them to TSM server.
>
>Go to www.redbooks.ibm.com, download SG24-7447, TSM 5.4-5.5 Technical
>Guide. Read Chap. 24.
>This is for TSM 5.5 client support ( 6.1 has more improvements), but it
>explains how the proxy backup works with VCB very well.
>
>
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.
|
