Hi Rodrigo,
Yes, you are correct. Of course you can always recreate
dsmserv.dsk if necessary by creating the dsmserv.dsk
file with the name of one of the available recovery
log volumes, as each volume contains a table of all
database and recovery log volumes.
Best regards,
Andy
Andy Raibeck
IBM Storage Systems Division
ADSM Client Development
e-mail: storman AT us.ibm DOT com
"The only dumb question is the one that goes unasked."
Hi Andy,
but you will need dsmserv.dsk intact too, right ?
So ADSM restore process can find the Recovery Log
valid copy, I think ...
regards,
Rodrigo
>From: Andy Raibeck <storman AT US.IBM DOT COM>
>Reply-To: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Re: Roll-Forward recovery?
>Date: Mon, 29 Nov 1999 08:28:43 -0800
>
>Hi Rick,
>
>ADSM/TSM *does* have roll-forward capability, provided that
>the recovery log is intact at the time of the failure. The
>information necessary for roll-forward recovery is contained
>in the recovery log when the ADSM server log mode is set to
>ROLLFORWARD (default is NORMAL, which does not afford the
>roll-forward capability).
>
>If the recovery log is in roll-forward mode, and it is
>intact at the time of the failure, then you should be able
>to restore the database up to the time of the failure. The
>restore operation will start with the last full backup of
>the database, followed by any subsequent incremental
>database backups, and finally apply the changes from the
>recovery log.
>
>As a general rule of thumb, if you are in a position where
>you need to restore the database, the DSMSERV RESTORE DB
>operation is the preferred method. In order to be able to
>perform this operation, you should be using the BACKUP DB
>command on a regular basis to take full and incremental
>database backups. This by itself allows you to restore the
>database up to the time of the last BACKUP DB operation.
>With the recovery log mode set to ROLLFORWARD, you can
>restore the database up to the time of failure (again,
>provided that the recovery log is intact).
>
>DUMPDB/LOADDB should be used only as a last resort. In
>this case, I would recommend contacting IBM support
>*before* attempting this operation just to be sure that
>you have no other options.
>
>Historical note: Back in ADSM V1, DUMPDB/LOADDB was the
>only means of backing up and restoring the database. In
>addition, an AUDITDB was often required. These processes
>were/are painfully slow, and should only be used when
>absolutely necessary, which is why I recommend contacting
>IBM support first. ADSM V2 introduced the BACKUP DB and
>RESTORE DB commands, which run much faster and provide
>more comprehensive protection.
>
>Please refer to the ADSM (or TSM) Administrator's Guide for
>further information on this topic. The Admin Guide contains
>information on protecting the server, including discussions
>on the roll-forward capability, backing up the database,
>mirroring the database and recovery log, etc.
>
>Best regards,
>
>Andy
>
>Andy Raibeck
>IBM Storage Systems Division
>ADSM Client Development
>e-mail: storman AT us.ibm DOT com
>"The only dumb question is the one that goes unasked."
>
>As we've been evaluating ADSM I guess I've been making a serious
>error in understanding backup/recovery.
>
>From reading the post below from another thread, do I now understand
>correctly that ADSM has NO ROLL-FORWARD recovery procedure? In other
>words, if you put down a full backup and incrementals, there is no
>way to roll forward to the point in time when the db was lost?
>
>Maybe my terminology is wrong - posting incrementals to a full may be
>"rolling-forward". But, the point is that the recovery log at the
>time of a crash is unusable when you must must do a restore from
>full/incremental backups.
>
>Is this correct?
>
>Thanks
>
>Rick
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
|
