These have been great points.
So to summarize.
For Mainframe
1) Plan for both OR/BC and DR conditions.
This includes testing as often as the company allows. Paper tests only
satisfy a minimal requirement but does not show the plan will actually work or
how long the plan will take to get the systems back up.
2) Replication is great unless there is data corruption.
3) DFHSM Backup/Dumps could be a good supplement to protect against data
corruption (Multiple Gens for critical files)
4) Tape is excellent for offsite storage in case there is not a secondary DR
site owned by the business
5) Make sure not only critical application/system files are there at the DR
site, but also include things like SMF data, LOGREC, DCOLLECT, and other
miscellaneous but not often thought of files. Depending on where these files
are located (DASD vs. DISK) you may be okay.
6) No plan is foolproof.
7) The company would benefit from having a full time VP of DR. (Or some high
position). Assigning this process to a Supervisor of Operations probably will
not be sufficient as they are very busy with day to day chores.
I have seen that some of the management teams that are responsible for Storage
(which might be both Open Systems and Mainframe) think that both areas can use
a similar type of DR or OR/BC plan. I can see some overlap, but I do believe
the way the Mainframe does backup and recovery for these areas is different
than a midrange or open systems backup and recovery.
So when management starts reading all of these DR or OR/BC papers by Symantec
or Dell or other vendors, they start to think the Mainframe is the same. This
discussion is helping to show how these functions are different.
Did I miss anything?
Thanks.
Lizette
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Tom Marchant
Sent: Thursday, May 30, 2013 2:16 PM
To: [email protected]
Subject: Re: To Backup or Not to Backup Data - That is the question
On Thu, 30 May 2013 11:44:32 -0700, Lizette Koehler wrote:
>So do I have overkill? .
Software disasters can be the hardest ones to plan for. What do you do if one
of your critical applications has a program change that causes it to start
corrupting data? How long will it take before it is noticed? This can be a
lot harder than a hardware failure.
--
Tom Marchant
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
