-----Original Message-----
From: Prather, Wanda
To: 'Korpi, Don '
Sent: 2/1/01 7:08 PM
Subject: RE: Volhistory file and DR
You are correct, you can construct a VOLHISTORY file yourself at the DR
site, or work without it.
When you run a RESTORE DB, if you don't specify the VOLUME, TSM looks in
the VOLHISTORY file to find it (and the associated DEVCLASS).
If you specify the VOLSER and devclass yourself, you don't even have to
have the VOLHISTORY file available.
The disadvantage if NOT having the VOLHIST is it puts a heavy burden on
you for record keeping, and maybe requires the person in charge at the
recovery site to be a bit more knowledgeable.
And what about your DEVCONFIG to get your devclass and devices redefined
correctly? And what about your DB and LOG size? Those are things you
ALSO will need to know to put your system back together at the recovery
site. We pull hardcopies of that stuff, too, and send it along with the
vault list.
(Or if you use DRM, just print a copy of the plan file.)
Anything that gets the information out there....
-----Original Message-----
From: Korpi, Don
To: [EMAIL PROTECTED]
Sent: 2/1/01 9:28 AM
Subject: Volhistory file and DR
Hello,
I have reviewed several old postings concerning the purpose of the
VOLUMEHISTORY file and am under the impression that as long as I know
what
volume contains my last good DB backup, I could manually create a
VOLUMEHISTORY file in the event of an offsite disaster recovery. This
is
operating under the premise that once the DB is restored, a new
VOLUMEHISTORY file is created anyway, based on the records within the
DB.
I send full DB backups offsite daily and would receive a hardcopy of our
vault listing, which calls out the newest DB backup, along with the
tapes
at the DR site.
Does anyone know of a reason that I would need to send a VOLUMEHISTORY
file
offsite, given the above information?
I am attempting to eliminate a cumbersome and unreliable 3.5" diskette
we
have been sending offsite daily with this information.
Thanks,
Don
