I do full DB backups daily.  I don't do incremental DB backups.  It seems
that my DB is not large enough to warrant that.  To restore, I use the
most recent DB backup tape.  I do not re-format any volumes.  I use this
command to restore the DB:

    /opt/IBMadsm-s/bin/dsmserv restore db todate=today totime=hh:mm

where hh:mm is the appropriate time that I determine by inspection of the
console log.

In response to Steffan <arhoads AT PACBELL DOT NET>, I am using raw logical
volumes for both my DB and my log files.  (Well, almost.  For the log,
I have two large volumes, mirrored for a total of six partitions, all
raw, and one tiny file, not mirrored, that I created one day when I
had to extend the log.  It turns out that I can't drop that last volume
very easily, now that I don't need it any more.  I should try again.)

Rich

At 12:29 AM 9/2/99 +0200, you wrote:
>What do you meen by " I can restore to a PIT just
>before the crash, and I'm up and running smoothly.". Are you doing it from
>the last tape with 'todate' option ? If not, how do you do it ?
>
>
>--
>Regards
>
>Malkit Hayun , UDI
>Storage Products Manager
>IBM Certified Specialist-ADSM
>Office: 972-3-9233440
>Fax:    972-3-9233441
>Mobile: 972-52-834575
>Email: malkit AT udi.co DOT il
>
>
>"Richard C. Dempsey" wrote:
>
>> I'm running with rollforward on my admittedly fairly small system.
>> I am currently working with IBM on a DB corruption problem that
>> will crash ADSM whenever I try to BA STG for a certain storage pool.
>>
>> I have been very happy with roll forward.  I have found that I cannot
>> restore to the time of the crash -- it just crashes again!  (This
>> has a certain "doh!" quality.)  However, I can restore to a PIT just
>> before the crash, and I'm up and running smoothly.
>>
>> I do mirror my DB and my logs.  I have occasionally lost a volume
>> of the DB mirror, but not of the log.  When I lose a DB volume, it
>> just varies offline and keeps on running.  When I replace the bad
>> volume, things resync and keep on running.
>>
>> my $0.02 ...
>> Rich
>>
>> At 09:19 PM 9/1/99 +0200, you wrote:
>> >Hello,
>> >
>> >I would like to discuss the following with you:
>> >
>> >I recommended my customers to work with rollforward. Some of them even
>> >have mirroring for their recovery log. The reason was - data integrity.
>> >
>> >We usually fail to restore the DB to its most current state. The main
>> >problem we encounter is that whenever we have a failure on ADSM DB -
>> >usually hardware problem it effects the recovery log as well, and we
>> >must run point in time backup.
>> >
>> >Yesterday, one of our customer had a crash on one of the recovery log
>> >disks. The recovery log was mirrored to another disk, but ADSM didn't
>> >switch to the alternate volume.Both of the volume switched to offline
>> >and ADSM crashed. Running 'dsmserv display logvol' we got a message that
>> >these volumes are offline. We couldn't load ADSM back - we try extend
>> >log, restore DB - which failed as well. Finally we run 'dsmserv format
>> >....' and only then we were able to restore the DB.
>> >
>> >I would like to ask you if any of you work SUCCESSFULLY with
>> >rollforward. What is your experience with ADSM DB and RLOG.
>> >
>> >
>> >--
>> >Regards
>> >
>> >Malkit Hayun , UDI
>> >Storage Products Manager
>> >IBM Certified Specialist-ADSM
>> >Office: 972-3-9233440
>> >Fax:    972-3-9233441
>> >Mobile: 972-52-834575
>> >Email: malkit AT udi.co DOT il
>> >
>> >
>>
>> Richard C. Dempsey                 email: dempsey AT kodak DOT com
>> Public Online Services             pager: 716-975-3539
>> 11th Floor, Bldg 83, RL            phone: 716-477-3457
>> Eastman Kodak Company              fax:   716-722-3885
>> Rochester, NY 14650-2203
>
>

Richard C. Dempsey                 email: dempsey AT kodak DOT com
Public Online Services             pager: 716-975-3539
11th Floor, Bldg 83, RL            phone: 716-477-3457
Eastman Kodak Company              fax:   716-722-3885
Rochester, NY 14650-2203