Hi Karen,
Good questions. No, you can not rebuild the ADSM database from the storage
pools so you are correct in placing emphasis on database backup and recovery.
In my opinion, the database and recovery log (they go hand-in-hand together)
are the "heart & soul" of your ADSM system. Ideally you can not over-protect
them, although in a practical world of limited budgets and limited resources,
you may need to make some compromises.
Here is a list of other things to consider:
1) You're probably better off backing up the database to a tape devclass and
sending the tape(s) offsite. This way, your backup copy will be available in
the event of a site-wide disaster.
2) Make sure your mirrors are on separate physical devices, and (ideally)
separate controllers. The idea is to physically isolate the mirrors as much as
possible. Also, you didn't say what operating system your ADSM server is
running on. Some operating systems, like AIX, have mirroring capability built
in to them. Make sure you are using ADSM mirroring and not operator system
mirroring.
3) Consider setting your recovery log to roll-forward mode. In the event you
need to restore the database (or a database volume), it can be restored to its
most current state. Note that a roll-forward recovery requires an intact
recovery log to work, so if a disaster takes out your recovery log (and all
mirrors), you won't be able to do a roll-forward restore. Also, roll-forward
mode will require a significant amount of additional space be added to the
recovery log (probably). So it's a trade-off between the amount of resources it
takes to support roll-forward mode vs. your restore requirements.
If you use roll-forward mode, also look at the DEFINE DBBACKUPTRIGGER command,
as you'll want to set that up. Just be sure you don't substitute the
DBBACKUPTRIGGER for regularly scheduled database backups. The DBBACKUPTRIGGER
is a safety valve, designed to help prevent your recovery log from filling up
completely and bringing your server down. It is not intended to be used "as a
way of life".
4) By default, ADSM writes to the database mirrors sequentially, and the
recovery log mirrors in parallel. Sequential means that the data is written to
one mirror, then to the other after the first write is successful. Parallel
means that the data is written to all copies at approximately the same time.
System failures (like a system crash) can bring ADSM to an abrupt halt, causing
only part of the data to be written to the database or recovery log. This is
known as a "partial page write". When data is written in parallel, the partial
page write could end up on all mirrors, corrupting them. When this occurs,
especially with the recovery log, you may not be able to restart the ADSM
server (not a good thing; this means you would have to recover it). These occ
urrences are relatively rare, but have been known to happen.
By default, the database is written to sequentially and the recovery log is
written to in parallel. These defaults were chosen as a balance between
performance and reliability, as sequential writes are safer than parallel
(because of the potential partial page write problem). However, there is a
performance penalty with sequential writes over parallel. You could set up your
recovery log to do sequential writes, but I recommend you test it to see how it
works out performance-wise. Some customers have done this and found the
performance hit to be negligible.
To change how ADSM writes to the recovery log or database mirrors, you need to
modify the server options file. The options are:
MIRRORWRITE DB SEQUENTIAL or PARALLEL
MIRRORWRITE LOG SEQUENTIAL or PARALLEL
The defaults are:
MIRRORWRITE DB SEQUENTIAL
MIRRORWRITE LOG PARALLEL
5) Back up your storage pools to a copy storage pool. This protects the primary
storage pools from media failures as well as provides for offsite recovery.
Storage pool backup is effectively an incremental backup of your primary
storage pools. The first time you run it, it backs up the the storage pools in
their entirety. Thereafter, it backs up only new data in the primary pools.
6) Consider setting the REUSEDELAY parameter of your tape storage pools (the
default is 0). When a storage pool tape becomes empty (by attrition,
expiration, reclaim, MOVE DATA, etc.), it is normally returned to the scratch
pool and made available for immediate reuse. This means that if you were to
restore the database to a point in time when ADSM had data on the tape, but the
tape itself had since been reused, ADSM would not be able to access the data on
the tape. Thus data has been lost. (When this happens, you need to do a DELETE
VOLUME with the DISCARDDATA=YES option.)
When a tape becomes empty, the REUSEDELAY parameter tells ADSM how long to keep
the tape in a PENDING state before returning it to scratch. For example, if
REUSEDELAY is set to 3, then ADSM will hang on to the tape for 3 days from the
time it becomes empty to the time it returns it to scratch. This means that if
a tape was deleted yesterday and you restore the database to 2 days ago (when
ADSM had data on the tape), the tape will still be available.
So how many days should you set REUSEDELAY for? The answer is at least the
number of days since your last full database backup. If your plan is to keep
'x' number of full database backups around for recovery purposes, then set
REUSEDELAY to at least as many days as you keep the full database backups.
Note that there is a trade-off (nothing is free): REUSEDELAY allows you to
maintain integrity of the database and storage pools in the event you have to
restore the database to a previous point in time, but the price is that you are
inventorying empty tapes for a lot longer. This means you need more scratch
tapes, and you also need more slots to store them in, including your offsite
tapes.
7) Implement the VOLUMEHISTORY and DEVCONFIG options in the server options
file. This allows ADSM to back up volume history and device configuration
information to sequential disk files. In the event that you need to restore
your database, ADSM reads these files to determine which tapes to mount (in
correct order), and on which devices they can be mounted.
8) During your daily backup scheme, you should back up the database after
backing up the storage pools. Once the database backup completes, run BACKUP
VOLHISTORY and BACKUP DEVCONFIG, then make backup copies (external to ADSM) of
the volume history and device configuration files. These are the files
specified in the VOLUMEHISTORY and DEVCONFIG options I mentioned in item #7
above. It would also be a good idea to issue QUERY DB, QUERY DBV, QUERY LOG,
and QUERY LOGV commands and saving the output, as these describe your database
and recovery log configuration. Also collect the server options file. Then send
all of this stuff offsite, along with the database backup and storage pool
backup tapes.
I hope this helps,
Andy
Andy Raibeck
IBM Storage Systems Division
ADSM Client Development
e-mail: storman AT us.ibm DOT com
Please respond to ADSM-L AT VM.MARIST DOT EDU
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Database backup procedures
As a soon-to-be in production ADSM site, I have had a concern expressed to
me about the backup of the ADSM database. Since the ADSM database is so
critical to the proper functioning of ADSM, what are the best steps taken to
ensure that it can be restored in case of a problem? To date, we are doing
the following:
1) Mirroring the db and recovery log
2) Backup the db to a file on disk on the ADSM server every day.
Eventually, we also plan to copy the db file to a tape or onto another ADSM
server. At what age does that db backup become useless (24 hours, 1 day, 3
days???)
Any other ideas on how to take the best care of the database and recovery
log? If the database is truly lost, can the tapes in the ADSM library be
re-read to re-build the database?
Thank you for your ideas and comments.
Karen Krowzack
IBM Global Services
Tieline 461, x7309
Outside phone - 312-394-7309
Pager: 800-759-8888, PIN 1967096
email: Karen.M.Krowzack AT ucm DOT com
|
