It's MUCH safer to let ADSM do its own recovery for the data base; the
capability is built in.

You've done almost everything you need to already.
The only other thing you need to back up is something that will tell you how
big your ADSM DB and log are.
(A simple way to do this is to enter the command Q SYSTEM and pipe the
output to a file.)

Now when you've restored your operating system from the mksysb, the ADSM
code will be there.
When you try to start the ADSM server, it will look at dsmserv.dsk and try
to find its data base and log volumes that way, but the the disk has
crashed, so the server won't start at all because it can't find its data
base.

All you need to do is to use dsmfmt to reformat new empty files for the DB
and log (presumably on new disk!)

Then you need to check the dsmserv.opt file and make sure there is a
devconfig entry that points to your devconfig.bk file, and a volhistory
entry that points to your volhist.bk file.

Then you start the server with :  dsmserv restore db
ADSM will look in the devconfig to find its tape drive and devclass
definitions, and look in volhist.bk to find the last good DB backup tape, it
will mount the tape on an appropriate drive, restore its DB and reformat the
recovery log.

It's very cool, very elegant, and works VERY well.

So there is no need to tar, better to rely on ADSM's DB restore capability
to get everything back in sync.

If by chance your replacement disk is not the same size as the old (say you
only have 1 big filesystem instead of 2 small ones), you can edit the file
names used for the db and/or log by editing dsmserv.dsk (something you
should do ONLY in a disaster recovery situation!); just make sure the total
space you format for the db and log is at least as large as your original
ones.

************************************************************************
Wanda Prather
The Johns Hopkins Applied Physics Lab
443-778-8769
wanda_prather AT jhuapl DOT edu

"Intelligence has much less practical application than you'd think" -
Scott Adams/Dilbert
************************************************************************








> -----Original Message-----
> From: ANGEL BUGARIN [SMTP:ANGEL.BUGARIN AT MAIL.SPRINT DOT COM]
> Sent: Wednesday, October 13, 1999 2:34 PM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: Crash recovery doc.
>
> ADSM will be reinstalled using the mksysb. This way the orginal files
> and configurations will be intact.
>
> One method of crash recovery I was thinking of is running a tar against
> the filesystems. If any of the disk fails, I would install the OS using
> the
> mksysb which also contains the ADSM server application then restoring
> the files. Any thoughts on this?
>
>    -----Original Message-----
>    From:       PrathW1 [SMTP:PrathW1 AT CENTRAL.SSD.JHUAPL DOT EDU]
>    Sent:       Wednesday, October 13, 1999 5:48 AM
>    To:         ADSM-L
>    Cc:         PrathW1
>    Subject:    Re: Crash recovery doc.
>
>            If the ADSM server application is in rootvg, will it be
>    reinstalled
>    as part of restoring the mksysb, or do you intend to reinstall it
>    from the
>    CD?
>
>    > -----Original Message-----
>    > From: ANGEL BUGARIN [SMTP:ANGEL.BUGARIN AT MAIL.SPRINT DOT COM]
>    > Sent: Tuesday, October 12, 1999 10:04 PM
>    > To:   ADSM-L AT VM.MARIST DOT EDU
>    > Subject:      Crash recovery doc.
>    >
>    > Hello everyone.  I need to create a documentation on
>    > crash recovery.  The crash is defined as "all disk drives
>    > are completely thrashed/inaccessible" that a reinstallation
>    > of the ADSM server application is required.  The following
>    > are facts:
>    >
>    > 1.  We don't have DRM installed.
>    > 2.  The ADSM server application is installed in rootvg.
>    > 3.  The data and recovery log are in a seperate volume
>    group(adsmvg).
>    > 4.  We perform a full ADSM database backup after all regular
>    >      backup processes are completed.
>    > 5.  A listing of the device config(devconf.bk) and volume history
>    >      (volhist.bk) is created. A copy of the dsmserv.opt is also
>    made.
>    >      The devconf.bk, volhist.bk and dsmserv.opt are placed in a
>    > directory
>    >      called /mksys which is included in our weekly OS backup.
>    >
>    > I understand that after ADSM is reinstalled, it does not know about
>    > the tape volumes in the volhist.bk or their contents.  In general,
>    what
>    > are the steps to perform to bring ADSM back to the last full
>    database
>    > backup--that is if still possible.
>    >
>    > Your suggestions or comments are appreciated.
>    >
>    > Thanks,
>    > angel
>    >
>    >
>    >
>
>
>