One solution would be to have a console automation routine watch for the
process complete messages, and then kick off the next operation. I have not
tried this, and would imagine it to be quite messy, especially when the
process is interrupted.
Another problem is the amount of activity that is going on during all of this
if you have a large amount of data to be backed up, then the process can
drag out for a long period of time. One problem we have is timing - Servers
back up in our shop most of the evening, desktop PCs backup after midnight,
and people with Laptop machines back up during the day. In addition, some
people do ad hoc backups (or don't want to use the scheduler) and backup
anytime.
When faced with this problem, we chose to use a cycle approach as follows:
Since servers backup most of the evening, we kick off a backup of the DASD
pool at 5AM. (we have separate pools for Servers and PCs). SInce it is
always better to backup the data while it is on disk, rather than tape, we
try to get this at the end of our batch cycle, when the DASD pool is full,
and has not yet been migrated. At approximately 7:00AM, we back up the
server tape pool, if there is anything to be done. For the PC people, we
backup their DASD storage pool at 3:00 in the afternoon, when activity is
usually done for the day. at about 5, we backup the PC tape pool. Archive
pools for both server and PCs are not used much here, so we just include the
backups for these at the same times as the regular backup pools.
Backup of the DB is always going to be a "best shot" problem for us, because
of activity. We have elected to do a Full backup weekly - Saturday noon -
nobody seems to be doing anything then. We do daily incrementals at 6:00.
This is a long span between full backups, but a DB backup for us is 19
volumes of 3480 tapes currently, and so doing it daily is not something I
want to think about. We are upgrading to 3490 this month, and hopefully this
will help. Now if I can get them to do "e" model tapes...... It would
really be nice if IBM would let us do 2 copies of the DB backup when the tape
is created.....
We do our backup vol hist, etc. just before noon each day, followed by a
delete volhist today-22 to insure that we have 3 weeks of data. Each
Saturday, morning (before the DB backup is taken), we send everything
offsite.
BTW, we issue the update vol command each night at 8:00.
The TMS pick list for offsite selection is keyed off of the messages issued
by the update vol command. It runs each night after midnight.
Are there holes in this? YES. Can we eliminate them? Probably not. Can we
live with what we have? We have to.
In an ideal world, we could stop all activity while we get our backuppool
copies and DB backups. But the world we live in is too busy to allow this.
So we have to do the best we can.
One thing that helped me was to use a timeline - chart all of the activity
for your shop on it, and then schedule backups at appropriate times.
Remember too that things like TMS nightly cycles probebly are out of your
control, so you have to live with them.
Hope this helps. If you have any questions, email them to me.
Jerry Lawson
jlawson AT thehartford DOT com
______________________________ Forward Header __________________________________
Subject: Automated Steps to Create Tapes for Disastere Recovery
Author: INTERNET.OWNERAD at SNADGATE
Date: 6/27/97 6:23 PM
The ADSM server environment for this question is MVS.
I would like to be able to automatically schedule the following steps to be
executed one after another.
It is important that step 2 is not started until all the commands in step 1
are finished. The same is
true for the rest of the steps.
Step1: Incremental backup of primary storage pools
ADSM commands:
backup stgpool backupppool disaster-recovery
backup stgpool archivepool disaster-recovery
backup stgpool spacemgpool disaster-recovery
backup tapepool disaster-recovery
Step 2: Update volumes to offsite status
ADSM command:
update volume * access=offsite location='vault site info' -
wherestgpool=disaster-recovery whereaccess=readwrite,readonly -
wherestatus=filling,full
Step 3: Backup ADSM database
ADSM command:
backup db type=incremental devclass=devclassname scratch=yes
Step 4: Backup volume history, device configuration and server options
files to be taken to disaster recovery site.
Use MVS utilities backup volume history, device configuration and server
options files to be taken to disaster recovery vault site
Step 5: Create a disaster recovery pull list from CA-1 TMS which lists all
ADSM
datasets with the disaster recovery dataset prefix which are on site.
|
