Andy, My experience may not map to the problem you are trying to solve, but I chose a relatively small VTL tape size (50GB) and have not regretted it. The trade-off is "total number of virtual tapes" vs "total number of anticipated simultaneous tape mounts". Say you have a 60TB VTL (usable), and you want to emulate LTO4 tapes. If you went with the default size (400GB) you would have about 150 virtual tapes in your pool. Say also that there are 300 TSM clients to be backed up each night. Each one will need at least one virtual tape during their backups, and some of them might need 4 or 8 for performance reasons. You would have only 150 tapes for 300 clients? You could spread out their schedules, of course, but that will still be problematic. After a few weeks you might have a bunch of them full, but not ready to reclaim, or waiting on reusedelay, and not have enough available tapes for all the tape mounts you need. With 50GB tapes, you would have over 1200 virtual tapes. Tapes would fill up sooner, of course, but they could be reclaimed sooner, too, and be returned to scratch. Your overall disk utilization will go up. One thing to bear in mind is that if you have single files that are bigger than your virtual tape size, the file will have to span multiple virtual tapes. This is no problem for TSM, but it does mean that each of the virtual tapes involved in that one file will not be mountable until after that large file is finished backing up. We have seen the unusual situation where a single 300GB Exchange database was backing up, and happened to run over into our 'backup stgpool' window. The 'backup stgpool' was waiting on a tape mount of a certain volume, but when we checked we could see that the volume was not mounted or in use by anybody else. After some digging we noticed that the virtual volume in question had been mounted some hours earlier in a backup session for a single large Exchange file, and that backup was still going on. As soon as that file finished backing up, the virtual tapes mounted and the 'backup stgpool' continued.
Another thing to think about is, have you sized the virtual library to have enough capacity for all your primary storage pool needs, or will the primary pool have to migrate to real tape? If so, that is another argument in favor of relatively small virtual tapes, because they won't migrate until they are full. In our case, using the migration threshhold to cause the migration to occur didn't work well because of how TSM calculates percent full, so we ended up writing a script that automatically migrates (using "move data") virtual tapes as they age, so that we are sure we always have enough scratch tapes for our next backups. Best Regards, John D. Schneider The Computer Coaching Community, LLC Office: (314) 635-5424 Toll Free: (866) 796-9226 Cell: (314) 750-8721 -------- Original Message -------- Subject: [ADSM-L] VTL Tape Size From: "Huebner,Andy,FORT WORTH,IT" <andy.hueb...@alconlabs.com> Date: Tue, July 07, 2009 9:36 am To: ADSM-L@VM.MARIST.EDU We are about to bring up new TSM servers and one of questions that has come up is how big to make the VTL tapes? We currently use 100GG and have tried 10GB with our test server. The question is what size it popular and why? Andy Huebner This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.
