Hi, In version TSM Server 6.3 there was improvements in relation to Virtual Libraries, I am not sure if this solves the problem. Anyway if you open a RFE I will add my vote and I hope new releases TSM Server will have the possibility to choose the pool to restore the data. I have seen this behavior when we use VTL and Physical Tape Libraries, the restores has been done from PTL instead of VTL due to the number of the tape volumes.
Regards, ________________________________ De: "Hart, Charles A" <charles_h...@uhc.com> Para: ADSM-L@VM.MARIST.EDU Enviado: Martes 8 de enero de 2013 21:01 Asunto: Re: Battles with TSM for VE Interesting ... we have experienced a very similar issue where our DB (Oracle etc) restores were coming off the Copy pool. We opened a PMR and found out this was due to the way TSM was designed to take the least path of resistance for restores meaning if there are less copy pools volumes required for a restore than primary volumes TSM will choose the pool with less volumes. This is s a real pain with Virtual tape as we make those smaller by design unlike physical tapes at 1+TB. IBM did do a "fix" with a option to put in the server option file but it didn't work for us. So if we have a critical restore and we see this happen we'll mark the offsite tapes as unavailable. -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Neil Schofield Sent: Tuesday, January 08, 2013 1:24 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Battles with TSM for VE We've been using TSM for VE in production for about 6 months now and although it generally works well, there have been a number of minor issues which remain unresolved. However one problem stands out above the others and despite extensive discussions with IBM support, we've been unable to achieve a resolution. I just wanted to run it past the ADSM-L community to gain their perspective. There are about 500 VMs (predominantly Windows Server) on ESX 4.1 that we back up on a nightly basis, with each VM getting one full backup a week and incrementals (using change block tracking) on the other nights. Consider the following scenario: - A backup proxy server accessing the ESX disk LUNs over a SAN running TSM for VE and with LAN-free (Storage Agent) access to tape library A - A dedicated primary disk storage pool (VMCTLDISK) on the TSM server for storing the CTL data - A dedicated primary tape storage pool (VMDATATAPE) using a device class in library A for the VM backup data - A dedicated copy tape storage pool (VMCTLTAPE) using a device class in library A to provide a backup for the CTL data on disk - VMDATATAPE is collocated by filespace so each VM's backup data is on the smallest number of tapes - VMCTLTAPE contains only one or two tape volumes to hold the copy of all the CTL data for all VMs (no collocation) - A daily admin schedule backs up CTL data in the primary storage pool to the copy storage pool after the backup window for the TSM for VE clients Now a full backup of a VM works fine. The backup proxy server sends CTL data over the LAN to disk on the TSM server and VM backup data over the SAN to library A. Incremental VM backups work less well. Under the covers, incremental backups involve a significant amount of restore processing by the client as it restores previously backed up CTL data. In the scenario above, we naively expected the process for restoring the CTL data to be the reverse of the backup process - ie the CTL data would be accessed over the LAN from the primary disk storage pool on the TSM servers. However it quickly became evident that the TSM for VE client was favouring the far slower tape volume in the copy storage pool when it came to restoring CTL data for every incremental backup (presumably on the basis that the tape volume could be mounted LAN-free while the disk volume couldn't). For the relatively small amount of data involved when restoring the CTL files (compared to the size of the backup data), the overhead of mounting the tape was significant. Even worse though, those one or two copy storage pool volumes became a massive source of contention when running multiple concurrent incremental VM backups. I can't find an easy way of inhibiting LAN-free access to the copy storage pool volumes by the backup proxy server without affecting it's ability to store (and restore) the VM backup data using LAN-free. When we discovered this behaviour the only relief I could find was to put in place a spectacularly ugly work-around which involved running for 99% of the day with the volumes in the copy storage pool holding the CTL data updated to have an access mode of unavailable. This forces the TSM for VE client to restore the CTL files from the primary disk storage pool during incremental VM backups. The script which performs the storage pool backup first updates the copy storage pool volumes to read/write and then changes them back to unavailable upon completion. This doesn't sit well with me because volumes which aren't read/write typically indicate trouble and it means mods to our monitoring to ignore these volumes. At the same time as we introduced this, we logged a PMR with IBM. This has now been relegated to the status of a documentation APAR to describe the behaviour, so it looks like the kludge we implemented could become permanent. Am I being unreasonable in thinking the way IBM have implemented this is flawed? For info, TSM for VE is v6.2 and TSM Server is v5.5.6 Regards Neil Schofield Technical Leader Yorkshire Water ---------------------------------------- Spotted a leak? If you spot a leak please report it immediately. Call us on 0800 57 3553 or go to http://www.yorkshirewater.com/leaks Get a free water saving pack Don't forget to request your free water and energy saving pack, it could save you money on your utility bills and help you conserve water. http://www.yorkshirewater.com/savewater The information in this e-mail is confidential and may also be legally privileged. The contents are intended for recipient only and are subject to the legal notice available at http://www.keldagroup.com/email.htm Yorkshire Water Services Limited Registered Office Western House, Halifax Road, Bradford, BD6 2SZ Registered in England and Wales No 2366682 This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately.
