Shannon, I have a fairly small shop. I currently have about 5 TB of managed data on primary tape pool and about 250 GB nightly backups and about 70 servers. I moved away from the VTS long before I got to this size
When I did restores from the VTS, it took many hours. Many of the files being restored span multiple 3490 virtual volumes. With the additional staging time required, this easily double or triple the expected restore time. This was for my primary backup pool. I always sent my archives to native 3590 H drive K length tapes. On my disk migrates to VTS, somehow I always ended up staging in my filling backup pool volumes. This is a factor on how much disk cache you have. After you append to a volume, the VTS will write to the 3590 and invalidate the original location. On my reclamation, I had many tapes that appears almost empty, but had one file that span multiple tapes. When these tapes are reclaim, TSM will stage in and reclaim every tape that file span. Sometimes I thought I only had one tape to reclaim, but that one tape brought in 5 others. After TSM has finished its reclamation, then the VTS will start reclaiming its native 3590 tapes. The VTS has some of the same intelligence as TSM. TSM reclamation will leave lots of free space on the VTS physical tape store and then the VTS will need to be reclaim. I was reclaiming daily to keep up. With 3590 H extended length cartridges holding about 60 GB native, I reclaim once a week on cartridges half empty. A half empty cartridge will take about one hour to reclaim. You mention you wanted to turn collocation on the VTS. What happens if the volumes TSM wants to mount for you archives is not in disk cache, then all these volumes must be staged back in. Depending on how many archives, this could take some time. VTS is best for volumes that will never be appended to. This is the same reason not to use the VTS for your DFHSM ML2 migrate. Imagine a single retrieve of 50 virtual volumes, that could be an extra 4 hours of staging time. A normal stage in process will take 4 to 6 minutes and the average native tape mount is about 90 seconds. If you have enough native drives or can get them, I would always go native. Leave the VTS for what it was design for, stacking lots of small tape data sets to large tapes. TSM will monitor your tape usage, and will fill your 3590s to max capacity with little wastes. Norman Gee Thanks for the responses! Here is the paragraph from IBM Redbook # SG24-2229-03 that I based my plan for sending TSM Archives to the VTS. Recommendations for VTS usage Use VTS for Tivoli Storage Manager archiving: Use VTS for archiving and back up of large files or data bases for which you don't have a high performance requirement during back up and restore. VTS is ideal for Tivoli Storage Manager archive or long term storage because archive data is not frequently retrieved. Archives and restores for large files should see less impact from the staging overhead. Small files, such as individual files on file servers, can see performance impacts from the VTS staging. (If a volume is not in cache the entire volume must be staged before any restore can be done). Norman, how much data were you talking about in your Primary pool on the VTS? And how many nodes were you backing up? I may have to re-think this if reclamation is going to be a problem. I have reclamation going all day on weekdays, to keep up with all the storage pools, and the Archcart stgpool only takes about 4 hours a week to complete, it's our easiest one! I at one time had my primary backup pool go into a VTS. Mine is a 3494-B18, older model. TSM likes to append to tape volumes until they are full. The recall process to stage a virtual volume from tape back to disk cache will take from 4 to 6 minutes and then TSM will start appending the tape and then it is written back to tape back end. When you start tape reclamation, it will take 4 to 6 minutes to load each 800 MB volume that needs to be reclaim. Tape reclamation is a real pain, at one time I was reclaiming 50 volume daily. I had 1200 virtual volumes before I decided to convert it all to native 3590 cartridges. I backup my database to VTS, but my offsite I take a DB SNAPSHOT to a 3590 cartridge. -----Original Message----- From: Steve Harris [mailto:[EMAIL PROTECTED] Sent: Thursday, October 14, 2004 4:38 PM To: [EMAIL PROTECTED] Subject: Re: Changes to Tape Management hardware in Data Center Shannon, What was the reason for purchasing the VTL? I'd surmise it is probably to do tape consolidation on your mainframe operations. *caveat! I have not actually used a 3494 VTL* Past posts here have indicated that TSM is not a good fit for the VTL because of the overhead of staging data that will only be used once and then destaged. I'd have to question why there is a perceived need to keep the archives in 3480 format. I can think of no reason to when native 3590s are available, other than a larger number of available drives. Sure, copy them over that way at conversion time if there is a co-existence issue with the new and old libraries, but new ones, nah. I understand that the VTL can be logically split into a native library and a VTL. I'd suggest for TSM that you use the native library. See the other posts earlier today about how to migrate to the new media. Regards Steve Steve Harris AIX and TSM Admin - ex mainframer 1980-1997 Queensland Health, Brisbane Australia I do have a question here about backing up the TSM database. Will it be possible to do some kind of DB Backup to the VTS and still keep my DB Series that is going offsite? 2. In addition to the VTS and our current Magstar, we are adding a 3494 -D14 and a 3494 -D12, that have a total of (6) 3590E drives. As with the Magstar, it will use the 3590J cartridges but will they should hold more data because of the difference between the Magstar 3590B drives vs. the 3590E drives on the new ATL. The following is the how this hardware change will have an effect on our TSM backup environment,