Data Consistency - Part 2

Data Loss vs. Data Consistency

Previous 1 2 3 4 Next Describes backup and Disaster Recovery considerations for data integrity by Mike Smith, Recovery Specialties

How does one reconcile the possibility of lost data versus the integrity and consistency of the data? Often times, traditional backups were created while files were being updated. Eventually, backups created in this fashion were referred to as “fuzzy backups” as neither the consistency nor the integrity of the data could be assured.

One might think it is better to capture as many updates as possible, even if the end result is not consistent. Let us consider this point within the confines of a "typical" large systems data center. For the sake of discussion, let us assume that there are many applications sharing data on hundreds of logical volumes in many thousands of data sets. What happens to the integrity of the data if some updates are applied and others are not? Should this occur, the data is in an artificial state, one that is neither time, transaction nor application consistent. When the applications are restarted, it is likely that some data will be duplicated, while other data will still be missing. The difficulty here is in identifying which updates were successful, which updates caused erroneous results and which updates are missing.

In most cases it is preferable to have time consistent data, even if a few partial transactions are lost or rolled back in the process.

Data loss can be defined as data that is lost and cannot be recovered by another means. Often, individual transactions or files can be restored or recreated, which is inconvenient, but does not represent a true loss of data. Even in cases where some transactional data cannot be recreated or recovered by the data center support teams, it can sometimes be re-entered by the end user if necessary.

From the end-user perspective, it is much easier to understand that "All transactions entered after 3:15pm are gone" versus "Some data entered after 3:15pm may be missing or incorrect."

If you are considering an asynchronous Business Continuity and Disaster Recovery solution, it is important to understand that some updates may be lost in flight. However, the greater consideration is that the asynchronous solution you select provides you time consistent data for all of your interrelated applications. In this way, recovery is similar to the process necessary to achieve Transaction and Application Consistency following an outage at the primary site.

Data loss does not imply a loss of data integrity. However, given a choice, most organizations will protect data consistency—for example, ensuring that bank deposits and withdrawals occur in the proper sequence so that account balances reflect a consistent picture any given point in time. This is preferable to processing transactions out of sequence, or, to use our banking example again, to record the withdrawal and not the preceding deposit.

Previous 1 2 3 4 Next This is the Next navagation arrow

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

This document was printed from http://recoveryspecialties.com/