A lot of the earlier discussions on the list were related to the IBM 3494 VTL, which was designed for handling small chunks of seldom-used sequential data. It is prone to performance issues when handling LARGE chunks of sequential data, so it is not a good fit for backup products like TSM, which are designed to FILL a volume, whether virtual or real.
The 3494 VTL uses a combination of disk and tape, whereas the newer VTL's are all disk - a very different architecture. And so these newer types of VTL's will have different issues. When considering performance issues, know thine own hardware architecture. Now, back to the original point of this thread, sizing a library (real or virtual): The biggest mistake people make when sizing a TSM library is in just summing up the total amount of data they will back up. Not only do you need additional space in the library for your inactive versions, you must allow for the fact that your volumes WILL NOT BE FULL. Data is constantly expiring, and on a given day a significant number of your volumes will be partially full, but below your reclamation threshold. My rule(s) of thumb: 1.For file server backups, start with the amount of data you will back up. Add .05 (5 per cent) multiplied by the number of VERSIONS you will keep. (IBM recommends 10% as a starting point, but I find the rate of change on most file servers to be far less than that). 2.For large data bases, (Oracle, Exchange, etc.) start with the amount of data you will back up. Multiply by the number of versions you will keep. 3.Add some additional tapes for your DB backups and scratch pool. 4.Assume that you will get at most a compression ratio of 1.5. 5.Assume that your tapes will be, on average 60% full. 6.Now that you have a total, remember that most data centers experience a rate of growth in data storage of 50-100% PER YEAR. Whatever you buy for TSM, it better be expandable. Wanda Prather "I/O, I/O, It's all about I/O" -(me) -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Richard Sims Sent: Tuesday, November 30, 2004 10:36 AM To: [EMAIL PROTECTED] Subject: Re: size of active vs. inactive? On Nov 30, 2004, at 9:58 AM, Johnson, Milton wrote: > ...Needless to say, I disagree with the statement that TSM doesn't > appear > to be a good fit for a VTL. Remember a VTL is just a library that can > mount/unmount a tape in less than one second and read/write to the tape > at disk speeds. Why wouldn't TSM work well with a library on > steroids? ... Thanks for sharing your experience with VTL in a TSM environment: it's helpful to have the perspective of experience. As we've seen in past tape vs. disk discussions, though, don't regard "disk speed" as some kind of ultimate data processing I/O attainment: high performance tape technologies streaming to sequential media can in many cases out-pace disk throughput. It is in mounting and tape positioning that tape is a poor performer relative to disk, where one can wait a minute or more before I/O can proceed. That's were VTL shines. Richard Sims
