Laurence Beard writes:
> I have written unix scripts to backup an ORACLE database via 6 GByte
> storage pools -> 2 x 8mmtape(5Gbytes). At the end of the backup I do a
> "update stg backuppool hi=0"
> This causes the data in the storage pool backuppool to be moved from
> disk(storagepool) -> 8mmtapes. This means everything is on tape, such
> that, migration = 0%, and utilization can be > 0%.
> If I were to do the following
> 1."backup db type=full..."
> 2. Delete everything in that database i.e. delete volumes and "delete
> filespace <CLIENT> *" etc.
> 3. Shut down server ,and "dsmserv restore db".
> Could I expect the ADSTAR database to look exactly the same at the
> time of the "backup db type=full..", complete with all volumes and
> storage pools. I am not concerned about the any data in the storage
> pools as I have migrated it out to tape.
I'm not sure if what you wrote is really what you mean, as it sounds
like you think that the data no longer exists in a storage pool when it
is migrated to tape. It is important to note that the data still exists
in a storage pool, only it consists of tape rather than disk.
> This is how I am trying to implement my Disaster-Recovery, rather than
> creating a disaster-recovery stgpool as in Chapter 14 of
> Administrator's Guide for ADSTAR and backing up from
> backuppool->disaster-recovery any unmigrated files.
In answer to your question, yes, the ADSM database will look just like it did
at the time you did the
BACKUP DB. However, your storage pools (even the tape pools) might not look
quite the same.
Backing up the database is only a part (although a very important part!) of
implementing a disaster
recovery backup scheme for ADSM. The other major piece of this scheme should
include protecting
your ADSM storage pools. Otherwise, if a disaster wipes out your ADSM database
and storage pools,
you'll be able to restore the database, but you won't have any client data.
This would render your
ADSM server useless.
In general, for complete protection, you should:
1) Back up your ADSM database (protects the database).
2) Consider backing up your storage pools (protects against storage pool volume
media failures).
3) Consider running your recovery log in roll-forward mode (in conjunction with
database backups,
allows you to restore your database up to its most current state if you have a
local failure, provided
that the recovery log is still intact).
4) Consider using ADSM to mirror your database and recovery log volumes to
protect against
database and recovery log media failures. For AIX, you should use ADSM
mirroring, not AIX
mirroring.
5) Consider setting the REUSEDELAY setting in your tape pools to some non-zero
number that
represents the maximum number of days that you would expect to ever regress
your database in
the event of a disaster. For instance, if you plan on being able to go back at
least 2 days, set
REUSEDELAY to 2 (or maybe 3, just to be safe) for the tape pools. This will
ensure that, should you
have to regress your database (such as in a disaster recovery situation), tapes
that the regressed
database thinks it owns will still be available. For example:
Monday: Back up ADSM database. Later on, reclamation causes tape TAP001 to be
released.
Tuesday: TAP001 is reused
Wednesday: Disaster strikes and you need to restore your ADSM database to the
state it was in as of Monday. After the restore, ADSM will think it has good
data on
TAP001, when in fact that tape had been written over. A REUSEDELAY of "3" would
prevent
this from happening, since the tape would not truly be deleted from ADSM's
inventory
until at least 3 days have gone by. Thus when the database is restored, the
data on the
tape will still be intact.
Note that, just as in real life, there is no "free lunch". All of these things
will consume resources,
including media, processor cycles, etc., so it's a trade-off. The key is to
understand the risks,
then weigh those risks against the cost of protecting against them, and
deciding which way you
want to go.
Consider the following sequence in backing up for disaster recovery:
Back up your storage pools (BACKUP STGPOOL)
Back up the ADSM database (BACKUP DB)
Run BACKUP VOLHIST to back up volume history
Run BACKUP DEVCONFIG to back up device configuration information
It's also a good idea to have the output from these commands on hand in case
you
need to restore your ADSM server:
Q DB F=D
Q DBV F=D
Q LOG F=D
Q LOGV F=D
Make backup copies external to ADSM of the volume history and device
configuration
files.
Send the following items offsite:
Newly created copy storage pool volumes
ADSM database backup media
External backup copies of volume history and device configuration files
Output from the above QUERY commands
ADSM server options file
There may be other variations on this that other folks might suggest, but I
think I've got the highlights.
Hope this helps. Good luck!
Andy Raibeck
ADSM Level 2 Support
|
