Data Consistency - Part 3

The Backup Problem - An Overview

"Fuzzy Backups"

Mike Smith, Recovery SpecialtiesPrevious  1 2 3 4  Next Mike Smith, Recovery Specialties

For a set of backup data to be of any value it needs to be consistent in some fashion; either Time, Transaction or Application consistency is required. For an individual data set, one with no dependencies on any other data, this can be accomplished by creating a simple Point in Time (PiT) copy of the data and ensuring that the data is not updated during the backup process.

At first glance, this appears to be a relatively simple thing to accomplish -- at least for an individual data set. However, if this data set is being updated by a critical on-line application, there may never be an opportunity to create a consistent backup-copy without temporarily halting the critical application. With today's dependence on 24x7 processing, the opportunities for even temporarily interrupting critical applications to create a "backup window"are seldom available.

As this problem became more prevalent, there were various methods used to attempt to address the situation. One of these methods was to create a “fuzzy” backup of the data, that is, to create the backup copy while updates were allowed to continue. Various utilities were used to perform this “backup while open” (BWO), but they all shared the attribute that the backup copy of the data may or may not be useable: If no additional actions were taken to validate and ensure the consistency of the data, any use of this backup data was predicated on the hope that “some data is better than nothing” and generally produced unpredictable and/or un-repeatable results.

In fact, there are three different possible outcomes, should this fuzzy backup be restored:

  1. The data is accidentally consistent and useable. This is a happy circumstance that may or may not be repeatable.
  2. The data is not consistent and not useable. A subsequent attempt to use the data detects the errors and ABENDs (ABnormally ENDs) subsequent processing.
  3. The data is NOT consistent, but does not cause an ABEND and happens to be useable to the application. It is used by subsequent processing and any data errors go undetected and uncorrected. This is the worst possible outcome.

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 http://recoveryspecialties.com/dc03.html directly to view the animation.

Example

Here is a simple example of how backing-up a data set that is being updated can produce unpredictable results.

There is an empty disk volume on the right.

When ready, position the mouse cursor over the image on the right and the automation will begin. First, data will begin to be allocated on the disk. In this case, the data is written to the volume in a non-sequential fashion, either randomly or key sequenced. When the record is first written, it is shown in bright Red. As the record ages, the color gradually changes to yellow indicating the "age" of the record.

After approximately 10 seconds a sequential backup of the data set begins. This backup process is depicted by blue lines indicating the progress of the backup process. In this illustration, the backup process is shown copying records at twice the speed that the records are being updated. Because the backup process can copy the data at twice the speed it is written, one might expect that there is a reasonably good chance of producing a viable backup. Sadly, this is not the case.

In this brief example, you see that the records are updated in an almost chaotic fashion. This type of I/O pattern is not at all unusual and is used to indicate either random or keyed writes by the application.

On the other hand, the backup process ran sequentially through the file beginning at the first record and ending with the last. However, during the period that the backup process was running, the file was still being updated.

Disaster Recovery, The Backup Problem and fuzzy backups, by Mike Smith, Storage and Recovery ConsultantPrevious  1 2 3 4  Next  An introduction to Fuzzy Backups 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 http://recoveryspecialties.com/


 
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
recoveryspecialties.com
Recovery Specialties logo, XRC, PPRC and data mirroring protect your enterprise
Data Replication over distance ensures Business Continuity no matter what happens