Eric,

I've reviewed your other replies, so this is my two cents added in.

Like you, I inherited an ADSM system whose main library was a 3575.  We started
out doing backups of about 30 nodes; now we're doing backups and archives of
about 120.  These additional recommendations are based on my personal experience
with the system.

1.  Daily system surveillance is critical.  ADSM has a tendency to become a
"train wreck" if problems are not addressed promptly.  The items I check DAILY
are:
has the OS reported any problems (AIX in our case)?
are any sessions hung (mediawait state)?
are any processes hung?
are all drives on line?
how much of the log has been used?
how much of the database has been used?
how full are our disk pools (we have disk pools "upstream" of all primary
libraries)?
how many empty tapes do I have in each library?
have any tapes been flagged read-only?

2.  I would recommend that you hang a small DLT library off your system for
off-site backups.  We backup our 3575-L18 and our 3575-L06 to a 7-slot DLT every
week.  The DLT hosts the copypool and those tapes go off-site.

3. Plan and watch your database and log very carefully.  As others have stated,
if either the log or the database fills up then ADSM just kind of dies.  The
manual states that each "object" takes about 600 bytes in the database.  Our
experience has matched that.

4.  Like you, we have a fairly lean shop and I'm the only one who really knows
ADSM having been through "combat" with it - I worked 70+ hour weeks because of
ADSM during the first seven months I had it.  You have a choice:  allow ADSM to
keep several versions of backups (we keep five of user-created data), or
scramble to load off-site tapes and/or make excuses when challenging restores
are requested.  My recommendation is to load your library with enough tapes to
hold all your data and let the system do the work.

5. In theory, backing up the DB allows you to roll back the state of the ADSM
system in order to restore files that have scrolled off the system.  My
recommendation: DON'T DO IT!    The one time we tried that we still couldn't get
to the files we wanted and it took two of us three weeks to recover from the
attempt.

6. Create some utility resources on the system, where you can park data if need
be.  I have a 10 GB disk pool and a DLT pool defined on top of our off-site
library, both of which are used in an ad hoc fashion as need arises.  There have
been times when they were worth their weight in gold.

7. ADSM has a lot of flexibility and scalability.  That is a two-edged sword, in
that you will always be learning more about the system and thinking of new
functionality to add.  That is normal-don't try to implement the world's
greatest backup system during your first couple of months.

After two years, our system has grown from backing up 30 nodes to backing up 120
nodes, archiving 60 nodes, off-site backups of backups and archives.  Our DB has
grown from 2 GB to 19 GB, and we've gone from storing all data on 25 Magstars
and 7 DLTs  to 300 Magstars and 60 DLTs.  We now have over 3 TB of data on tape.

Hope this helps.

Tab







Eric Lindbeck <elindbec AT SCTCORP DOT COM> on 02/03/2000 07:29:46 PM

Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

To:   ADSM-L AT VM.MARIST DOT EDU
cc:    (bcc: Tab Trepagnier/Corporation/Laitram/US)
Subject:  Easy ADSM?




Hello Everyone,

I've recently inherited an ADSM 3.1.2.50 system running on AIX, with a
Magstar L12 library attached.  Due to vendor problems and a real
comedy (?) of errors it only recently became usable, after 5+ months
of sitting idle.  No one here knows anything about ADSM, but
management insists that we attempt to make use of it because such a
large investment was made in it (how we got in this situation isn't a
cheeful story).  I've been tasked with figuring out what it can/can't
do and recommending a course of action.  To that end, I've read most
of the manuals we have and attended the TSM intro class.  I've also
been playing around on our system for the past week or so.

My primary concern right now is this:

Our IT department is a bit lean.  It's all I can do to just maintain
the other backups we have, much less babysit ADSM.  I recognize the
power of the system, but if I'm to use it, I'll need to configure it
to be as labor-free as possible.

From what I can figure, in order to make the process of creating a
full off-site backup as simple as possible, less than half of my tape
library should be filled.  That allows the other half of the library
to be filled with scratch tapes, so I only have to load & unload tapes
once.  Is this right, or am I missing something?

To make things even easier (and cheaper), could I attach a DLT library
and use it to make the tapes that are sent off-site?  Assuming the DLT
library can handle it, I'd be able to use the entire Magstar library
for client data - thus making better use of that fast (and expensive!)
medium and never having to touch the Mastar tapes (except to replace
worn out ones).  Am I on the right track here?

I'm basing all this on the belief that the most labor-intensive task
in maintaining *SM is creating tapes for off-site storage.  There seem
to be plenty of other things to keep a(n) *SM admin busy, but what
they are is still a bit vague to me.  What should my next area of
concern be?

Thanks!
Eric Lindbeck
SCT