ADSM-L

Migrating V1 to V2 (VM) without messing up the tapepool.

1998-01-15 18:10:54
Subject: Migrating V1 to V2 (VM) without messing up the tapepool.
From: Joseph A Faracchio <SPGJAF AT CMSA.BERKELEY DOT EDU>
Date: Thu, 15 Jan 1998 15:10:54 PST
Well, one of our New Year's resolution is to get off of Version 1.
We have a VM system that we've been running Version 1 since we
replaced a WDSF/VM setup.   Back then it was still in pilot test,
so we didn't bother to carry our users over from WDSF to ADSM.
But now we have too many 'paying' users to do the same thing.

We are doing an ADSM migration plan from V1 to V2, and I've decided
on using IBM's Bite-the-bullet-style suggestion but with a twist
that makes it better for backing out of it.

According to IBM when you bring up the V2 server on a V1 database
it has a conversion run that can not be reversed.
Naturally , IBM recommends backing up the database.
But I wondered how I could "backup" the      *** tape pool ***.
After all, once the new version is running for a day, thresholds will
kick in and tapes will get written over, created or scratched.

We have 2 copies of the database on disk and we also backup to tape.
So going back to V1 is not an issue for the database, but I'm worried
about the tape pool becoming unusable and if we have to fall back to
Version 1 then  I don't want to have to do a data base checkpoint
audit as well.   (To get the database in-sync with the tapes.)

After a little thought I wondered if this would work -

Set all the in-use tape volumes to Read-Only before letting users
onto the Version 2 setup, add more scratch tapes to the pool
and (temporarily) turn off collocation and let it run that
way for about 3 days.  Then tape writing with be *only* to new tapes.

If problems occur anytime before the 3 day cutoff then go back to
the old system, tell users that backups for the last 3 days have been
invalidated & make the tapes read-write again. Then investigate the problems.

Comments?

I know this may be a little overkill but I don't want
to have a long test period in parallel and I don't want to be
messing around with a complicated back-out that involves redoing the DB.

thanks in advance for you thoughts!
                                     ... joe.f.
<Prev in Thread] Current Thread [Next in Thread>