Laurence Beard wrote:
> 1. In your comment: " It is important to note that the data still
> exists in a storage pool, only it consists of tape rather than disk"
From the phrasing in your post (for example, "I am not concerned about
any data in the storage pools as I have migrated it out to tape."), I
thought that you might be under the impression that once it migrates
to tape, it no longer resides in an ADSM storage pool. TAPEPOOL is an
ADSM storage pool, just like BACKUPPOOL.
> I was wondering, at the end of every backup from UNIX to ADSTAR, I am
> moving all from BACKUPPOOL -> TAPEPOOL, by setting "update stgpool
> packuppool hi=0", at this
> point the stgpool of concern is TAPEPOOL that I should look at
> recoverying for DR, or still the BACKUPPOOL as well ?
If you *know* for sure that data resides only in the tape pool, then
you don't have to back up the disk pool. However I usually recommend
erring on the side of caution. For instance, what if a migration process
fails for some reason, and you don't catch it? You would then still have
data resident on disk, and would thus be exposed if you don't back up
the disk pool. On the other hand, if the migration is successful, then
the disk pool backup won't back up anything. So you've really got
nothing to lose by backing up the disk pool.
A couple of hints:
1) If you are migrating everything to tape, consider turning disk pool
caching off, since it really won't buy you a whole lot.
QUERY STGPOOL poolname F=D
and look at the "Cache Migrated Files?" field. If it says "Yes", then
issue the command:
UPDATE STGPOOL poolname CACHE=NO
2) Getting back to disk pool backup for a moment: consider backing up
the storage pools *before* you migrate.
If you migrate from disk to tape, then subsequently run BACKUP STGPOOL,
ADSM has to mount the tapes you migrated to as input, and new tapes
for the copy storage pool as output. If you do the BACKUP STGPOOL
before the migrate, then ADSM only has to mount the output tapes,
since the input is still on disk.
In this case, you might then ask whether you need to do a BACKUP STGPOOL
for the tape pool since you are capturing everything while it is still
on disk. Again erring on the side of caution, I'd say yes; you've got
nothing to lose.
> 2. (***CONFUSED***) From the ADSTAR Administrator's Guide, you create
> a DR stgpool and use "backup stgpool backup..." for primary stgpools.
> Currently, I have 6GByte (raw) for BACKUPPOOL (everything is a FULL
> cold backup of ORACLE database about 15 GBytes/day for 5 days), this
> is the only stgpool I am using, with migration to TAPEPOOL.
> Does the DR stgpool require extra disk space above the 6 GByte for
> BACKUPPOOL ?
No.
Most folks use tape for their copy storage pool. In fact, you can not
define a copy storage pool whose device class type (DEVTYPE) is DISK.
> Is the DR stgpool called a "copy storage pool" ?
Yes.
> From the above figures, how much data will I have to backup from the
> DR stgpool to tape (scratch vols) ?
> I am of the impression that I need to backup the data twice, once in
> the primary stgpool and also in the DR stgpool ??
No. You only back up primary storage pools. Think of BACKUP STGPOOL as
an incremental backup of your ADSM primary storage pools.
For example, suppose you have two primary pools:
BACKUPPOOL (the 6 GB disk pool you mentioned)
TAPEPOOL
You can define one copy storage pool called (for example):
COPYPOOL
To back up your primary pools, you could then issue two BACKUP STGPOOL
commands as follows:
BACKUP STGPOOL BACKUPPOOL COPYPOOL
BACKUP STGPOOL TAPEPOOL COPYPOOL
COPYPOOL should be large enough to house the combined data in BACKUPPOOL
and TAPEPOOL.
Although I don't think a lot of people do this, you can have multiple
copy storage pools. For instance, you could define a new copy storage
pool called:
COPYPOOL_2
Then in addition to the above BACKUP STGPOOL commands, you would also do:
BACKUP STGPOOL BACKUPPOOL COPYPOOL_2
BACKUP STGPOOL TAPEPOOL COPYPOOL_2
This will effectively give you *two* backup copies of your primary
storage pool.
> The logmode is rollforward, does "dsmserv restore db" backup anything
> of the logs, or does this all ready have to be intact on the system?
> If so, then how does the database recover to the time of total
> failure, when the system has to be completely rebuild ? Should the log
> be backed up also?
You don't back up the recovery log.
Recovery up to the time of failure applies only when the recovery log is
still intact. For example, in the case where a hard drive failure results
in the loss of your ADSM database. If you lose the recovery log, or if
you have a "real" disaster where your data center is wiped out, then all
you have (hopefully) is your offsite BACKUP DB tapes. In this case, at
your hot or cold site, you would have to recreate your database and
recovery log volumes from scratch, and then run the "dsmserv restore db
todate=?????". Since your live recovery log was wiped out, you can only
restore up to the time of your most recent BACKUP DB.
By the way, in my last post I recommended having the output from several
QUERY commands. This is so that you have information on how large your
database and recovery log volumes were, since the "restore db" command
requires that the database be the same size as it was when you backed
it up. For example, if you had a database consisting of two 400 MB
volumes (total 800 MB), then you must create a new database that is 800
MB in size. The number of volumes is not important, but the size is. So
you can create one 800 MB volume, two 400 MB volumes, four 200 MB
volumes, etc.
Andy Raibeck
ADSM Level 2 Support
---------------------- Forwarded by Andrew Raibeck/San Jose/IBM on 07-17-97
05:11 AM ---------------------------
05:11 AM ---------------------------
ADSM-L @ VM.MARIST.EDU
07-16-97 10:43 PM
Please respond to ADSM-L AT VM.MARIST DOT EDU @ internet
To: ADSM-L @ VM.MARIST.EDU @ internet
cc:
Subject: Re: Disaster Recovery and DSMSERV RESTORE DB
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.
Deleted stuff...
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
|
