If you regularly run full production on Site B for any significant
length of time just to prove DR process works, and Site A is physically
functional at the time, I would think once you are sure Site B is fully
functional you would want to establish mirrors of Site B back to Site A
as soon as practical so that Site A now serves as DR backup site for
production at Site B. Then when ready to switch back to Site A, choose
a time to reverse your DR process, do recovery at from Site B to Site A,
and revert mirroring back to Site A mirrored on Site B when recovery
complete.
If you actually run production at a DR recovery site, moving back
becomes the same as a DR recovery process with site roles reversed, the
only difference being that you normally get to chose the time of the
move back rather than having the timing driven by a disaster event.
Although one can conceive of DASD subsystems being clever enough to
retain synchronization information and somehow just reverse the
direction of data flow and synchronization control for a DR test
production switch over, I would think the main point for such a complete
test would be to prove that switch over and return of production will
actually work in a real disaster,which could involve physical loss of
all or part of the primary data center. So even if it were technically
possible to avoid complete data transfer back to Site A after a test
move of production, I would think it would be "cheating" to assume
during a full switchover test that the original production DASD
subsystems would still be at site A with original content when ready to
resync DASD, as the procedure for handling a real disaster must assume
that is not the case.
JC Ewing
On 06/06/2013 08:08 PM, Skip Robinson wrote:
OK, I really did not understand the process. Site A mirrors to Site B.
True production runs at Site B for some time. Then you want to mirror back
to Site A with then current data resulting from ongoing production at Site
B.
The answer is that you must entirely mirror *all* data from Site B back to
Site A in order to get up to date. It's not just a matter of reversing
direction. It's how XRC works (and I suspect also PPRC although I have no
experience with it).
In the case of XRC, data updates are sent continuously to the receiving
site. If the receiving site goes temporarily unavailable via XRC SUSPEND,
the sender is notified to keep track of updates in a bit map in each
controller. When XRC is RESUMEd, the sender uses the bit map to 'refresh'
the receiving site and bring his copy current. All of this depends
entirely on the receiving site picking up exactly where he left off with
absolutely nothing changed on his side during the interruption. All
missing updates are applied--accumulated ones as well as ongoing
updates--until both sites are back in synch.
In the case in question, there is no SUSPEND/RESUME operation and no bit
map. You have no choice but to do a full mirror to bring Site A in synch
with Site B, which has the current data. The difference between full copy
and resync is elapsed time and network traffic.
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[email protected]
From: "Pommier, Rex R." <[email protected]>
To: [email protected],
Date: 06/06/2013 04:31 PM
Subject: Re: XRC Volume Resync on a Return Home
Sent by: IBM Mainframe Discussion List <[email protected]>
Ed brings up an interesting question. So with your response, you're
saying that with PPRC, you cannot 'reverse' the mirror. Breaking and
re-establishing the mirror pairs will require a full data re-push back to
the now secondary site.
Rex
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On
Behalf Of Mike Schwab
Sent: Thursday, June 06, 2013 5:10 PM
To: [email protected]
Subject: Re: XRC Volume Resync on a Return Home
With PPRC, you would break the pairs and re-establish in the opposite
direction.
When are all replicated and almost up to date, shut down the primary,
wait for updates to propate, and start at the secondary.
XRC may be a bit different.
On Thu, Jun 6, 2013 at 4:26 PM, VanBebber, Edmond@CIO
<[email protected]> wrote:
Thanks for the reply. I don't think that is the case when you say 'you
cannot just return operations back to the original application region'.
Banks do this all the time. They run production in site A for a few
months then switch and run in site B for a few months. I'm not really
asking if this can be done, I'm asking if you reverse replication with
XRC, can you do an incremental resync without GDPS and configured for a
region switch.
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On
Behalf Of Skip Robinson
Sent: Thursday, June 06, 2013 2:09 PM
To: [email protected]
Subject: Re: XRC Volume Resync on a Return Home
If you are truly 'running production in a recovery site', then you
cannot
just 'return operations back to the original application region'. I hate
to sound pedantic, but running production anywhere other than its home
location. means that the latest live, current production data now lives
at
the recovery site. 'Home data' is now obsolete. You would have to
restore
that data from the recovery site at home, overlaying the old data.
If that's not what you mean, please clarify.
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[email protected]
From: Ed VanBebber <[email protected]>
To: [email protected],
Date: 06/06/2013 11:34 AM
Subject: XRC Volume Resync on a Return Home
Sent by: IBM Mainframe Discussion List <[email protected]>
After running production in a recovery site for some time, if you want
to
return operations back to the original application region, does XRC do a
full volume resync or an incremental resync?
I've read that XRC can do an incremental resync when returning home if
you
are configured with region switch and running GDPS, which we are not.
Does
anyone know if this is a proprietary thing?
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
...
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
