We held a very informative webinar recently on DASD backup and recovery for z/OS environments. One of the questions that came up was “why do I need your backup and recovery solution when I already mirror to another site?” This question is certainly not uncommon. Many of our account executives say that they run into this question on a regular basis.
On the surface, this viewpoint may not seem unreasonable. If I’m routinely mirroring my data to another system and/or another site, I already have a full backup copy of my data that I can restore anytime–so what’s the problem?
But there is a problem–or at least a real potential for one–and that problem comes to light when it’s time to restore.
The presenter for our webinar was Mark Jula, a technical sales consultant with a good deal of experience helping customers address backup and recovery. Mark had two responses to that question:
- “More than half of my customers already mirror, but want a 3rd copy on portable media that they can take anywhere. So if they plan to restore to a data center that’s already full, they have the flexibility to go to another data center. Tape cartridges are certainly portable and virtual tape can also be portable with VTS copy/export”
- “When you mirror, corrupted data gets mirrored also. You need that 3rd copy where you can restore from a backup created before the corruption has occurred.”
The above responses state two very important reasons to not rely on mirroring alone. But since this question comes up so often, Mark and one of his colleagues, DeWitt Knapp, decided to discuss this issue further. DeWitt is particularly passionate about this topic and had some great real life examples to share:
- “In 2005, a company had a main site in New Orleans and a mirror site in Mobile, Alabama. Both sites were hit by Hurricane Katrina. The fact that both sites were lost is an indictment on best practices for mirroring, which holds to the standard that mirrored sites should be east of the primary site.This east-west practice originated in California where a mirrored site was always placed east of the San Andreas Fault. The moral of this story: if the best practices of mirroring east of a primary site is short-sighted, so is depending exclusively on mirroring.”
- “In February 2011 a Google technician was doing some maintenance on Gmail. He accidentally deleted in excess of 100,000 accounts. Because Google is heavily dependent on mirroring, the error was propagated to all of their mirrored sites. These email accounts were unrecoverable. I recall two points from article written by Techspot:
- Google said they were sorry for the inconvenience it caused their customers, but the impact was small affecting less than one percent of their mail accounts.
- Secondly, the journalist who reported the incident blamed Google for being unsympathetic toward those who actually lost their data. Google had nowhere near the concern as compared to those who lost their data.
- The moral of this story: if mirroring fails to give complete protection of data, the response will be, well, mirroring did everything it could.”
- “Mirroring is great for seamlessly continuing business operations; however, it never provides historical recreation of data. What do you do if you need to reach back into time and recreate some data? It is just not there unless provided by the application. The moral of this story: mirroring implicitly puts the responsibility of providing historical data backup in the hands of the application programmer; a person, who for various reasons, may do an imperfect job of building historical safeguards into their applications.”
- “Mirroring is expensive. It may be more cost effective for communications (fiber optics, special hardware, traffic, et al) to limit mirroring of key storage groups. Alternatively, customers could prioritize and mirror storage groups containing their most critical applications, while backing up storage groups for less critical applications (or less time critical). In this scenario identifying disk volumes and corresponding storage groups is key. And as Mark Jula mentioned in the Webinar, one of the features of Rocket DASD Backup Supervisor is the automatic discovery of the disk volumes within each storage group and the ability to specify one or more storage groups for backup.”
So to summarize, mirroring alone is not a comprehensive data protection strategy. Mirroring without a supplemental backup and recovery strategy can lead to multiple issues when it comes to recovery. This is particularly pertinent to mainframe environments, which hold the most critical data for the largest banks, insurance, and government institutions.
A viable supplemental backup and recovery strategy must:
- Automate point-in-time replication products such as FlashCopy, SnapShot, and TimeFinder
- Create multiple historical backup versions allowing you to restore from any point in time pertinent to your business and free from data corruption
- Retain a portable backup copy that can be used anywhere
- Provide recovery granularity by allowing you to restore from one or more individual datasets or full volume backups.
If you’d like to see how Rocket DASD Backup Supervisor for z/OS can address these needs or listen to the 30 minute recorded webinar recording please visit the web page.
“What makes something a backup (versus just a copy)…….is whether or not it has management, reporting, and cataloging built around it so that it is useful when it needs to be.” – Industry expert W. Curtis Preston (otherwise known as “Mr. Backup”)
Latest posts by Sal Capizzi (see all)
- “Mainframe for All” highlighted at SHARE Atlanta 2016 - August 10, 2016
- Join the Rocket team at the SHARE conference February 28 – March 4 in San Antonio - February 17, 2016
- What’s New in Rocket Mainstar Database Backup and Recovery for DB2 v3.1 - October 14, 2015