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:
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.
This document was printed from http://recoveryspecialties.com/