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 [[email protected]] On Behalf Of Prather, Wanda [[email protected]] Sent: Monday, May 24, 2010 5:35 PM To: [email protected] 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:[email protected]] On Behalf Of Timothy Hughes Sent: Monday, May 24, 2010 10:10 AM To: [email protected] 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.
