IBM Systems Magazine, Mainframe - January/February 2018 - SE19
ARTICLE: HA/DR BACKUP
Business Continuity Depends
on Backup and Recovery Plans
etting a business up and running after an unplanned outage
requires solid planning and strategy. Organizations can
develop a standardized approach to handling outages and
ensuring that backups are performed optimally.
Any enterprise creating a backup and recovery plan must
examine five main points, says Harry Batten, executive IT architect,
IBM. (See "Five Points to Consider When Preparing for Backup
and Recovery," bit.ly/2xNanwS.) They are:
The importance of the data
How often it changes
The data's lifecycle
If it's required for system recovery
When it should be backed up
Clients should look at the data from a failure perspective, Batten
says. If it becomes lost or corrupted, the client must determine
how to get it back online and the recovery point objective.
With so much data flowing, companies often tag which data
must be backed up regularly. Any data used for compliance or
recovery reasons will be backed up as a matter of course. With
IBM Z* environments, "most of the critical data is already vaulted
via a disaster recovery (DR) plan," Batten notes. "The backups
we are talking about here are for easy recovery of day-to-day
If an organization isn't certain whether specific data must be
backed up, the data can be put in a management class where it
will be migrated and then deleted after a set number of non-usage
days, he suggests.
Consider Data Lifecycles
In crafting any backup plan, clients must assess whether data
is static or dynamic. Dynamic data, which changes regularly,
benefits from incremental backups, whereas static data might
be backed up as a generation data group. Further, clients must
pick a backup time that will result in the least disruption.
Development and test environments
must also be evaluated. Developers
don't always clean out test data once
testing is complete, causing unnecessary data to remain in
Once the type of data and backup is determined, clients
should consider employing automated backup methods to
ensure backups are being made and enable administrators to
generate reports that list when backups were made and data
was accessed last.
At least once a year, IT should determine when backups are no
longer current or usable. This may be tedious, but it's necessary,
To ensure that all data is backed up and available for DR at a
remote site, many IBM Z clients use asynchronous or synchronous
data replication methods. To perform an effective recovery
following a disaster, clients must know what data is necessary
as well as where it is stored.
IBM GDPS* is used to ensure data consistency for Z as well as
automating the entire recovery process. Remote copy solutions,
such as z/OS* Global Mirror and Metro Mirror, are used by GPDS.
Tivoli* System Automation for z/OS provides automation for GPDS.
IT should reassess backup plans anytime a new technology is
added or a new compliance requirement is put into effect. Even if
nothing has changed, Batten suggests reviewing DR and backup
Any technical support solution must include platform and software
support in addition to cross-vendor multivendor support, say
Robert Laraman, executive, U.S. Technology Software Support
Services at IBM, and Seamus Keane, business executive,
Technology Support Services. (See "IBM Technology Support
Services Offers Protection for Business Resiliency and Continuity,"
Technology Support Services gives mainframe clients on-site
and remote access to IBM technical specialists to help ensure
resiliency and maintain business continuity.
By standardizing DR procedures, organizations will be well
prepared to handle any outage and
return the system to operation as quickly
ibmsystemsmag.com/buyersguide 2018 // 19