ADSM-L

Re: Easy ADSM?

2000-02-04 02:48:04
Subject: Re: Easy ADSM?
From: S W Branch <SWBRANC AT PPCO DOT COM>
Date: Fri, 4 Feb 2000 01:48:04 -0600
Does anyone have an IT dept that isn't lean? If you do, tell me - I'd like to
apply for a job there!

I don't know what your environment is like, but I've supported an ADSM
installation consisting of approx 300 client nodes
that are a mixture of AIX, HPUX, Netware, Windows 95, and Windows NT  for the
past 4 1/2 years and I haven't
experienced too many bumps in the road. We utilize an RS6000 58H AIX server and
our library is a 3494 L12 with
 2 3590-B1A tape drives. I would say that our environment is quite simple
compared to the environments that others on
 this list support - I only have a 10 GB database that is 70% utilized with 270
cartridges. Here are some of my thoughts:

1. Consider bringing in someone who is knowledgeable about ADSM to help you get
it set up properly. Sure it costs money, but
    if you get ADSM set up right from the start you will have a lot easier time
afterwards. We initially had 2 of our people from our
    corporate office and 1 person from IBM come in for 3-4 days to help us. As
we went through everything we had some very
    beneficial discussions about what worked in theory and what worked in the
"real world".

2. Put a lot of thought into the development of your management policies. You
want to make sure that you have a reasonable
    number of copies of your files in case you have to restore from your backup
and the copy on tape is corrupt. Say you have a
    file that changes every day and you back it up every day and maintain 3
backup copies (just an example). Initially you have  3
   good copies. Then the user does something stupid to mess up the file. If the
user calls you right then and asks you to restore
   from backup you will be ok. Suppose the user doesn't call you thinking all
will be better tomorrow. You backup the file that is no
   longer any good and one of your good backup copies ages off the system. The
next day the user tries to fix the problem and still
  doesn't call. Since the file timestamp got updated again today the corrupt
file is again backed up tonight and another of the good
  copies ages off. If the same thing happens the following day you will have
nothing but corrupt copies of that file in ADSM. Trying
  to repair the damage at that time could get pretty labor intensive. One of the
toughest things for new ADSMer's to adjust to is
  ADSM's incremental forever approach. Learn to use it to your advantage rather
than trying to keep doing things the old way.

3. Plan the size of the ADSM database and recovery logs and leave yourself
plenty of room for expansion. When your
    recovery log fills up ADSM comes to a standstill.

4. You can do quite a bit to automate ADSM through the use of administrative and
backup schedules and unix scripting.
     A lot of good examples have been posted to this list over the years - go
back through this list's archives try some of them.

5. Making offsite copies is not the labor intensive part if you have the right
equipment. The labor intensive part is in dealing with
    problems, ie backups that didn't run properly, equipment failures, tape
media failures, and those software bugs that have a
   way of finding their way into updated code. If your Magstar library is a 3494
with an adequate number of 3590 tape drives ( you
   should have 2 or more drives to do tape reclamation properly) you should be
in good shape. Also make sure you have plenty of
   hard drive capacity for your disk storage pools.

   I'm not sure that I would mess with a second library unless you expect to be
really tight on available cells. Are you taking into
   account that once you send your initial set of offsite tapes to the vault
most of your offsite tapes will tend to stay offsite? Each
   week you will create a few new offsite tapes and as you reclaim the ones that
are nearly empty a few will come back. Of course
   you will have to remove those that are going offsite and add those that have
returned, but that's not a big deal for us. We have
  a feature on our 3494 that allows us to insert or remove 10 cartridges at a
time (I don't remember the exact name). While it is
  true that you can save some money with DLT the number of problems that have
seen raised on this list gives me the
  impression that DLT is not as reliable as some of the other technologies. The
Ultrium based products that are supposed
  to be out soon, if not already looks promising. It would also be worth looking
at some of the other good products that have been
 discussed on this list within the past few months.
  past few months as well.

6. Test out your setup up front to make sure it works rather than getting into a
crisis and finding that it doesn't.

7. Is it possible to eliminate some of those backups that you mentioned and
utilize ADSM more than what you are
    currently? Not only does ADSM support a wide variety of clients, but they
also have additional agents that integrate with
   ADSM for backing up databases (Oracle, Sybase, Microsoft SQL, etc), Microsoft
Exchange, and Lotus Notes. As soon as we
   had our first full backup of our Netware servers we gladly ripped out our old
Palindrome to 8mm tape backup system and never
   looked back - it had never worked reliably so you can imagine how labor
intensive that was. So ADSM actually made
   things easier for us.

8. Utilize the knowlege that this list provides - it's free and the answers are
great. In addition to the free support that you get
    here you should strongly consider a support agreement with IBM if you don't
already have one.


If I've made it sound too easy, that wasn't my intention. ADSM is a very complex
system and it does require someone's time to
keep it operating as efficiently and trouble free as possible. To  reiterate
what I said earlier, if you spend quality time up front the
rest is a lot easier.

Good luck,


Steve Branch
Phillips Petroleum
e-mail: swbranc AT ppco DOT com





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

Any replies will be addressed to: "ADSM: Dist Stor Manager"
      <ADSM-L AT VM.MARIST DOT EDU>


To:   ADSM-L AT VM.MARIST DOT EDU

cc:
(bcc: S W Branch/PPCO)







 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
<Prev in Thread] Current Thread [Next in Thread>