The nature of our environment is such that in the unlikely event of a
data-center-wide disaster we are not legally required to have
near-continuous availability and zero transaction loss, and for the most
part our corporate end users could re-enter critical data from primary
documents and accept that some (non-mainframe) server platforms and
applications might not be fully functional for up to 48hrs. Under those
conditions, being able to recover everything on the mainframe to a daily
point-in-time state is adequate.
After studying DR requirements for several years, we finally came to the
conclusion that to support DR in our continually changing application
environment the only way to reliably co-ordinate with the day-to-day
status of all the application groups was to avoid the need for such
coordination in the first place! We invested in IBM FlashCopy and
Magstar drives and in what is now CA-Vtape. All application tapes are
on duplexed virtual tapes with a vault copy. All HSM ML2 and Backup
tapes are duplexed with vault copies. Nightly we quiesce batch, and
quiesce DB2 for the few seconds it takes to establish consistent
FlashCopy replicas of all production DASD volumes containing permanent
datasets. The physical volume backups are made over the next several
hours, and this is all coordinated with the tape library run to insure
that all duplex HSM and VTape physical tapes relevant to the system
status at the daily point-in-time backups make it to the vault with the
daily DR dumps. This gives us assurance that we have off site
everything that would have been accessible to all applications as of
that point in time and can recover to that point. All application areas
will have some interesting and unique problems dealing with catch-up and
transaction re-entry from that point, but at least they will have all
the relevant DASD and tape files.
Scott T. Harder wrote:
Joes (and Radoslaw),
You both have moved me more towards the center, certainly, of this
issue. Excellent points. I just was brought up in a centralized
environment, where CONTROL and MANAGED storage were the words of the
day. How do you coordinate recovery well when there are multiple
groups, both in and outside the data center, responsible for
recovering everything? Obviously, it can be done, but much harder
IMO.
Products such as ABARS (ok... I know) and other 3rd party DR backup
products can group application data set backups together - on a point
in time - and allow for proper recovery. That, of course, takes money
though and I can see where your model would make sense and work.
All the best,
Scott T. Harder
On 5/12/09, Joel C Ewing <[email protected]> wrote:
Obviously some shops must be radically different. In a full SMS shop,
applications programmers of course have no business doing volume-level
or volume-specific operations, and to prevent override of RACF access
restrictions ADRDSSU ADMIN authority must be tightly restricted to those
authorized to perform DASDAdmin functions; but for us to deny
applications access to DFDSS for dataset level backup/restore functions
on their own application datasets would be counterproductive.
We find that SMS configuration and conventions can reasonably be used to
handle a few backups, but are completely inadequate for many others
where the only kinds of backups that make sense are driven by
application-level events, with sets of related datasets that must be
handled as a consistent group, and/or with archival retention
requirements that don't fit within the rather simplistic SMS management
capabilities.
As a SysProg it is part of my responsibility to see that we can recover
the data center as a whole to a point-in-time in the event of a data
center failure. But, I do not have the time, the inclination, or the
responsibility to determine what additional backups many different
individual application areas may need in order to recover from
mini-disasters caused by application program failures, to reprocess old
data because of changed end-user requirements, or to meet data archival
requirements imposed by management or law specific to that application area.
Given that there are of necessity backups that must be designed by and
maintained by non-SysProg, applications people who are the ones in the
best position to understand their archival requirements, to deny them
ADRDSSU, effectively limiting them to sequential file backups and
awkward and inefficient file stacking on tape backups, makes little sense.
JC Ewing
...
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
