ADSM-L

How I use the ADSM V2 disaster recovery features

1995-12-15 02:09:32
Subject: How I use the ADSM V2 disaster recovery features
From: Andy Raibeck <raibeck AT CONNIX DOT COM>
Date: Fri, 15 Dec 1995 12:09:32 +0500
Dennis Riley asked me this question, and I thought I'd share my experiences
with the rest of the ADSM-L subscribers, since I haven't seen much on this
particular topic.

>  Could you send me some information on your disaster recovery setup
> for ADSM. What mechanism do you use to get data to your DISASTER_RECOVERY
> pool? Seperate schedules? Do you backup the database also? I like to
> investigate storing some backups offsite for disaster recovery purposes
> and I'm interested in how you're implementing this. We have ADSM for MVS v2,
> backing up AIX , HP-UX , SunOs, IRIX, Ultrix, Windows, OS/2 and NT, about
> 100 nodes.

Most of my disaster recovery stuff is driven by the ADSM scheduling facility.
Here's what a day in the life of ADSM disaster backup looks like at CML:

06:30 - A schedule runs to issue the BACKUP STG command for my disk backup
        storage pool:
        BACKUP STGPOOL BACKUPPOOL DISASTER_RECOVERY MAXPROCESS=6

06:30 - A schedule runs to issue the BACKUP STG command for my disk archive
        storage pool:
        BACKUP STGPOOL ARCHIVEPOOL DISASTER_RECOVERY MAXPROCESS=2

06:30 - A schedule runs to issue the BACKUP STG command for my tape backup
        storage pool:
        BACKUP STGPOOL TAPEPOOL DISASTER_RECOVERY MAXPROCESS=2

09:30 - A schedule runs to issue the UPDATE VOLUME command for my disaster
        recovery copy storage pool. This command changes all the volumes
        created by the 06:30 processes so that their access is 'offsite':
        UPDATE VOLUME * ACCESS=OFFSITE LOCATION='IRON MOUNTAIN' +
           WHERESTGPOOL=DISASTER_RECOVERY WHEREACCESS=READWRITE,READONLY +
           WHERESTATUS=FILLING,FULL

10:00 - A schedule runs to issue the BACKUP DB command:
        BACKUP DB DEVCLASS=VAULT TYPE=INCREMENTAL (Monay - Friday)
        BACKUP DB DEVCLASS=VAULT TYPE=FULL (Saturday)

11:00 - A CA-7 job is triggered to get a pull list for our tape operators
        for all newly-created volumes that I send offsite. These include
        volumes created by the database backups and the storage pool backups.
        The qualifier defined in my VAULT device class is 'DSMVAULT'. My
        other device classes use 'DSM'.

12:00 - A schedule runs to delete old volume history information:
        DELETE VOLHISTORY TODATE=TODAY-35
        (Note: 35 days is a lot, and I will probably eventually lower
        this to something like 10 days.)

15:00 - A schedule runs to issue the BACKUP STG command for my disk backup
        storage pool:
        BACKUP STGPOOL BACKUPPOOL DISASTER_RECOVERY MAXPROCESS=2


One thing I need to add is a job to dump those ADSM data sets that I would
need in a disaster recovery situation to tape: volume history, device class
files, disklog, linklib, message libs, help libs, etc. This would run some-
time between when the database backup ends and the 11:00 pull list job.

When I originally set this up, the tape pool was the hardest to get fully
copied to the DISASTER_RECOVERY pool. That's because I well over 1,500
3480 tapes to read. So I took a phased approach to this.

First I set up the schedules to back up the two disk pools: ARCHIVEPOOL and
DISKPOOL. This incurred scratch mounts only, so it wasn't a problem. The
bulk of my ADSM activity is in backup, so I ran these two schedles for about
3 weeks before attempting to back up the TAPEPOOL storage pool. By doing so,
I was able to copy all *new* backup versions from my disk pool to the
DISASTER_RECOVERY pool, and over that 3 weeks, turn over a large number of
versions that existed in the tape pool. The net effect was that I avoided
backing up a lot data from my tape pool that would have expired in a few
weeks anyway, and thus avoided a ton of input mounts. I'd waited this long
for the disaster recovery features, how much difference would a few extra
weeks make? The upshot is that when I finally started backing up my tape
storage pool, I ended up not needing to mount around 40% of the tapes in
my tape pool (because I already had backups for those versions from when
they were in the disk backup pool).

Due to drive allocation problems, and the time it took for manual tape
mounts (we are not "roboticized"), I had to start and stop the tape pool
backup quite a few times. But over the course of 3 or 4 weeks, I finally
managed to get *all* of my primary storage pools backed up to the copy
storage pool (DISASTER_RECOVERY). The entire process took around 2 months.
Once that was complete, I added the schedule to back up the tape pool on a
daily basis.

I do have workstation backups that run during the day. I then migrate most
of my disk backup pool to tape, later in the day (4PM). However, since these
more recent backups haven't been backed up yet to the DISASTER_RECOVERY
pool (they were created after the 6:30AM storage pool backup processes),
I'd incur input mounts when the TAPEPOOL backup process started at 06:30 the
next day. So I added another schedule to back up my disk backup pool at 3PM
in order to minimize the number of input mounts required the next morning.

It would be nice if I could base some of these schedules on events, rather
than time of day. For example, set ADSM up so that when all three storage
pool backup events complete (the 6:30AM ones), the UPDATE VOLUME command
will then execute, followed by the BACKUP DB command. But for now, time of
day works out. The backup for the disk backup pool takes the longest, around
an hour and a half to two hours or so. The UPDATE VOLUME runs in a minute
or less. So I've got plenty of surplus time built in to the schedules.

Andy Raibeck
Connecticut Mutual
203-987-3521
<Prev in Thread] Current Thread [Next in Thread>
  • How I use the ADSM V2 disaster recovery features, Andy Raibeck <=