Keeping large filesystems mounted ties up OS memory? Creating storage
pool volumes ties up TSM database space? Keeping filesystems mounted
all the time increases the likelihood that a crash will lead to
corruption?

How much perl scripting would be required to emulate an external type
library by mounting and unmounting filesystems and creating symlinks?
Emulating tape drives might be tough though.

[RC]

On Dec 7, 2006, at 12:35 AM, Roger Deschner wrote:

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.