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 rogerd AT uic DOT edu
======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.
>
|
