I believe he's not copying to DR site, but copying to tapes that might
be used for DR recovery. Hopefully he was just describing the process
by which system backups are made on some regular schedule (daily?) and
not intending to imply they only follow that process before a DR test.
Presumably in a real disaster they would be recovering to the most
recent point-in-time for which they have complete backup tapes, with
potential loss of any updates that occurred after that point (which may
be sufficient for some businesses). If that is the correct
interpretation, then how the system goes down in a real or simulated
disaster is irrelevant, only the time of the event which determines
which backups are used for recovery.
For over a decade we successfully did daily point-in-time full-system,
full- volume backups in a heavy CICS DB2 shop. We didn't even bother
shutting down CICS regions, just used flash copy to take all logical
dumps to DASD in a few seconds while DB2 was inhibited from updates so
no in-flight transactions could do COMMITs. On a DR system that was
restored from the resulting tape copies of the DASD backups, standard
DB2 and CICS recovery on restart would rollback partial uncommitted
updates to keep DB2 tables consistent.
Now if you are in a environment that requires continual ability to do DR
recovery with no loss of any completely processed transactions, things
become much more complex and expensive. I think that would require a
minimum of two mirrored DASD copies (maybe more): one mirrored copy of
production DASD for staging and a 2nd mirrored copy of that at the DR
hot site, just so you can test various modes of disruption of updates to
the DR DASD without disrupting production and prove you can still
recover at the DR hot site.
Joel C. Ewing
On 11/09/2015 11:00 AM, J O Skip Robinson wrote:
> This may be OT for your actual question, but an alarm went off in my head
> while reading this post. If you carefully shut down your systems before
> copying to your DR site, you may well find yourself in a world of hurt in the
> event of a real disaster. If systems die a sudden death without warning, you
> will have no opportunity to shut down cleanly or do any other kind of
> processing on the production side.
>
> To test DR properly, you need to stop processing like yanking a plug. How you
> accomplish that action depends on your configuration and mirroring technology
> (if any). Maybe you depend on tornado alerts where you live. We have
> earthquakes. No time for any preparation whatsoever.
>
> .
> .
> .
> J.O.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]
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]] On
> Behalf Of Tony Thigpen
> Sent: Saturday, November 07, 2015 10:01 AM
> To: [email protected]
> Subject: (External):Question on IMS and dr volume backups
>
> We are testing DR for an OS/390 2.10 system with IMS.
> Before the backups, CICSs are shut down and /DBR DB ALL is issued. We then
> copy all disk volumes to tape to send to the DR site.
>
> When we restore the system to the DR box, sometimes we have to issue the
> /ERESTART OVERRIDE command to get IMS happy. Sometimes IMS is happy without
> the /ERESTART.
>
> My main systems programmer says 'We are doing it the way we always have.' I
> am wondering if there is something else we should be doing.
>
> [We can't flash as OS/390 2.10 does not talk correctly with flashcopy on the
> DS8300 we are using. A flash command turns into a standard disk copy.]
>
> --
> Tony Thigpen
>
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
--
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
