Rodrigo Gazzaneo wrote:

> Hi again,
>
> > > Second is a particular opinion that although ADSM is
> > > installed on /usr/lpp/adsmserv, you should never
> > > keep your configuration files and even your ADSM
> > > startup directory on ROOTVG, because if you needed
> > > to restore from mksysb tape you would be erasing
> > > important application configuration.
> >
> >      Like what?
>
> Like dsmserv.opt, like dsmserv.dsk, like volhist and
> devconfig. If they are overwritten for older versions,
> your ADSM may go very crazy ...

    dsmserv.opt -- unlikely to change, and changes are unlikely to affect
                            an emergency recovery (maybe memory changes
etc).
                            Generally, a copy is stuck into things that get
sent offsite.
                             Or at the very least, it should be...   :)

    dsmserv.dsk -- will be recreated when you recreate the dbs and logs

    volhist -- consulted to find the last good ADSM backup.  Yes, you
                   certainly need the latest copy of this.  Which is kept
inside of
                   your Recovery Plan File from DRM, or if you've rolled
your
                   own, you will have a copy of.

    devconfig -- consulted to determine how to get the last good ADSM
backup.
                       Same comments apply as for volhist.

     None of these files really apply, because you'd be in the same boat if
the db and logs were in the savevgs either.  If that's all that you mean,
I've
got to disagree with you.

>
> >No other savevg tapes required.
>
> If you feel ok, than it is ok for you.
>
> On bigger sites and bigger corporations, it is normal
> that different people and different areas take care of,
> let4s say, AIX system, backup with ADSM, database,...

     This is normal.

>
> so it is a good policy to keep everything separate, in
> order to reduce inter-area damage.

       I've heard this argument before, and I can pretty much say that
it's not a bad way to operate, if you choose to do so.  I don't think
that it's the ONLY way to operate, and IMHO reducing the number
of tapes and steps for admins to keep track of to restore your ADSM
server back to a minimally-operating state is a Good Thing(tm).

    As always, your mileage will vary.

> If you don4t have this kind of problem, and you know
> where everything is, ok. The problem arises when you
> have 20 people over a S80 server ...
>

      Like I said, I see fewer parts and areas of contention in my
procedures.
Whatever you feel comfortable with.  As for the implication that what I'm
suggesting is only ok for small shops, you're mistaken.  If you don't
document
your environment, train your people in the procedures, and practice your
chosen implementation, you're hooped unless the implementor of the plan is
the one doing the restores.

>
> >
> >   I guess the thing I don't understand from your statement is the part
> >about "if you needed to restore from mksysb tape you would be erasing
> >important application information".
>
> Suppose your server crashes. Suppose your system disks
> crashes. You replace them, reinstall from tape,
> re-import the shared VGs and sit back happily after all.

    You forgot the step of re-installing the ADSM binaries, patches etc
back onto the ADSM server. :)

> You didn4t lose any config data because they were never
> affected by the rootvg crash. You didn4t have
> to rewrite dsmserv.opt. You didn4t have to
> restore it from ADSM. It is a matter of choice
> for less trouble and better administration.

     What can I say, I don't think you've given my point of view enough
credit.
If your server crashes, and the secondary becomes the primary, all you need
to do is use your mksysb and copy the files over from the primary.

> >Can you provide me with a specifc example of something that would be
> >messed up with a mksysb?
>
> Once again. Hdisk0, hdisk1 is rootvg. ADSM is
> on rootvg, dsmserv.opt, dsmserv.dsk is on
> rootvg. You have a crash. You replace your
> disks and reinstall your system image.
>
> If your last system image (for instance is
> your weekend system image) doesn4t have
> your last changes of dsmserv.opt, dsmserv.dsk
> and volhist, you will have a config file in
> the wrong version that might cause
> problem.
>
> Of course you won4t notice until you
> can4t access a certain volume, or a volume

> Then you will have to restore the file,
> stop your ADSM server, restart it.
>
> It seems to be no problem if you have
> a small site. But on bigger environments,
> non-stop applications, DBs throwing logs
> all over the site, well, ... not that easy, ....

        If you're relying on ALWAYS having one machine available to you
in order to do the restore, I think that you are going to seriously have
to think about a DRM plan.  :)    No HA cluster is going to save you if
an earthquake rips apart your data center, unless you rely on transaction-
oriented, distributed database technology over a wide area (note that I'm
disqualifying fibre-optic link systems, as I don't trust them yet.  Given
another
couple of years, they will probably become very good choices, but I don't
feel comfortable yet :).  ADSM doesn't have a distributed database
technology
(yes, I've seen the server-to-server communications portion, and it's still
a
little too cumbersome).

    From your descriptions, it sounds like you're not addressing DRM and
ADSM database restores.   As I've said before, you can make your method
work, but you still need documentation, some kind of Recovery Plan File,
and your latest ADSM DB backups.

    Anyway, there are a number of possible ways to implement HACMP.
As another person pointed out, split-brain syndrome is a very baaad thing.
So long as you take proper precautions, you should be ok.

   From this discussion, I don't think you're paranoid enough about being
able
to recover your data, but hey -- that's your comfort level.


kells