Data Consistency - Part 4
The Backup Problem
"Fuzzy Backups" in greater detail
Previous
1
2
3
4
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).
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).
Previous
1
2
3
4
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
