Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
  • G06F11/14—Error detection or correction of the data by redundancy in operations
  • G06F11/1446—Point-in-time backing up or restoration of persistent data
  • G06F11/1448—Management of the data involved in backup or backup restore
  • G06F11/1451—Management of the data involved in backup or backup restore by selection of backup contents
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
  • G06F2201/82—Solving problems relating to consistency
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
  • G06F2201/84—Using snapshots, i.e. a logical point-in-time copy of the data
• • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
  • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y10S707/00—Data processing: database and file management or data structures
  • Y10S707/99951—File or database maintenance
  • Y10S707/99952—Coherency, e.g. same view to multiple users
  • Y10S707/99953—Recoverability
• • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
  • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y10S707/00—Data processing: database and file management or data structures
  • Y10S707/99951—File or database maintenance
  • Y10S707/99952—Coherency, e.g. same view to multiple users
  • Y10S707/99955—Archiving or backup

Definitions

• the present invention relates to the protection of computer data, and more particularly to a system and method for taking a snapshot copy of only certain sectors on one or more mass storage systems.
• Background and Related Art Computers have become an integral part of most business operations. In some instances, computers have become so vital that when they cease to function, business operations cannot be conducted.
• Banks, insurance companies, brokerage firms, financial service providers, and a variety of other businesses rely on computer networks to store, manipulate, and display information that is constantly subject to change. The success or failure of a transaction may turn on the availability of information which is both accurate and current.
• the credibility of the service provider, or its very existence, may depend on the reliability of the information maintained on a computer network. Businesses worldwide recognize the commercial value of their data and are seeking reliable, cost- effective ways to protect the information stored on their computer networks by reliably backing up data.
• the software layer intercepting all file system commands is an adequate solution when only a few files are tracked.
• the solution proves unworkable as the number of tracked files increases.
• the problem is that the software layer essentially performs the work of a file system.
• each file operation performed by operating system is also performed, in one form or another, by the software layer.
• the software layer becomes overloaded and degrades performance such that the system is unusable.
• the software interception layer also overlooks the relationships that may exist between files. As described above, it is not enough that the data stored within a file is consistent. The data stored in one file is likely related to data stored in one or more other files.
• the prior art's software layer is only able to insure that a file is accessible during a backup process. It makes no provision for insuring a logically consistent set of data across all files comprising a backup operation. Therefore, backups made with a software layer of this type may be less beneficial due to inconsistencies in the stored data. It would, therefore, represent an advancement in the art to have an efficient system for backing up only data that is desired to be backed up while maintaining relationships between files.
• the backup system and method of the present invention reduces the amount of data needed to make a backup by backing up only those data blocks of the primary mass storage device that changed and have been designated as desirable files for backup.
• the system and method of the present invention provides for a more efficient use of the storage area since the amount of data for backup is reduced to the absolute minimum through backing up only that which is desirable to back up.
• the system and method of the present invention emphasizes accuracy of the backup by ensuring that the primary storage device is in a logically consistent state when a backup is made.
• backup frequency can be increased.
• the method of the present invention begins with the assumption that the original data and a snapshot copy of that data contain identical data, at least with regard to the data blocks designated for backup. This may be accomplished, for example, by making a complete copy of the original data to the snapshot copy using either traditional backup techniques or traditional disk mirroring techniques.
• the present invention creates a map or another data structure for listing all data blocks that have been altered, tracks the changes made to the data blocks on the primary mass storage device, identifies the altered data blocks, and designates the data blocks desired for backup from those data blocks that that are not desired for backup.
• the tracking is done by identifying those storage locations in the original data that have new data written in them from the time that the snapshot copy was in sync with the original data.
• the identification of those changes that have been made to the original data indicates the changes that need to be made to the snapshot copy in order to bring the backup storage device current with the primary mass storage device.
• the changes that need to be made to the backup storage device are registered on a listing or table.
• the system allows for the identification and separation of the listing or table into information that is desirable for backup and information that is undesirable for backup. This separation can be accomplished by either flagging the desirable information or by flagging the undesirable information. Identification and separation of the information in the table reduces the amount of information for backup to only that which is desirable, thus the speed of the backup process is increased and the storage space is more efficiently used by reducing the amount of information to be backed up. Furthermore, the identification and separation prevents undesirable information from being included in the backup.
• the present invention takes a data block approach to the backing up of a mass storage system, and because only those data block that are designated to be protected are backed up, the present invention minimizes the amount of data that needs to be transferred in making a backup to the absolutely minimum possible. For example, if a large database has five records that change, prior art systems would copy the entire large database. The present invention, however, copies only the five records that have changed. Because the amount of data is minimized, the present invention is particularly well suited to backing up data to a backup system located at a remote site. The present invention can utilize low bandwidth communication links to transfer backup data to a remote backup site. As an example, in many cases conventional dial-up telephone lines with a 56.6k baud modem are entirely adequate.
• Figure 3 is a system level block diagram of one embodiment of the present invention.
• FIG 5 illustrates the processing details of one embodiment of the primary backup processing block of Figure 3
• Figure 6 illustrates the processing details of one embodiment of the backup read processing block of Figure 3;
• Figures 8A and 8B are diagrams illustrating an example of a method according to one embodiment of the present invention.
• the present invention extends to both systems and methods for taking a snapshot of only those data sectors that are desirable to be backed up from a mass storage means, rather than taking a snapshot of all the data in that mass storage means. Since a snapshot is taken of only the desirable data, this invention optimizes both time and storage space in providing a back up copy of data located on a mass storage means.
• Embodiments within the scope of the present invention also include computer- readable media having encoded therein computer-executable instructions or data structures.
• Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer.
• Such computer-readable media can comprise RAM, ROM, EEPROM, CD- ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, magneto-optical storage devices, or any other medium which can be used to store the desired computer-executable instructions and data structures and which can be accessed by a general purpose or special purpose computer. Combinations of the above should also be included within the scope of computer-readable media.
• Computer-executable instructions comprise, for example, executable instructions and data which cause a general purpose computer or special purpose computer to perform a certain function or a group of functions.
• data block is used to describe a block of data that is written to or read from a mass storage means.
• data block is intended to be broadly construed and should include any size or format of data.
• the data stored in an individual sector on a disk is properly referred to as a data block.
• the amount of data stored in a group or cluster of sectors may also properly be referred to as a data block.
• the mass storage means is a RAM or other word or byte addressable storage device, the term data block may be applied to a byte, a word, or multiple word unit of data.
• the term “desired data block” is used to describe a data block that is designated to be backed up
• the term “undesired data block” is used to describe a data block that is not designated to be backed up.
• the system shown generally as 10, comprises a computer system 12 which may be any type of networked or stand alone computer system.
• computer system 12 may be a network server computer connected to a computer network such as computer network 18.
• the computer system 12 may also be a stand alone system.
• Computer system 12 has attached thereto mass storage means for storing a plurality of data blocks in a plurality of storage locations. Each of the storage locations is specified by a unique address or other mechanism.
• Mass storage means can be any storage mechanism that stores data blocks.
• such mass storage means may comprise one or more magnetic or magneto-optical disk drives. In Figure 1 , for example, such mass storage means is illustrated by mass storage device 20.
• the mass storage device 20 includes original data 14 including data blocks that are desirable to be backed up as well as data blocks that are not desirable to be backed up. Examples of data blocks that may not be desired to be backed up are swap files, free sector tables, print buffers, temp files having the ".tmp" extension, and other files not desired to be backed up.
• the mass storage device 20 may also include a snapshot copy of the data blocks in the original data that are desirable to be backed up as those data blocks existed at a particular point in time. "Snapshot" copy thus refers to the fact that the copy has captured the desirable data blocks as they existed at an instant in time.
• the snapshot copy 16 is shown as being in a data storage location included within the same mass storage device as the original data, the snapshot copy 16 may instead be located in a data storage location of a different storage device.
• the computer system 12 writes the snapshot data to the different storage device over a communication medium such as the computer network 18.
• the snapshot copy 16 is stored on the same mass storage device 20 as the original data 14.
• Embodiments within the scope of this invention use a snapshot copy of all or part of the mass storage device corresponding to desired data blocks during the backup process.
• Embodiments within the scope of this invention therefore comprise preservation memory means for temporarily storing data blocks of said mass storage means so as to create a static snapshot of the mass storage means at a particular point in time for the desired data blocks.
• preservation memory means may comprise any type of writeable storage device such as RAM, EEPROM, magnetic disk storage, and the like.
• Such preservation memory means may also comprise a portion of mass storage device 20. In Figure 1 , such preservation memory means is illustrated, for example, by snapshot storage device 22.
• Preservation memory means is discussed in greater detail below.
• computer system 12 may be any type of general purpose or special purpose computer, computer system 12 may also comprise any other hardware that makes up a general purpose or special purpose computer.
• computer system 12 may also comprise processor means for executing programmable code means.
• the processor means may be a microprocessor or other CPU device.
• the processor means may also comprise various special purpose processors such as digital signal processors and the like.
• Computer system 12 may also comprise other traditional computer components such as display means for displaying output to a user, input means for inputting data to computer system 12, output means for outputting hard copy printouts, memory means such as RAM, ROM, EEPROM, and the like.
• FIG 2 an overview of the method used to backup original data such as original data 14 of Figure 1 , to a snapshot copy, such as snapshot copy 16 of Figure 1, is presented.
• the method illustrated in Figure 2 presumes that, as far as the desired data blocks are concerned, the original data 14 and the snapshot copy 16 are current.
• "current" means that the snapshot copy contain a current copy of all the desired data blocks of the original data 14.
• the snapshot copy 16 is assumed to have a current copy of the original data 14 at time TQ.
• the method summarized in Figure 2 maintains the snapshot copy 16 in a current state with respect to the original data 14.
• the method summarized in Figure 2 captures successive logically consistent states. This results in the snapshot copy 16 either moving from one logically consistent state to a subsequent logically consistent state or allows the snapshot copy 16 to capture successive logically consistent states. This creates a tremendous advantage over prior art systems which may leave the backup storage device in a logically inconsistent state. By ensuring that the backup device is in a logically consistent state, the present invention ensures that a useable snapshot copy is always available.
• the changes are preferably tracked by identifying data blocks of the mass storage device that have new data written in them starting at time TQ and which are desired data blocks. As explained in greater detail below, this may be done by keeping a map which identifies those data blocks that have new data written in them starting with time TQ and by keeping a map of desired data blocks
• the system identifies a logically consistent state of the primary mass storage device and takes a static snapshot of at least the desired data blocks that have been changed since time To- In Figure 2, the logically consistent state is identified as time T ⁇ and a snapshot is taken.
• a static snapshot is designed to preserve data as it is exists at a particular point in time so that the desired data blocks will be available after the particular point in time in their state as it existed at the snapshot time even though changes are made to the original data after the snapshot time.
• Many ways exist of creating such a static snapshot Any such method works with the present invention, however, some methods are preferred over others due to various advantages.
• the details of how a static snapshot is taken and a preferred method for creating a static snapshot is presented below. For this summary, however, it is important to understand that any method which creates a static snapshot can be used with the present invention. It is, however, preferred that the static snapshot be taken without terminating user read or write access to the mass storage device.
• the data Since the data is preserved by a snapshot at time Tj, the data is available for transfer to the backup storage device even though new data is written to the mass storage device after time Tj .
• the maps or other mechanisms that were used to track which storage locations had data written therein between time TQ and time T ⁇ and that were used to designate the data blocks that were desired to be backed up are used to identify the data that should be transferred to the backup storage device.
• only incremental changes to desired data blocks are sent and entire files are not transferred unless the entire file changes.
• undesired data blocks are not sent even if there are changes to those data blocks.
• data blocks that are desired for backup are designated during time period 33 using a map or another data structure in the manner described above in reference to time period 29.
• the same data blocks that have been previously designated to be backed up or, equivalently, not to be backed up can carry over into the new snapshot.
• the user is not required to repeatedly designate data blocks that are to be backed up.
• the factors that determine whether the previous designations carry over to new snapshots as described above include the frequency of the snapshots, the preferences of the user, and whether the file structure has changed since the previous snapshot.
• the present invention only backs up those few data blocks that have been actually changed due to the database modification. Furthermore, as will be explained in further detail below, the present invention allows the data blocks that have been changed to be designated as either desirable or undesirable for backup. Therefore, only the data blocks that have been changed, between a first instant in time and a second instant in time, and are desirable for backup are sent to the snapshot copy 16. Thus, memory, processing cycles and communication bandwidth are not wasted storing backup copies of data blocks that are not desired to be backed up.
• Embodiments within the scope of this invention therefore comprise means for preserving a static snapshot at a particular instant in time.
• the use of a static snapshot is preferred because it allows users to continue to access primary mass storage device 20 while the changes are being backed up. Since it takes a period of time to transfer the changes from the original data 14 to the snapshot copy 16, the data that is to be transferred must remain unchanged until it is transferred. If the snapshot copy 16 is not located within the mass storage device 20, one way to ensure that the data remains unchanged is to prevent access to primary mass storage device 20.
• snapshot processing block 50 the means for preserving a static snapshot is illustrated by snapshot processing block 50. As illustrated in Figure 3, it may make sense to incorporate the snapshot processing mechanism into the mass storage read/write processing block. Although the details of snapshot processing block 50 are presented below, one preferred embodiment preserves a static snapshot by copying a data block of the original data 14 that is to be overwritten from the original data 14 into snapshot storage 22 and then indicating in snapshot map 52 that the block has been preserved in snapshot storage 22. Once a copy has been placed into snapshot storage 22, then the copy of the data block in the original data 14 can be overwritten. As described above in conjunction with Figure 2, if a series of successive backups are to be made, it is necessary to track the changes made to the original data 14, during the time that a backup is being made.
• the present invention is designed to capture one or more logically consistent backup states at the snapshot copy 16 for desired data blocks.
• embodiments within the scope of this invention may comprise means for determining when a logically consistent state has been achieved.
• a logically consistent state is a state where no logical inconsistencies such as improperly terminated files exist on the mass storage system.
• a logically consistent state may be identified by a number of mechanisms. For example, a logically consistent state may be identified by watching the activity on the mass storage device. When no activity exists on a mass storage device, it may generally be presumed that all internal data buffers have been flushed and their data written to the mass storage system and the mass storage system is not in a state where data blocks are being updated.
• a preferred method of preserving a static snapshot utilizes a snapshot storage, such as snapshot storage 22 of Figure 3, to preserve data blocks of a mass storage device, such as mass storage device 20 of Figure 3, that are to be overwritten with new data.
• a snapshot storage such as snapshot storage 22 of Figure 3
• the data blocks that are to be preserved are first copied into the snapshot storage and a record indicating that the data block has been preserved is updated.
• Such a record can be stored, for example, in snapshot map 52 of Figure 3. New data may then be written to mass storage device 20 without losing the preserved data blocks.
• snapshot map 52 of Figure 3 identifies those data blocks that have changed since a static snapshot was preserved at a particular instant in time. Thus, snapshot map 52 can be used as a backup map when a new snapshot is taken.
• decision block 76 of Figure 4. This decision block tests whether a message received by mass storage read/write processing block 42 is a mass storage read or write request. By the time decision block 78 is reached, the only messages that are possible are either a mass storage read request or mass storage write request. This is because other types of requests are either handled or filtered out before decision block 78 is reached. Decision block 78 distinguishes between a mass storage read request and a mass storage write request. If a request is a mass storage read request, then the next step is to retrieve the requested data block from mass storage device 20 and return the data to the process making the request. This is illustrated in step 80. If, however, the request is a write request, then execution proceeds to decision block 82.
• Decision block 82 determines whether a snapshot is to be preserved.
• a snapshot is preserved by copying data blocks that are to be overwritten to a preservation memory such as snapshot storage 22 of Figure 3.
• the snapshot is in essence preserved incrementally.
• the snapshot storage is prepared to preserve data blocks as previously described in steps 72 and 74. Thereafter, no data is stored in the snapshot storage until an actual write request occurs that will overwrite data that should be preserved.
• it is important to determine if a snapshot has been taken or if write requests should occur to the mass storage system without worrying about preserving snapshot data.
• Decision block 82 tests whether the write request should occur without preserving snapshot data or whether snapshot data should be preserved for write requests. If the write requests should occur without preserving snapshot data, decision block 82 indicates that execution proceeds to step 88 where the data blocks are written to the mass storage device, such as mass storage device 20 of Figure 3. If, however, snapshot data should be preserved, then execution proceeds to decision block 84.
• a snapshot storage such as snapshot storage 22 of Figure 3.
• the new data block can be written to the mass storage system.
• the goal of a snapshot is to preserve the data as it exists on the mass storage system at a particular point in time.
• the snapshot need only preserve the data as it existed at the time of the snapshot.
• Decision block 84 tests whether the original data block stored on the mass storage system at the time that the snapshot was taken has previously been preserved in the snapshot storage.
• Decision block 85 determines whether the data block is marked to be protected. As illustrated in Figure 3 with protection map 53, a user may designate the data blocks as either desirable or undesirable for backup so that only the data blocks that are desirable for back up are actually backed up. Data blocks that are designated as desirable for backup have been and are referred to herein as desired data blocks, whereas data blocks that are not designated as desirable for backup have been and are referred to as undesired data blocks. This feature reduces the amount of time and storage space required for backup. Requests to designate desirable/undesirable data blocks for backup 43 are received by mass storage read/write processing 42.
• the data blocks on snapshot map 52 indicate the data blocks that are stored in snapshot storage 22 as a result of the most recent static snapshot taken.
• Mass storage read/write processing 42 indicates on the protection map 53 those data blocks that are desirable for backup.
• snapshot processing can indicate on protection map 53 those data blocks that are undesirable for backup, preventing their backup by marking them as always being current.
• snapshot map 52 and protection map 53 can be one map. In other words, the functions performed on protection map 53 can be performed on snapshot map 52. If the data block is not marked to be protected, or in other words are not desirable for backup, then execution proceeds from decision block 85 to step 88 skipping step 86. Alternatively, if the data block is marked to be protected, then execution proceeds to step 86, where the original data blocks are copied into the snapshot storage 22.
• step 85 can be omitted. Changed data blocks would be preserved independently of whether they were desirable data blocks or not. Then, when sending data blocks to the snapshot copy, backup read processing 56 can filter out any undesirable data blocks using protection map 53 so that only desirable data blocks are sent to the snapshot copy, as step 113 of Figure 6 illustrates.
• step 86 After the original data has been preserved by step 86, or a determination was made by decision block 84 that the original data had previously been preserved, or a determination was made by decision block 85 that the data block is not marked to be protected, then execution proceeds to step 88 where the write request is fulfilled by writing the data block included with the write request to the designated storage location on the mass storage device.
• Step 90 identifies the storage location as containing new data. As previously described, this may be accomplished by placing an entry in a snapshot map, such as snapshot map 52 of Figure 3. Step 90 represents but one example of the previously described means for identifying storage locations of a mass storage device that have new data written therein.
• a response may then be returned to the process making the write request. The sending of such a response is indicated in Figure 4 by step 92.
• Such responses are typically sent to the process that issues the write request not only to indicate the success or failure of the write operation but also to indicate completion of the write operation. Execution then proceeds back to the start where the next request is handled.
• step 100 identifies a logically consistent backup state. After a logically consistent state has been identified, then a snapshot of the logically consistent state is preserved so that the backup may proceed.
• the snapshot is preserved by step 102 which signals the snapshot processing, as for example snapshot processing block 50 incorporated into a mass storage read/write processing block 42 of Figure 3, to take the snapshot. In one embodiment, this results in snapshot request 68 being sent to mass storage read/write processing block 42.
• this request causes steps 70, 72, and 74 of Figure 4 to be executed, which prepares for the snapshot to be taken. Thereafter, original data for designed data blocks stored in the mass storage device 20 at the time the snapshot was taken is preserved by decision block 84, decision block 85 and step 86 of Figure 4.
• step 106 sends the assembled data 64 to the snapshot copy 16. This may be accomplished by sending the data to the mass storage read/write processing block 42 for writing into the snapshot copy.
• the data blocks that are sent to the snapshot copy 16 by step 104 are only those data blocks that have changed since the last backup and are desired to be backed up. Furthermore, the data blocks are transferred as they existed at the moment in time that the snapshot was taken. Thus, only those data blocks that are identified in a backup map, such as backup map 48 of Figure 3, as having changed and identified as protected in a protection map, such as protection map 53 of Figure 3 are transferred.
• the snapshot preserves those desired data blocks in the state that they were in when the snapshot was taken.
• Primary backup block 54 therefore needs to retrieve certain data blocks that were preserved by the snapshot.
• Primary backup processing block 54 may incorporate the functionality needed to retrieve the data blocks from the snapshot and/or mass storage system, or such functionality may be incorporated into a separate processing block. A separate processing block incorporating this functionality is illustrated in Figure 3 by backup read processing block 56.
• Figure 6 presents one embodiment of backup read processing block 56 designed to recover the data preserved by these snapshots.
• decision block 112 highlights the fact that backup read processing block 56 only handles read requests that are to retrieve the data as it existed at the moment in time when the snapshot was taken. This decision block may not be necessary if the structure and architecture of the processing guarantees that only such read requests are sent to backup read processing block 56 of Figure 3.
• decision block 1 13 highlights the fact the backup read processing block 56 only retrieves desired data blocks for eventual transfer to the backup system. The check for whether a data block is a desired data block may be accomplished by referring to protection map 53 of Figure 3.
• decision block 113 may be omitted.
• some embodiments of the present invention may preserve only data blocks that have been marked as protected. Where only protected data blocks are placed in snapshot storage, decision block 113 may be eliminated because an indication by decision block 1 14 that a data block has been stored in snapshot storage necessarily means that the data block was marked to be preserved.
• mass storage write request is processed in the following manner.
• step 70 the snapshot map is copied to the backup map.
• step 7A this means that map locations 140 are copied into map locations 142 of backup map 48.
• map locations 142 indicate that locations 3, 4, and 6 have had new data stored therein.
• step 72 clears the snapshot map and step 74 clears the snapshot storage as previously described. Execution in Figure 4 then returns to the start to await further processing.
• Mass storage read/write processing block 42 handles the write of the data blocks to be stored in locations 4 and 6 as previously described with the data blocks 144 stored in those locations after time T] (data block 4b and data block 6a) being stored in snapshot storage 22. New data blocks 4c and 6b then are written to mass storage device 20.
• the primary system that contains the original data crashes during a write update, it may leave the original data in a logically inconsistent state.
• the backup copy is tracking every change made to the original data, then when the primary system crashes, the backup copy may also be left in the same logically inconsistent state.
• This example highlights the problem of leaving a known logically consistent state before a second logically consistent state has been identified.
• the present invention avoids this problem by maintaining the prior logically consistent state until a new logically consistent state has been identified and then moves the snapshot copy from the previous logically consistent state to the next logically consistent state without transitioning through any logically inconsistent states between the two logically consistent states.
• Map locations 152 are then updated to indicate that the storage locations that have been changed since time Tj now include storage locations 4 and 6 in addition to storage locations 1 and 3. This is illustrated in Figure 7A by map locations 160 of snapshot storage 52.
• data blocks that are read are then transmitted to the snapshot copy via mass storage read/write processing block 42 as illustrated in steps 104 and 106 of Figure 5.
• data blocks 166 are then applied to storage locations 154 in order to arrive at storage locations 168, which are an identical copy of storage locations 158 of the original data ( Figure 7A) except for storage location 3 since it was identified as being undesirable for backup.
• a snapshot request 68 is sent to mass storage read/write processing block 42.
• this snapshot request is processed by decision block 66 which results in steps 70, 72, and 74 being executed.
• step 70 the snapshot map is copied to the backup map.
• map locations 140 are copied into map locations 142 of backup map 48.
• map locations 142 indicate that locations 3, 4, and 6 have had new data stored therein.
• step 72 clears the snapshot map and step 74 clears the snapshot storage as previously described. Execution in Figure 4 then returns to the start and await further processing.
• Step 88 of Figure 5 then states that the data blocks need to be identified as modified.
• map locations 152 of snapshot map 52 are modified to indicate that storage location 1 and storage location 3 have new data stored therein.
• a write request response is then returned as directed by step 92 of Figure 4.
• Steps 104 and 106 then indicate that the data blocks that were changed before the snapshot was taken should then be assembled and sent to the snapshot copy.
• the data blocks that should be transferred are indicated by the information contained in backup map 48 and protection map 53.
• snapshot map is cleared as indicated by map locations 164 of snapshot map 52.
• Snapshot storage 22 still shows data blocks stored therein. This is to illustrate that the data blocks may still physically reside in snapshot storage 22 as long as the index to snapshot storage 22 is cleared so that snapshot storage 22 appears to contain no data blocks.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Quality & Reliability (AREA)
• Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
• Techniques For Improving Reliability Of Storages (AREA)
• Retry When Errors Occur (AREA)

Priority Applications (4)

Applications Claiming Priority (2)

Publications (1)

Family

ID=25544232

Family Applications (1)

Country Status (7)

Cited By (8)

Families Citing this family (186)

Citations (5)

Family Cites Families (39)

• 2001
  • 2001-11-29 US US09/997,643 patent/US7296125B2/en not_active Expired - Lifetime
• 2002
  • 2002-11-15 WO PCT/US2002/037309 patent/WO2003048941A1/en not_active Ceased
  • 2002-11-15 AU AU2002350221A patent/AU2002350221A1/en not_active Abandoned
  • 2002-11-15 JP JP2003550066A patent/JP4181044B2/ja not_active Expired - Lifetime
  • 2002-11-15 EP EP02786751A patent/EP1449088A4/en not_active Withdrawn
  • 2002-11-15 CN CNB028237064A patent/CN1291320C/zh not_active Expired - Lifetime
  • 2002-11-15 KR KR1020047008199A patent/KR100560726B1/ko not_active Expired - Lifetime
• 2006
  • 2006-10-04 US US11/538,546 patent/US7398366B2/en not_active Expired - Lifetime

Patent Citations (5)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events