Kris,

All true.  I just didn't want to go into too much detail to express a 
simple point.

We do use DASD-vendor provided software (neatly avoiding posting the 
vendor name) which provides writes to all mainframe DASD to be 
concurrently written to DASD at both campuses.  The DASD at each campus is 
then mirrored at each campus.

In preparation for the D.R test, the DASD vendor breaks the software link, 
causing each campus to have their own set of up-to-date mirrored DASD. 
Following the test, the vendor restores the link, and the D.R. site DASD 
(now out of synch) is automatically refreshed from the production copy. 

I'm the z/VM guy, I won't pretend to know all the technical details about 
how all that magic is performed, but instead just get to enjoy its 
benefits. 

Yet I do sometimes miss those occasional 44-hour+ 
straight-through-without-sleep bits-and-bytes D.R. tests.  That's when the 
creative problem-solving juices really flow - when something in the D.R. 
plan breaks and you need to quickly develop a creative solution. 

Now, with split campuses and "mirrored" (to use the simple term) DASD, 
it's mostly boring - even if we do get bragging rights every time because 
that z/VM system is back up within about 20 minutes of being given the 
LPAR.  OTOH, z/OS with DB2 and a "few" more apps is "just slightly" more 
complicated.  ;-)

Mike Walter
Hewitt Associates
The opinions expressed herein are mine alone, not my employer's.




"Kris Buelens" <kris.buel...@gmail.com> 

Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
12/16/2009 01:39 AM
Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>



To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: VM Best Practices






Mirroring does not replace good backup tapes: an accidental ERASE or 
FORMAT is mirrored perfectly well to your DR site.
Secondly: if you simply have a two copy mirror, performing DR tests means 
you break the mirroring during the test and at that time you no longer 
have a mirror.

2009/12/16 Ivica Brodaric <ivica.broda...@gmail.com>
Mike,

I didn't mean to be smart, sorry if it came out that way. I just wanted to 
stress that everything you need to perform a DR, including hardcopy 
reports, utility tapes, DR procedure manual, CD's with software 
manuals, etc. has to be on a DR site or in the off-site storage, that's 
all. 

Of course, mirroring makes that much easier, because your DR system is 
just waiting to be IPLed. You have to send less stuff off-site, a lot of 
it can be kept on disks. Anything that you may need *before* you bring up 
VM, and that answers questions "where is...?" has to be either in the DR 
manual or in the hardcopy report on the DR site.
  
My recent experience is also with mirroring - two sites running half of 
production load each, disk mirroring each way. LPAR configs were identical 
between sites and DR meant logging on one second level VM on each 
surviving VM(*) and PROFILE and other EXECs would take care of the rest. 
But I still miss the good ol' days of walking into a DR site and actually 
*doing something* to restore the system. Oh, wait, maybe I don't. It's 
just nostalgia. I was just much younger then. :-)

Ivica

(*) I don't suggest this setup unless you have plenty of storage and zero 
paging in production LPARs. At least that.



-- 
Kris Buelens,
IBM Belgium, VM customer support




The information contained in this e-mail and any accompanying documents may 
contain information that is confidential or otherwise protected from 
disclosure. If you are not the intended recipient of this message, or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message, including any attachments. Any 
dissemination, distribution or other use of the contents of this message by 
anyone other than the intended recipient is strictly prohibited. All messages 
sent to and from this e-mail address may be monitored as permitted by 
applicable law and regulations to ensure compliance with our internal policies 
and to protect our business. E-mails are not secure and cannot be guaranteed to 
be error free as they can be intercepted, amended, lost or destroyed, or 
contain viruses. You are deemed to have accepted these risks if you communicate 
with us by e-mail. 

Reply via email to