Data Consistency - Part 4

The Backup Problem

"Fuzzy Backups" in greater detail

Animation showing how backups can end successfully and create unuseable backups by Mike Smith, Disaster Recovery and Storage Consultant, Recovery SpecialtiesPrevious  1 2 3 4 Storage, Disaster Recovery and Business Continuity consultant - Mike Smith, Recovery Specialties

Animated display depicting randon write I/O's and a concurrent sequential backup of the data.  This backup creates a 'fuzzy' copy of the data.
Printing Note: This is an animated gif. Only a single frame is printed here. Please visit directly to view the animation.

In order to understand just one of the several ways in which this type of backup scenario can fail, it is necessary to study the process in greater detail: The figure to the left is similar to the previous animation, however the write I/Os have been sequentially numbered. This will facilitate an understanding of exactly which records are being over-written and what records are being backed-up.

Just prior to the backup beginning, the file contains 20 records that are sequentially numbered from 120 through 139. Immediately following the backup (and before the next write I/O) the file still contains 20 records, but the record numbers now contained in the file are: 127-133, 136-138, and 140-149. (Note: As in the previous animation, the file depicted here is accessed either randomly or via a record key and not sequentially).

Drag the mouse cursor to the image on the left to run the automation.

One of the first things you might notice when looking at the records contained on the backup is that they are different from the data records that were present on the file both before the backup started and immediately after the backup ended. In fact, the records contained within the backup is a completely artificial construct and does not accurately describe the contents of the file at any Point in Time.

This is not a consistent backup of the data. It is neither data-consistent within itself nor is it time-consistent from any point in time. It is a completely artificial representation of a file that never existed!

It is true that different records would have been backed up if the write I/O pattern had been different, or if the backup process was either faster or slower. The point here is that unless the backup could have been processed instantaneously (or at least in the time between two of the file write I/Os), the backup copy does not represent consistent data within the file.

In order to address this failing, various methods were developed including transaction logging, transaction backout and file reload with applied journaled transactions, just to name a few. These methods are all share the attributes of requiring extra effort (before the backup) and additional time - possibly even manual intervention - before the data can be used.

More importantly, the corrective process requires an in-depth understanding of both the application and data. These requirements dictate that a unique recovery scenario be designed for nearly each and every data set.

The integrity problem is daunting enough when viewed in the context of just these 20 records, but what about when there are interdependencies between thousands of data sets residing on hundreds (or even thousands) of volumes?

In this greater context, simple data consistency within individual data sets is no longer sufficient. What is required is time consistency across all of the interdependent data. As it is impossible to achieve this with the traditional backup methodologies, newer technologies are required to support time consistent data.

Luckily, there are solutions available today. For a single-site solution, FlashCopy with Consistency Groups can be used to create a consistent Point-in-Time copy that can then be backed-up by traditional means.

For a multi-site recovery environment, the various options include Metro Mirror for ESS(PPRC), Global Copy for ESS (PPRC-XD), as well as the two Global Mirror options: Global Mirror for ESS (Asynchronous PPRC) and Global Mirror for z/Series (XRC).  

Detailed description of one of many ways traditional backups can be unusable by Mike Smith, Disaster Recovery and Storage Consultant, Recovery SpecialtiesPrevious   1 2 3 4 Traditional 'fuzzy backup' problem explained.  Original animation by Mike Smith, Storage Solutions Architect, Recovery Specialties

Recovery Specialties, LLC:  Business Continuity and Disaster Recovery Consulting Services
Recovery Specialties, LLC
Enterprise Storage Solutions,
Business Continuity and Disaster Recovery consulting
for z/OS environments

This document was printed from

Sitemap | Privacy Statement | Personal Information | Ethics Policy | Conflict of Interest Policy
Recovery Specialties, LLC. All rights reserved. 2007
Recovery Specialties Storage and Business Continuity consulting for z/Series environments
Recovery Specialties, LLC
Recovery Specialties logo, XRC, PPRC and data mirroring protect your enterprise
Data Replication over distance ensures Business Continuity no matter what happens