I keep hearing it said, that if you're going to buy a great big disk array for TSM, that it works better if you let TSM know it has disks (DEVCLASS=FILE), than if you lie and try to tell it they are virtual tapes. Cheaper too, because you don't have that VTL layer in there. Simpler to administer because it's all done in TSM. Easier to grow later because you're not locked into a single vendor or technology - all the disk box needs to do is support Unix filesystems under your OS. All that lying just adds overhead.
We are dividing our workload, between large clients and small clients. Basically, we're dividing them between those who could use collocation on real tape effectively, and those who cannot. The small clients are going to move to an all-disk solution. You could call it virtual tape, except that TSM knows it's disks. Small clients are the situation where backup to disk is effective, because collocation is impractical so in a restore you're mostly waiting for the robot to dance around in his cage mounting and unmounting tapes. This is a huge waste of the robot's time, your time, and most importantly the client's time. SATA drives aren't fast, but they're fast enough to speed up small clients' large restores (e.g. an entire PC hard drive) by several orders of magnitude. The large clients are very much best on collocated real tape. I'd say the test is this: If you have a group of clients that are exploiting collocation correctly and effectively, without wasting too much tape, then that is exactly where they belong - on real tape. We found in a real disaster situation (big server had a large Unix filesystem get corrupted) that by setting RESOURCEUTILIZATION to get multiple restore streams going at once, that we restored that filespace many times faster than by any other possible backup/restore method, TSM or anything else. We also found that setting RESOURCEUTILIZATION high was much more efficient than any attempt to divide up the restore manually. Get several modern SDLT or LTO drives in a RTL (Real Tape Library) streaming data into a GigE pipe at once, and you're moving a lot of data very fast. Restore of large filespace(s) from disk simply cannot beat real tapes, with collocation, and the TSM RESOURCEUTILIZATION setting automating the process of creating multiple restore streams. Roger Deschner University of Illinois at Chicago [EMAIL PROTECTED] ======I have not lost my mind -- it is backed up on tape somewhere.===== On Wed, 6 Dec 2006, Nancy L Backhaus wrote: >Op System AIX 5.3 ML 3 >Nightly Backup 2 -2 1/2 TB >Library - ADIC I2000 Scalar >18 LTO Tape Drives >LTO 2 Tapes >600 slots >Clients - 135 (Wintel) >AIX -26 (Sybase, SQL, and DB2) > >We are looking into Virtual Tape Technology for our environment. 1 1/2s >TB data first backs up to disk then to onsite tape then we make a backup >of our onsite tape to a copy stgpool and store those tapes offsite for >disaster recovery. The other 1 TB of data is a DB2 database that we >back up directly to onsite tape and of course make a copy of the onsite >tape to offsite tape for disaster recovery. We can't get our backups >done and out the door to meet our RTO objective. We are looking to add >a VTL and reduce our tape drive and slot capacity in a new library to >offset some of the cost for a virtual tape library. We would like to >also take advantage of collocation and setup library sharing too. > > >I would like to know what vendors you are using for virtual tape? > >Pros/Cons(Any regrets, Success Stories). > > > >Thank You. > > >Nancy Backhaus >Enterprise Systems >(716)887-7979 >HealthNow, NY >716-887-7979 > >CONFIDENTIALITY NOTICE: This email message and any attachments are for the >sole use of the intended recipient(s) and may contain proprietary, >confidential, trade secret or privileged information. Any unauthorized >review, use, disclosure or distribution is prohibited and may be a violation >of law. If you are not the intended recipient or a person responsible for >delivering this message to an intended recipient, please contact the sender by >reply email and destroy all copies of the original >message. >