Ok, so you're really doing a proof of concept of your dasd replication solution. Obviously, once in production one doesn't want to stop replicating just to do a test, unless you don't care how stale your DR data gets. So once the concept is proved, you'll have to come up with procedures to do testing which will involve various R2's, BCVs, PIT gold copies, etc. You'll need to understand those requirements ahead of time to properly size your DR dasd solution. We also successfully restore our VTAPE library using this technique. It is very small (one or two mod 3's), but the concept is extensible.
________________________________ From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard Sent: Thursday, November 11, 2010 4:11 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: BRP In essence, we will be breaking the connections with the main system at a time not previously disclosed to us, and will not be allowed to go back to it or reference anything on it for the duration of the test. We will have to resync the dasd after the test has been completed. The main system will stay up and running so that those who are not part of the test can continue working. Far from defeating the purpose of the test, which is to demonstrate that we can get the BRP system up and fully functional in x hours (x has yet to be determined, but it will be fairly small, without reverting to using the main system to help in any way. With the tape backup system, x used to be 24; however, it was trimmed to be only 12 and we demonstrated that it could not be done in that time frame. The restore of our (VSSI) VTAPE library, which is not tiny, did not complete during the window. It had been running for almost 8 hours and was only about half done when the window closed. We just got confirmation that the current configuration at the DR site has not been kept up to date. :-( That is a problem we do not expect to have if we are replicating the dasd. Regards, Richard Schuh ________________________________ From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Quay, Jonathan (IHG) Sent: Thursday, November 11, 2010 10:51 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: BRP If you can't snap off a copy what are you going to do during a test? Stop replicating? Kind of defeats the purpose. Anyway, we've never had a problem with the vm or linux filesystems. A lost inode here or there, but that is to be expected. ________________________________ From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard Sent: Thursday, November 11, 2010 12:05 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: BRP VM is my main concern, we already have multiple copies of TPF at different centers. The TPF folks have their own DR requirements, including "no complete network outage". We are concerned with the ability to update source and test the updates, which requires both VM and Linux, and to run potentially critical applications that require VM. z/OS has its own set of requirements which are at least partially met by there being running instances of z/OS at each of the centers. Our DR site is a CBU LPAR in our other datacenter. The hardware configuration is (supposedly, no confirmation as yet) maintained in parallel with our running system. Once the DR test starts, we will be allowed no contact with the running system and there will be no ability to "snap off" a copy prior to the test - in fact, it is expressly forbidden. Regards, Richard Schuh ________________________________ From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Quay, Jonathan (IHG) Sent: Thursday, November 11, 2010 8:28 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: BRP We also have all EMC dasd. To guard against application faux pas that are not immediately discovered, we maintain 3 copies of TPF at 8 hour intervals (we can also bring home our offsite copies, which you need to be able do when a real disaster is over). For DR testing, we snap off point-in-time copies of TPF, z/OS, z/VM, and z/Linux (ECKD) dasd. We bring up TPF under our z/VM at the DR site so we can remap devices to correspond with the vendor provided hardware environment. It all works like a charm. Once the vendor moves our dasd over, we IPL z/VM, check the hardware environment, then un-NOLOG TPFPROD, and IPL it. Getting the network switched over takes more time than this, so we wind up waiting on them. ________________________________ From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard Sent: Wednesday, November 10, 2010 7:51 PM To: IBMVM@LISTSERV.UARK.EDU Subject: BRP Finally, the powers that be are considering remote shadowing of DASD as the way to handle the BRP situation. The time we are allotted to recover the system has been reduced to a number that is impossible using tape backups. I would appreciate it if anyone who is already doing this would regale me of their experiences - what they are doing, what are the gotchas, how satisfied are they, etc. It undoubtedly is different depending on the dasd vendors so here is what we have: * EMC DASD - about half of our DASD. * HDS DASD - the other half. * Currently, there is no SCSI, it is all ECKD We currently have no IBM DASD; however, that does not mean that we will not have some in the future. Every couple of years, we go through a DASD refresh, at which time we may change vendors. I will gladly accept replies on or off list. TIA. Regards, Richard Schuh
