WO2007047346A2 - Technique for timeline compression in a data store - Google Patents

Technique for timeline compression in a data store Download PDF

Info

Publication number
WO2007047346A2
WO2007047346A2 PCT/US2006/039857 US2006039857W WO2007047346A2 WO 2007047346 A2 WO2007047346 A2 WO 2007047346A2 US 2006039857 W US2006039857 W US 2006039857W WO 2007047346 A2 WO2007047346 A2 WO 2007047346A2
Authority
WO
WIPO (PCT)
Prior art keywords
timeline
time interval
data
selected time
rollup
Prior art date
Application number
PCT/US2006/039857
Other languages
French (fr)
Other versions
WO2007047346A3 (en
Inventor
Ronald Peter Passerini
Robert Warren Perry
Christopher Angelo Rocca
Michael Daniel Anthony
Original Assignee
Symantec Operating Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Symantec Operating Corporation filed Critical Symantec Operating Corporation
Priority to EP06816785.7A priority Critical patent/EP1952236B1/en
Publication of WO2007047346A2 publication Critical patent/WO2007047346A2/en
Publication of WO2007047346A3 publication Critical patent/WO2007047346A3/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1415Saving, restoring, recovering or retrying at system level
    • G06F11/1435Saving, restoring, recovering or retrying at system level using file system or storage system metadata
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1446Point-in-time backing up or restoration of persistent data
    • G06F11/1448Management of the data involved in backup or backup restore
    • G06F11/1451Management of the data involved in backup or backup restore by selection of backup contents
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1446Point-in-time backing up or restoration of persistent data
    • G06F11/1458Management of the backup or restore process
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1446Point-in-time backing up or restoration of persistent data
    • G06F11/1458Management of the backup or restore process
    • G06F11/1461Backup scheduling policy
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/835Timestamp
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/84Using snapshots, i.e. a logical point-in-time copy of the data
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/102Programmed access in sequence to addressed parts of tracks of operating record carriers
    • G11B27/105Programmed access in sequence to addressed parts of tracks of operating record carriers of operating discs

Definitions

  • the present disclosure relates generally to data storage and, more particularly, to a technique for timeline compression in a data store.
  • Embodiments of such a technique provide a solution for continuous data protection (CDP) wherein write commands directed to a storage system are intercepted by a storage management system having a current store and a time store.
  • the current store may maintain or have access to a current (or mirror) copy of the storage system's digital content.
  • the time store may record information associated with each intercepted write command, such as new data in the write command's payload or old data to be overwritten in the current store in response to the write command.
  • COW copy-on-write
  • the time store may also record other information (i.e., metadata) associated with an intercepted write command and/or the corresponding COW operation, such as, for example, a timestamp, an original location in the current store where the old data are overwritten, and a destination location in the time store to which the COW data are copied.
  • Each COW operation typically backs up one or more blocks of COW data, thereby creating one set of COW data and corresponding metadata.
  • multiple sets of COW data and corresponding metadata may be accumulated as a collection of historical records of what have been written or overwritten in the current store or the storage system.
  • the content of the time store may be indexed based on the metadata to facilitate efficient access to the COW data.
  • the storage management system adds a new dimension, i.e., time, to the storage system. Assuming the storage management system has been operatively coupled to the storage system since a past time, the storage management system may quickly and accurately restore any addressable content in the storage system to any point in time between the past time and a present time. Ideally, it might be desirable to maintain such a data recovery capability for as long a timeline as possible. However, to accommodate an extended timeline, a significant amount of storage space is needed to store the COW data and corresponding metadata for every write command in that timeline.
  • a technique for timeline compression in a data store is disclosed.
  • the technique may be realized as a method for timeline compression in a storage system, wherein digital content of the storage system is backed up to enable restoration of the digital content to one or more points in a timeline.
  • the method may comprise selecting a time interval in the timeline.
  • the method may also comprise identifying one or more sets of backup data recorded for the selected time interval, wherein the identified one or more sets of backup data represent at least a portion of old data overwritten during the selected time interval.
  • the method may further comprise discarding other backup data recorded for the selected time interval, thereby reducing a granularity level of the timeline in the selected time interval.
  • the digital content of the storage system may be backed up through copy-on-write operations into a plurality of sets of copy-on-write data and corresponding metadata, and the step of identifying may further comprise identifying one or more sets of copy-on-write data and corresponding metadata recorded for the selected time interval.
  • a length of the time interval may be selected based at least in part on a desired granularity level of the timeline.
  • the step of identifying may further comprise: determining whether a storage unit in the storage system has been overwritten more than once during the selected time interval; if the storage unit has been overwritten once during the selected time interval causing a sole set of copy- on-write data and corresponding metadata to be recorded, selecting the sole set; and if the storage unit has been overwritten more than once during the selected time interval causing multiple sets of copy-on-write data and corresponding metadata to be recorded, selecting one of the multiple sets.
  • the selected set of copy-on-write data and corresponding metadata may be the earliest set recorded for the selected time interval.
  • the method may further comprise coalescing metadata in the one or more identified sets of copy-on-write data and corresponding metadata.
  • the method may further comprise: identifying copy-on-write data that correspond to the coalesced metadata; and replacing all sets of copy-on- write data and corresponding metadata previously recorded for the selected time interval with a new set comprising the identified copy-on-write data and the coalesced metadata.
  • the method may further comprise: selecting multiple time intervals in a portion of the timeline based on a desired granularity level for the portion of the timeline; and repeating the steps of identifying and discarding for the selected multiple time intervals.
  • the storage system may comprise a plurality of storage devices and the method may further comprise: repeating the steps of identifying and discarding for one or more of the plurality of storage devices to cause the plurality of storage devices to have a consistent granularity level of the timeline with respect to one another.
  • the steps of selecting, identifying and discarding may be triggered when one or more of the following conditions are met: a predetermined storage capacity for the timeline has been consumed; a predetermined amount of data have been accumulated for a granularity level of the timeline; granularity levels of the timeline for at least two storage devices in the storage system are inconsistent; an instruction to reduce the granularity of the timeline is received; and a scheduled time for reducing the granularity of the timeline is reached.
  • the method may further comprise scanning the storage system for a storage device for which the granularity of the timeline can be reduced.
  • the techniques may be realized as at least one signal embodied in at least one carrier wave for transmitting a computer program of instructions configured to be readable by at least one processor for instructing the at least one processor to execute a computer process for performing the method as recited above.
  • the techniques may be realized as at least one processor readable carrier for storing a computer program of instructions configured to be readable by at least one processor for instructing the at least one processor to execute a computer process for performing the method as recited above.
  • the techniques may be realized as a system for timeline compression in a storage system, wherein digital content of the storage system is backed up to enable restoration of the digital content to one or more points in a timeline.
  • the system may comprise means for selecting a time interval in the timeline.
  • the system may also comprise means for identifying one or more sets of backup data recorded for the selected time interval, wherein the identified one or more sets of backup data represent at least a portion of old data overwritten during the selected time interval.
  • the system may further comprise means for discarding other backup data recorded for the selected time interval, thereby reducing a granularity level of the timeline in the selected time interval.
  • the techniques may be realized as a system for timeline compression in a storage system, wherein digital content of the storage system is backed up to enable restoration of the digital content to one or more points in a timeline.
  • the system may comprise a storage medium for storing instructions .
  • the system may also comprise at least one processor for: selecting a time interval in the timeline; identifying one or more sets of backup data recorded for the selected time interval, wherein the identified one or more sets of backup data represent at least a portion of old data overwritten during the selected time interval; and discarding other backup data recorded for the selected time interval, thereby reducing a granularity level of the timeline in the selected time interval .
  • Figure Ia shows a timeline maintained for a storage system based on a traditional method.
  • Figure Ib shows a timeline maintained for a storage system in accordance with an embodiment of the present disclosure .
  • Figure 2 shows a flow chart illustrating an exemplary timeline compression method in accordance with an embodiment of the present disclosure.
  • Figure 3 shows a state diagram illustrating an exemplary method for timeline compression in accordance with an embodiment of the present disclosure.
  • Figure 4 shows an exemplary timeline for three related LUs in accordance with an embodiment of the present disclosure .
  • Figure 5 shows another exemplary timeline for three related LUs in accordance with an embodiment of the present disclosure.
  • Figure 6 shows major objects involved in an exemplary program for timeline compression in accordance with embodiments of the present disclosure.
  • backup data refers generally to data that have been recorded and/or organized (or even reorganized) with a purpose of restoring or recovering digital content of a storage system.
  • Copy-on-write data (or “COW data”) refers to substantive data (e.g., new data to be written or old data to be overwritten in response to a write command) that have been recorded in a copy-on-write operation. New data to be written in response to a write command are sometimes referred to as "after image data” or "after image,” while old data to be overwritten in response to a write command are sometimes referred to as "before image data” or “before image.”
  • the copy-on-write operation may be an actual operation performed in response to an actual write command. Or, the copy-on-write operation may be a virtual operation that includes the collective effect of multiple copy-on-write operations that occur during a selected time interval.
  • Corresponding metadata refers to informational data (e.g., timestamps) regarding the associated COW data in a copy-on-write operation.
  • informational data e.g., timestamps
  • one copy-on-write operation causes one set of COW data and corresponding metadata to be created.
  • COW data and corresponding metadata may be stored in separate storage devices or segments. In a time store, COW data may be organized in one or more timestamped "data chunks.”
  • Raw data refers to one or more sets of COW data and corresponding metadata that have been recorded in response to actual write commands and have not been coalesced or otherwise modified since their recordation.
  • COW data and corresponding metadata may refer to COW data and corresponding metadata, respectively, that have been coalesced, re-organized or otherwise modified in a timeline compression process, wherein a resulting set of COW data and corresponding metadata may be considered as originating from a virtual copy-on-write operation in response to one or more write commands during a selected time interval.
  • COW data and “corresponding metadata” may sometimes refer to backup data that are not on the raw data level.
  • “Granularity level" of a timeline refers to a time scale
  • the granularity level of a timeline is typically determined by the specific mechanism employed to back up digital content, how complete backup data are kept, and how the backup data are organized.
  • a typical "storage system” may comprise one or more storage devices which may be physical, virtual or logical devices or a combination thereof.
  • a storage system may comprise a storage area network (SAN) having one or more datasets, wherein each dataset may comprise one or more nodes, and wherein one or more logical units (LUs) may be coupled to each node.
  • SAN storage area network
  • LUs logical units
  • the term “storage system” may refer to an entire storage system or a portion (e.g., dataset or node) thereof.
  • a timeline may be maintained for all LUs in a same dataset.
  • Timeline storage refers to a storage space for backup data in a time store. Timeline storage is typically organized in terms of quota groups, wherein each quota group allocates a predetermined storage space for a timeline associated with a corresponding dataset.
  • Embodiments of the present disclosure provide a technique known as "timeline compression" that allows a more extended timeline to be maintained for a storage system (or a dataset) without any substantial increase in timeline storage capacity or complete discarding of older backup data. This may be achieved by selectively decreasing a granularity level of the timeline as backup data are aging.
  • One or more older portions of raw data backed up for a storage system may be coalesced and/or re-organized into one or more data chunks that reflect write operations in the storage system on a coarser level of granularity (e.g., hourly or daily) than the raw data normally would reflect.
  • Such reduction in the granularity level of the timeline may offer a flexible, user-definable tradeoff wherein the timeline storage is economized without sacrificing older data entirely. As a result, a much longer timeline may be maintained for a storage system without any significant impact on its data protection or data recovery capabilities.
  • the coalescence and/or re-organization process of backup data from one granularity level to another may be referred to as a "timeline rollup" or "rollup.”
  • FIG. Ia there is shown a timeline maintained for a storage system based on a traditional method.
  • present day may be Monday of Week 0.
  • the timeline may have been continuously maintained for a storage system for a few weeks (i.e., Week -1, Week -2, Week -3, Week -4 and so on) . If several weeks' worth of backup data were all stored in the form of raw data, a large amount of storage space in a time store would be required. If, for example, there is only enough storage space to store fourteen days' worth of raw data, then, according to traditional approaches, those raw data that are more than fourteen days old must be completely discarded.
  • Figure Ib shows a timeline maintained for a storage system in accordance with an embodiment of the present disclosure.
  • This timeline may be generated by subjecting raw data to a timeline compression process that selectively reduces a granularity level of the timeline. It is recognized that, as time goes by, the oldest backup data are the least likely to be needed on the finest granularity level. Therefore, it might suffice to keep only a few days' worth of raw data in order to be able to restore the storage system to any point in time in the past few days . For older backup data, the granularity level of the timeline may be progressively reduced.
  • backup data for the past three days are kept in the form of raw data.
  • the backup data may be kept in the form of hourly data. That is, the original raw data may be selectively coalesced and/or discarded, as will be described in more detail below, such that only enough backup data is kept to be able to restore digital content of the storage system to any hour during the second time period.
  • the backup data may be kept in the form of daily data.
  • a timeline compression functionality in accordance with embodiments of the present disclosure may be implemented in any type of storage systems, preferably in connection with a storage management system hav ⁇ ng a current store and a time store.
  • a set of parameters known as Timeline Lifecycle Profile (TLP)
  • TLP may be configured by a user to control the timeline compression process.
  • the TLP may specify four levels of backup data and a user configurable amount of time to keep each level of backup data before that level of backup data may be rolled up to a next level.
  • the TLP may also specify a minimum amount of timeline storage used before a rollup takes place.
  • the timeline illustrated therein reflects one exemplary TLP relating to four levels of backup data.
  • Level-0 TLP may specify conditions that must be fulfilled before raw data can be rolled up to the next level.
  • the conditions may be defined as an amount of raw data, in terms of time length and/or timeline storage capacity, to keep before some raw data may be rolled up to the next level.
  • the Level-0 TLP may require that at least 3 days' worth of raw data using 40% of the timeline storage capacity be accumulated before raw data older than 3 days or beyond the 40% storage limit may be rolled up to the next level. According to this configuration, even if there are more than 3 days of raw data, the raw data older than 3 days will not be rolled up until the raw data have also used up at least 40% of the timeline storage capacity.
  • This configuration may also require that, even if 40% of the timeline storage capacity is occupied by raw data, a rollup is not performed unless more than 3 days' worth of raw data have been accumulated.
  • a default value for the time length may be infinite, which means that all other levels may be ignored and there will be no rollup of Level-0 raw data.
  • a default limit for timeline storage capacity may be 0%, which means the amount of timeline storage in use will not be considered in determining whether to initiate a rollup of the raw data.
  • Level-1 TLP may specify a reduced granularity level (e.g., hourly) of the timeline compared with Level-0, as well as conditions that must be met before Level-1 data (e.g., hourly data) can be rolled up to the next level. Similar to Level-0 TLP, the conditions may be defined as an amount of Level-1 data, in terms of time length and/or timeline storage capacity, to keep before Level-1 data may be rolled up to the next level (e.g., as shown in Figure Ib, 11 days' worth of hourly data using 20% of the timeline storage capacity) . In the Level-1 TLP, a default value for the time length may be infinite, which means that all other levels may be ignored and rollups do not continue beyond Level-1 data.
  • a default value for the time length may be infinite, which means that all other levels may be ignored and rollups do not continue beyond Level-1 data.
  • a default limit for timeline storage capacity may be 0%, which means the amount of timeline storage in use will not be considered in determining whether to initiate a rollup of the Level-1 data.
  • Level-2 TLP may specify a further reduced granularity level (e.g., daily) of the timeline as well as conditions that trigger a rollup of the Level-2 data. For example, the Level- 2 TLP may require that at least 14 days' worth of daily data using 20% of the timeline storage capacity be accumulated before the older daily data may be rolled up to the next level .
  • Level-3 TLP may specify an even further reduced granularity level (e.g., weekly) of the timeline as well as conditions that trigger a rollup of the Level-3 data to the next level (e.g., monthly data) .
  • the Level-3 TLP may require that at least 12 weeks' worth of weekly data using 10% of the timeline storage capacity be accumulated before the older weekly data may be rolled up to the next level.
  • a user typically does not explicitly create a TLP since a default TLP may already exist when a quota group is created in a storage system.
  • the user may have the option of modifying the default parameters of the TLP.
  • a user typically does not explicitly delete a TLP.
  • the TLP may be deleted when the associated quota group is deleted.
  • a user may modify a TLP in order to change the desired behavior of timeline compression.
  • the TLP may be modified at any time without any immediate effect on the timeline.
  • the default TLP upon creation of a quota group, may specify that no rollups take place.
  • a user may also modify a TLP when modifying attributes of a quota group.
  • the LU When an LU is added to a dataset, the LU may inherit an existing TLP for the corresponding quota group.
  • the effect on the timeline may be that the start of the timeline may shift forward. This behavior may be the same as when there are no rollups defined. However, rollups may continue at the current rollup level for the entire dataset, and the new LU' s current rollup state may be set to reflect that of the rest of the LUs in the dataset.
  • the start of remaining timeline When an LU is removed from a dataset, the start of remaining timeline may shift backward. This may be the same behavior exhibited when there are no rollups defined.
  • FIG. 2 there is shown a flow chart illustrating an exemplary timeline compression method in accordance with an embodiment of the present disclosure.
  • a rollup may be started for a storage device in a storage system.
  • the method steps in Figure 2 illustrate a simplest rollup operation of backup data recorded for a portion of a timeline from one level to a next level, wherein it is assumed that the timeline is maintained for a particular storage device only. Timeline compression involving multiple storage devices will be described separately below.
  • a time interval may be selected for a rollup operation. Selection of the time interval is typically based on conditions specified in the TLP. For example, if it is a rollup from raw data to hourly data, the time interval may be one hour long and selected from a portion of the timeline where hourly data are desired. This portion of the timeline may span multiple hours. Thus, the method steps 204 through 212 may be repeated for every hour in this portion of the timeline. Similarly, if it is a rollup from hourly data to daily data, the time interval may be 24 hours long and selected from a portion of the timeline where daily data are desired.
  • COW data and corresponding metadata may be identified to represent backup data recorded for the selected time interval.
  • a unit of storage (e.g., a block) in the storage device may have been overwritten one or more times during the selected time interval. If a block has been overwritten only once during the selected time interval, the resultant set of COW data and corresponding metadata may be identified to represent backup data for this block. If a block has been overwritten multiple times during the selected time interval, a set of COW data and corresponding metadata that results from the earliest write operation may be identified to represent backup data for this block. Alternatively, a set of COW data and corresponding metadata that results from the latest write operation during the selected time interval may be identified. Additional or alternative criteria may be used to identify the representative backup data for the storage device during the selected time interval.
  • step 208 other backup data that have been recorded for the selected time interval but are not selected in step 206 may be discarded or simply ignored.
  • metadata or other indexing data for the unselected backup data may be deleted or erased such that the unselected backup data are effectively deleted from the timeline.
  • step 210 the COW data and corresponding metadata identified or selected in step 206 may be coalesced.
  • these COW data and/or corresponding metadata are preferably coalesced into fixed size allocation units known as "buckets.” For example, when rolling up raw data into hourly data, one hour's worth of raw data may be coalesced into one 512 KB fixed-size hourly- bucket.
  • 24 hourly buckets of backup data may be coalesced into one 12 MB fixed-size daily bucket.
  • Coalescence of the selected COW data and corresponding metadata may be carried out in a number of ways.
  • the metadata for the selected time interval may be coalesced first.
  • the COW data (pointed to by the coalesced metadata) may be coalesced and copied into memory.
  • the coalesced COW data may then be stored as new, higher level COW data for the selected time interval.
  • the coalesced metadata may be modified and stored as corresponding metadata for the new COW data.
  • step 212 it may be determined whether the rollup has been done for this storage device. If there are additional time intervals to roll up, the process may loop back to step 204 to repeat the coalescence of backup data until the rollup for all appropriate time intervals has been completed according to the requirements specified in the TLP. Then, in step 214, the rollup may end for this storage device.
  • a timeline rollup operation may be configured (e.g., as a thread or sub-routine) to start or restart upon initiation by a user or upon triggering of one or more events defined in the TLP. For example, the rollup thread may be activated whenever a pre-determined percentage of the timeline storage has been used, before or after a deprecation of timeline, and/or on a periodic basis.
  • a rollup thread may also be awoken when a second rollup thread on another node determines that it must rollup data for an LU on that node .
  • FIG 3 there is shown a state diagram illustrating an exemplary method for timeline compression in accordance with an embodiment of the present disclosure.
  • the state diagram shows five phases in a timeline rollup operation.
  • the rollup operation may be preferably a thread running on or in coordination with a storage management system.
  • the rollup thread may coalesce and/or re-organize backup data for a storage system by going through a Determination Phase, a Scan Phase, a Coalescence Phase, a Copy Phase, and a Replacement Phase.
  • a typical environment for implementation of a timeline compression may be a storage management system coupled to a storage system having a plurality of storage devices (e.g., LUs) .
  • One typical requirement for timeline compression involving multiple LUs is consistency of granularity levels of the timeline across all LUs. Accordingly, there may be a need to determine which level of backup data to roll up and which LU to start with.
  • the level of backup data to perform the rollup for also known as a "rollup level,” may be determined based on rollup state data (described in detail below) that have been maintained for the LUs .
  • the LUs may be examined one at a time, typically by analyzing the rollup state data and/or other informational data associated with the LUs. For each LU, the oldest backup data in the timeline may be identified for the current rollup level. If, for example, the LU in question is owned by a local node for which the rollup thread is running, and if there are enough valid, sealed backup data for the time range in question (e.g., at least two data chunks), then the rollup operation may proceed to the next phase (i.e., Scan Phase). Otherwise, another LU may be chosen and analyzed. If no LU is found that meets the criteria defined in the TLP, then the rollup operation may end.
  • the next phase i.e., Scan Phase
  • all related LUs e.g., those associated with the same quota group
  • the rollup thread on other nodes may be awoken using a remote message.
  • a scan of the metadata may be performed in order to identify the time period defined by the TLP and to retrieve relevant metadata.
  • the scan may be a query of the metadata on a slice by slice basis in time order.
  • each LU may be divided into a plurality of fixed-size logical partitions (e.g., 16 Gigabytes (GB) each) for ease of management and for load balancing purposes, wherein each fixed-size logical partition may be referred to as one "slice.”
  • the identified metadata may be coalesced in the Coalescence Phase, after which a next slice may be scanned in the Scan Phase.
  • the slice by slice cycle may repeat until all slices have been exhausted for the LU and time period in question.
  • the metadata that have been identified in the Scan Phase may be coalesced into fixed size allocation units. Coalescence of the metadata may be achieved in any of a variety of ways. According to one embodiment, the identified metadata may first be stored in memory in a time- ascending order according to their timestamps. Then, starting from the oldest metadata, the identified metadata may be inserted into a binary tree (B-tree) that is indexed by starting Logical Block Addresses (LBA' s) recorded in the metadata. The B-tree may be first scanned for LBA overlap before the coalesced metadata are inserted. The newer COW data containing LBA overlaps may be discarded. Splits may also be done on COW data where needed to achieve coalescence.
  • B-tree binary tree
  • LBA' s Logical Block Addresses
  • These statistics may be kept on an LU basis so that a determination can be made in the Copy Phase as to whether to actually copy the COW data into a rollup chunk or simply modify the corresponding (coalesced) metadata.
  • the statistics kept may include, for example, the number of original blocks, the number of duplicate blocks (block savings) , the number of original COW operations, and the number of coalesced COW operations (metadata savings) .
  • Each resulting metadata row may be that of the earliest original operation in a particular slice. For example, if Block 128 was written twice in a row, once at time Tl and again at time 12, the resulting coalesced metadata may only reflect the write operation at time Tl. Once the metadata for a slice has been coalesced, the next slice may be processed for the same LU in the Scan Phase. This procedure continues until all slices for the LU have been processed, whereupon the Copy Phase may be executed.
  • the coalesced metadata may be read from memory, and the COW data the coalesced metadata point to may be copied into rollup chunks. Whether or not to actually copy the COW data may depend on an evaluation of the statistics collected in the Coalescence Phase. General, an actual copy of the COW data is performed only when there is some saving of storage space. After the evaluation has passed and all of the metadata have been coalesced for an LU, the COW data may be copied into resulting rollup chunks on a slice by slice basis. The COW data may be copied from a time store (in the storage management system) to the same time store using pre-allocated non-replicated buffers.
  • an event chain may be created and a RollupTimeStoreMove event may be pushed onto the event chain.
  • the RollupTimeStoreMove object may be derived from an SGIO and a WaitableEvent object and may be handled by an IO execution context.
  • the event may have two extents, one for the read of the original COW data and one for the write to the rollup chunk in the time store.
  • the Copy Phase may wait for the event to complete and then update an in-memory array with a data structure representing a new indexing operation. This array may be used in the Replacement Phase to update the coalesced metadata. Once all of the COW data have been copied, the rollup thread may proceed to the Replacement Phase.
  • the relevant portion of old COW data may be replaced with the newly created rollup chunks, the corresponding metadata may be replaced or modified to reflect the new chunks and coalesced COW data contained therein, and the rollup state may be updated.
  • the Replacement Phase is typically carried out atomically and may be rolled back should a catastrophic failure event occur.
  • the LU whose metadata are being updated may be locked to keep configuration from changing and to prevent timeline deprecation from occurring during this phase.
  • the old COW data coalesced in the previous phases may be freed, and the new rollup chunks may be added to the appropriate place in the timeline.
  • the original metadata may be deleted and replaced by the new, coalesced metadata.
  • the LU may be unlocked, and a next LU that meets the Determination Phase criteria may be processed.
  • the old COW data may be transformed into new rollup chunks without an actual copy taking place.
  • the original data chunks may simply be updated to reflect the rollup timestamps, and their rollup level may be updated accordingly.
  • the rollup operation runs through a number of phases one of which involves copying COW data to newly rolled-up chunks, which may take a significant amount of time.
  • other critical components of the system that interfere with rollups or change the state of the timeline such as Instant Restore, Time Images, or Timeline Deprecation, may cause an in-progress rollup to be canceled. If a rollup is canceled during processing of a particular level, all other levels may ⁇ be cancelled as well. Therefore, in the state diagram shown in Figure 3, there is a Cancel route from almost every phase to End.
  • the Replacement Phase may not be arbitrarily cancelled and may proceed while the LU in question is locked.
  • the timeline compression process may be preferably scheduled to start when resources in the storage system and/or the storage management system are in low demand.
  • the rollup state may be stored in a database table in a global database called "rollup_state, " one example of which is shown in Table 1.
  • Each entry in Table 1 may have a generation number that uniquely identifies the rollup level for each LU.
  • the generation number may be updated whenever a rollup is completed for an LU.
  • each LU entry in the global database may have a field describing the last rollup level for it. This may be used to determine the timeline for an LU within a rollup level.
  • rollup_history one example of which is shown as Table 2.
  • Table 2 Rollup History Table.
  • This information may be used to determine valid image times for an LU and rollup level. Once a rollup level is rolled up (e.g. from Level-1 to Level-2) or a rollup level has been deprecated, the entry representing that particular rollup may be deleted.
  • the result of a rollup on one LU may affect how the timeline for a group of LUs is represented.
  • a timeline rollup' involves a group of LUs (e.g., in a dataset or quota group)
  • the start of a timeline for the group of LUs may be the earliest common timeline start (ECTS) among all the LUs.
  • ECTS earliest common timeline start
  • Figure 4 illustrates two different rollup levels across three related LUs. Each tick on the timelines may represent a data chunk in a time store.
  • the start of the timeline for hourly data may be time t3 since it is the ECTS among the three LUs.
  • valid image times are t3, t4, and t5 for the hourly data.
  • the times tO, tl, and t2 can only be chosen through dissociation with the other related LUs.
  • times t3, t4, and t5 are hourly buckets of backup data and are essentially single-point-in- time (SPIT) images, image times chosen in between these times may be invalid.
  • SPIT single-point-in- time
  • the Level-0 data in this example runs from time t6 through a present time. Any Level-0 time between t6 and the present time may be valid image times.
  • primitive APIs may be provided to represent a timeline that accommodates transient rollup inconsistencies.
  • primitive APIs may be provided to perform the following functions: (a) retrieve start and end of timeline for an LU across all rollup levels, wherein the start and end time range, as well as the generation number for the last rollup, may be returned for the LU; (b) retrieve start and end time of a timeline for an LU witnm each rollup level for an LU (e.g.
  • start and end of Level-1 data for LU-I wherein the start and end time range, as well as the generation number for the last rollup, may be returned for Level-0, Level-1, Level-2 and Level-3 data; (c) retrieve the next and previous image times based on an input image time for an LU, wherein the start time before and the start time after the image time may be returned for each of the two times.
  • a user or client program that has knowledge about the relationship among the LUs may query the information for each LU and determine the start and end of the timeline for each level.
  • the primitive APIs may be used to find the start and end of the Level-1 timeline for the related Lus as follows.
  • the ECTS may be found for the set of LUs based on what the latest timeline start is for the set of LUs, in this case time t3.
  • the Level-1 data with earliest start time past the ECTS, in this case t5 may be the start of the Level-1 timeline.
  • the Level-1 data with the latest end time past the ECTS, in this case t5 may be the end of the Level-1 timeline .
  • All image times chosen between the start and end times may be validated by using API(c) above for each LU.
  • Finding the closest time before and after the image time may yield up to two valid data points for an image time.
  • the primitive APIs may be used to find the start of the Level-0 timeline for the related LUs in Figure 4.
  • the ECTS may be found for the set of LUs based on what the latest timeline start is for the set of LUs, in this case time t3.
  • the Level-0 data with the earliest start time past the latest end time of the Level-1 data, in this case time t6, may be the start of the Level-0 timeline.
  • Any image time from this point forward may be valid for Level-0 data.
  • an image time may be chosen in a two-stage process wherein the image time is validated (or confirmed) by each storage device before the requested Time Image or Instant Restore operation takes place.
  • the validation phase in that two-stage process may cancel a currently running rollup and prevent other rollups from running.
  • the validation phase may complete in error to force a new query of the timeline.
  • Configuration events in the validate phase for Time Image and Instant Restore may also pass in the rollup generation number queried when the timeline was queried. If the generation number has changed since the query, the validation phase may also complete in error to force a new query of the timeline.
  • each quota group may have an allocated timeline storage space for rollup purposes .
  • the amount of storage provisioned may be based on the following formula: (Maximum number of LUs in the storage system x Maximum number of rollup levels possible) + 100 working chunks for doing a rollup .
  • Rollup chunks may be essentially transformed into new COW data in the Replacement Phase.
  • the old data chunks may be freed as they are replaced.
  • the rollup quota may be updated to reflect changes in the amount of space used. This guarantees that a rollup does not cause a deprecation of timeline and that there is space for at least 100 rollup chunks available at the start of any given rollup.
  • the rollup thread on other nodes may be woken as well, so that LUs belonging to the same dataset may be processed.
  • the mechanism used to awaken the remote thread may be a simple spread message.
  • Every capturing LU may have an active rollup chunk for every level configured in the TLP.
  • an LU has capture mode turned on a rollup chunk may be activated for each level configured.
  • Timeline deprecation typically involves discarding older backup data in a timeline once the timeline storage is approaching its quota. If a deprecation of timeline is about to take place, any rollup currently running may be immediately cancelled. When the deprecation is completed, another rollup may be immediately scheduled.
  • Rolled-up data may typically be deprecated first in the timeline since they may be the oldest data in the timeline.
  • One anomaly in terms of deprecation may be that it is possible for an active rollup chunk to be deprecated.
  • Multiple rollup chunks may contain duplicate start times, much like data chunks copied back during an Instant Restore. The same deprecation rules apply to these rollup chunks as do the copy back chunks .
  • Rollup chunks with duplicate start times may be all deprecated regardless of how much space is needed.
  • Time images may be short lived entities. As a result, they may be deleted when deprecation of timeline takes place.
  • One goal of timeline compression may be to avoid this deprecation of timeline based on the premise that backup data at a higher level of granularity may be better than no data at all. This being the case, there may be two options:
  • a global option may be set up by a user to control how rollups behave when encountering a time image. For example, any time image creation may cancel a running rollup.
  • An instant restore may cause the state of a timeline to change drastically and quickly. As a result, an active rollup may be immediately canceled when an instant restore is initiated.
  • timeline annotations may be invalidated when timeline is deprecated. The same holds true for rollups .
  • any running rollup may be cancelled.
  • Leftover data for rollups that may have been in progress on a remote node may be cleaned up by a surviving node.
  • Rollup chunks may be scrubbed the same way COW data may be scrubbed on failover.
  • a RollupManager object may be an interface for starting, canceling, maintaining synchronization, and querying state for rollups . In addition, it may be responsible for maintaining TLP objects.
  • the RollupManager may contain an instance of a TimelineRollup object.
  • the TimelineRollup object may be an active object responsible for performing all phases of a rollup.
  • There may also be an object called RollupState which may be an interface for querying and setting state for rollups. It may maintain transient states related to the rollup process as well as the persistent states for LUs which may be stored in a global database.
  • a RegionMaps/lndexing object may be responsible for building B-trees as described above.
  • a tsAlloc object may allocate time store cache for rollup chunks .
  • a tsQuotaGroup object may allocate timeline storage space for a dataset.
  • a TimelineProfile object may record a TLP for a dataset.
  • the technique for timeline compression in accordance with the present disclosure as described above typically involves the processing of input data and the generation of output data to some extent.
  • This input data processing and output data generation may be implemented in hardware or software.
  • specific electronic components may be employed in a storage area network (SAN) or similar or related circuitry for implementing the functions associated with timeline compression in accordance with the present disclosure as described above.
  • one or more processors operating in accordance with stored instructions may implement the functions associated with timeline compression in accordance with the present disclosure as described above. If such is the case, it is within the scope of the present disclosure that such instructions may be stored on one or more processor readable carriers (e.g., a magnetic disk), or transmitted to one or more processors via one or more signals.
  • processor readable carriers e.g., a magnetic disk

Abstract

A technique for timeline compression in a data store is disclosed. In one particular exemplary embodiment, the technique may be realized as a method for timeline compression in a storage system, wherein digital content of the storage system is backed up to enable restoration of the digital content to one or more points in a timeline. The method may comprise selecting a time interval in the timeline, one or more sets of backup data recorded for the selected time interval. The method may further comprise discarding other backup data recorded for the selected time interval, thereby reducing a granularity level of the timeline in the selected time interval.

Description

TECHNIQUE FOR TIMELINE COMPRESSION IN A DATA STORE
CROSS-REFERENCE TO RELATED APPLICATIONS
This patent application claims priority to U.S. Provisional Patent Application No. 60/726,187, filed October 14, 2005, which is hereby incorporated by reference herein in its entirety.
This patent application is related to U.S. Patent
Application No. 10/924,652, filed August 24, 2004, which is a continuation-in-part of U.S. Patent Application No.
10/668,833, filed September 23, 2003, each of which is hereby incorporated by reference herein in its entirety.
FIELD OF THE DISCLOSURE The present disclosure relates generally to data storage and, more particularly, to a technique for timeline compression in a data store.
BACKGROUND OF THE DISCLOSURE In related U.S. Patent Application No. 10/924,652 and U.S. Patent Application No. 10/668,833, a time-dependent data storage and recovery technique is disclosed. Embodiments of such a technique provide a solution for continuous data protection (CDP) wherein write commands directed to a storage system are intercepted by a storage management system having a current store and a time store. The current store may maintain or have access to a current (or mirror) copy of the storage system's digital content. The time store may record information associated with each intercepted write command, such as new data in the write command's payload or old data to be overwritten in the current store in response to the write command. Recordation of the new or old data in response to a write command may be referred to as a copy-on-write (COW) operation, and the new or old data recorded may be referred to as COW data. The time store may also record other information (i.e., metadata) associated with an intercepted write command and/or the corresponding COW operation, such as, for example, a timestamp, an original location in the current store where the old data are overwritten, and a destination location in the time store to which the COW data are copied. Each COW operation typically backs up one or more blocks of COW data, thereby creating one set of COW data and corresponding metadata. Over a period of time, multiple sets of COW data and corresponding metadata (including timestamps) may be accumulated as a collection of historical records of what have been written or overwritten in the current store or the storage system. The content of the time store may be indexed based on the metadata to facilitate efficient access to the COW data.
With a current copy of the storage system' s digital content in the current store and the historical records in the time store, the storage management system adds a new dimension, i.e., time, to the storage system. Assuming the storage management system has been operatively coupled to the storage system since a past time, the storage management system may quickly and accurately restore any addressable content in the storage system to any point in time between the past time and a present time. Ideally, it might be desirable to maintain such a data recovery capability for as long a timeline as possible. However, to accommodate an extended timeline, a significant amount of storage space is needed to store the COW data and corresponding metadata for every write command in that timeline. Even more storage space is needed if the storage system sees a relatively high write rate (i.e., number of write operations per unit time) . One temporary solution may be to simply increase storage capacity of the time store. However, apart from a higher cost, a simple storage increase may not scale well with the rest of the system and tends to create a deluge of other problems, such as a performance degradation due to difficulties of parsing through an additional amount of data. Without an infinite storage capacity, most storage systems have to settle for the reality that only a finite length of timeline (e.g., ten days or two weeks) can be maintained. In conventional data protection systems, it is typical to keep a few days' worth of backup data and completely discard the backup data that are more than a few days old. In these systems, data recovery capabilities are limited to the past few days for which backup data are available. Alternatively, the backup data that are more than a few days old may be moved off site on a regular basis. Such a brute-force solution can be costly and disruptive, not to mention its slow response to data recovery requests where off- site data are needed.
In view of the foregoing, it would be desirable to provide a solution for data storage management which overcomes the above-described inadequacies and shortcomings.
SUMMARY OF THE DISCLOSURE
A technique for timeline compression in a data store is disclosed. In one particular exemplary embodiment, the technique may be realized as a method for timeline compression in a storage system, wherein digital content of the storage system is backed up to enable restoration of the digital content to one or more points in a timeline. The method may comprise selecting a time interval in the timeline. The method may also comprise identifying one or more sets of backup data recorded for the selected time interval, wherein the identified one or more sets of backup data represent at least a portion of old data overwritten during the selected time interval. The method may further comprise discarding other backup data recorded for the selected time interval, thereby reducing a granularity level of the timeline in the selected time interval.
In accordance with other aspects of this particular exemplary embodiment, the digital content of the storage system may be backed up through copy-on-write operations into a plurality of sets of copy-on-write data and corresponding metadata, and the step of identifying may further comprise identifying one or more sets of copy-on-write data and corresponding metadata recorded for the selected time interval.
In accordance with further aspects of this particular exemplary embodiment, a length of the time interval may be selected based at least in part on a desired granularity level of the timeline. In accordance with additional aspects of this particular exemplary embodiment, the step of identifying may further comprise: determining whether a storage unit in the storage system has been overwritten more than once during the selected time interval; if the storage unit has been overwritten once during the selected time interval causing a sole set of copy- on-write data and corresponding metadata to be recorded, selecting the sole set; and if the storage unit has been overwritten more than once during the selected time interval causing multiple sets of copy-on-write data and corresponding metadata to be recorded, selecting one of the multiple sets.
In accordance with another aspect of this particular exemplary embodiment, if the storage unit has been overwritten more than once during the selected time interval, the selected set of copy-on-write data and corresponding metadata may be the earliest set recorded for the selected time interval.
In accordance with yet another aspect of this particular exemplary embodiment, the method may further comprise coalescing metadata in the one or more identified sets of copy-on-write data and corresponding metadata. In accordance with still another aspect of this particular exemplary embodiment, the method may further comprise: identifying copy-on-write data that correspond to the coalesced metadata; and replacing all sets of copy-on- write data and corresponding metadata previously recorded for the selected time interval with a new set comprising the identified copy-on-write data and the coalesced metadata.
In accordance with a further aspect of this particular exemplary embodiment, the method may further comprise: selecting multiple time intervals in a portion of the timeline based on a desired granularity level for the portion of the timeline; and repeating the steps of identifying and discarding for the selected multiple time intervals.
In accordance with a yet further aspect of this particular exemplary embodiment, the storage system may comprise a plurality of storage devices and the method may further comprise: repeating the steps of identifying and discarding for one or more of the plurality of storage devices to cause the plurality of storage devices to have a consistent granularity level of the timeline with respect to one another.
In accordance with a still further aspect of this particular exemplary embodiment, the steps of selecting, identifying and discarding may be triggered when one or more of the following conditions are met: a predetermined storage capacity for the timeline has been consumed; a predetermined amount of data have been accumulated for a granularity level of the timeline; granularity levels of the timeline for at least two storage devices in the storage system are inconsistent; an instruction to reduce the granularity of the timeline is received; and a scheduled time for reducing the granularity of the timeline is reached.
In accordance with another aspect of this particular exemplary embodiment, the method may further comprise scanning the storage system for a storage device for which the granularity of the timeline can be reduced.
In another particular exemplary embodiment, the techniques may be realized as at least one signal embodied in at least one carrier wave for transmitting a computer program of instructions configured to be readable by at least one processor for instructing the at least one processor to execute a computer process for performing the method as recited above.
In yet another particular exemplary embodiment, the techniques may be realized as at least one processor readable carrier for storing a computer program of instructions configured to be readable by at least one processor for instructing the at least one processor to execute a computer process for performing the method as recited above. In still another particular exemplary embodiment, the techniques may be realized as a system for timeline compression in a storage system, wherein digital content of the storage system is backed up to enable restoration of the digital content to one or more points in a timeline. The system may comprise means for selecting a time interval in the timeline. The system may also comprise means for identifying one or more sets of backup data recorded for the selected time interval, wherein the identified one or more sets of backup data represent at least a portion of old data overwritten during the selected time interval. The system may further comprise means for discarding other backup data recorded for the selected time interval, thereby reducing a granularity level of the timeline in the selected time interval.
In a further particular exemplary embodiment, the techniques may be realized as a system for timeline compression in a storage system, wherein digital content of the storage system is backed up to enable restoration of the digital content to one or more points in a timeline. The system may comprise a storage medium for storing instructions . The system may also comprise at least one processor for: selecting a time interval in the timeline; identifying one or more sets of backup data recorded for the selected time interval, wherein the identified one or more sets of backup data represent at least a portion of old data overwritten during the selected time interval; and discarding other backup data recorded for the selected time interval, thereby reducing a granularity level of the timeline in the selected time interval . The present disclosure will now be described in more detail with reference to exemplary embodiments thereof as shown in the accompanying drawings . While the present disclosure is described below with reference to exemplary embodiments, it should be understood that the present disclosure is not limited thereto. Those of ordinary skill in the art having access to the teachings herein will recognize additional implementations, modifications, and embodiments, as well as other fields of use, which are within the scope of the present disclosure as described herein, and with respect to which the present disclosure may be of significant utility.
BRIEF DESCRIPTION OF THE DRAWINGS
In order to facilitate a fuller understanding of the present disclosure, reference is now made to the accompanying drawings, in which like elements are referenced with like numerals. These drawings should not be construed as limiting the present disclosure, but are intended to be exemplary only.
Figure Ia shows a timeline maintained for a storage system based on a traditional method. Figure Ib shows a timeline maintained for a storage system in accordance with an embodiment of the present disclosure .
Figure 2 shows a flow chart illustrating an exemplary timeline compression method in accordance with an embodiment of the present disclosure.
Figure 3 shows a state diagram illustrating an exemplary method for timeline compression in accordance with an embodiment of the present disclosure. Figure 4 shows an exemplary timeline for three related LUs in accordance with an embodiment of the present disclosure .
Figure 5 shows another exemplary timeline for three related LUs in accordance with an embodiment of the present disclosure.
Figure 6 shows major objects involved in an exemplary program for timeline compression in accordance with embodiments of the present disclosure.
DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS
As used herein, "backup data" refers generally to data that have been recorded and/or organized (or even reorganized) with a purpose of restoring or recovering digital content of a storage system. "Copy-on-write data" (or "COW data") refers to substantive data (e.g., new data to be written or old data to be overwritten in response to a write command) that have been recorded in a copy-on-write operation. New data to be written in response to a write command are sometimes referred to as "after image data" or "after image," while old data to be overwritten in response to a write command are sometimes referred to as "before image data" or "before image." The copy-on-write operation may be an actual operation performed in response to an actual write command. Or, the copy-on-write operation may be a virtual operation that includes the collective effect of multiple copy-on-write operations that occur during a selected time interval.
"Corresponding metadata" refers to informational data (e.g., timestamps) regarding the associated COW data in a copy-on-write operation. Typically, one copy-on-write operation causes one set of COW data and corresponding metadata to be created. Despite their correlation, COW data and corresponding metadata may be stored in separate storage devices or segments. In a time store, COW data may be organized in one or more timestamped "data chunks."
"Raw data" refers to one or more sets of COW data and corresponding metadata that have been recorded in response to actual write commands and have not been coalesced or otherwise modified since their recordation. In some circumstances, "COW data" and "corresponding metadata" may refer to COW data and corresponding metadata, respectively, that have been coalesced, re-organized or otherwise modified in a timeline compression process, wherein a resulting set of COW data and corresponding metadata may be considered as originating from a virtual copy-on-write operation in response to one or more write commands during a selected time interval. In other words, "COW data" and "corresponding metadata" may sometimes refer to backup data that are not on the raw data level. "Granularity level" of a timeline refers to a time scale
(e.g., weekly, daily, hourly, by the second, or by the millisecond) with which digital content of a storage system can be restored to a point in the timeline. The granularity level of a timeline is typically determined by the specific mechanism employed to back up digital content, how complete backup data are kept, and how the backup data are organized.
A typical "storage system" may comprise one or more storage devices which may be physical, virtual or logical devices or a combination thereof. According to one embodiment, a storage system may comprise a storage area network (SAN) having one or more datasets, wherein each dataset may comprise one or more nodes, and wherein one or more logical units (LUs) may be coupled to each node. Hereinafter, for ease of illustration, the term "storage system" may refer to an entire storage system or a portion (e.g., dataset or node) thereof. Typically, a timeline may be maintained for all LUs in a same dataset.
"Timeline storage" refers to a storage space for backup data in a time store. Timeline storage is typically organized in terms of quota groups, wherein each quota group allocates a predetermined storage space for a timeline associated with a corresponding dataset.
Embodiments of the present disclosure provide a technique known as "timeline compression" that allows a more extended timeline to be maintained for a storage system (or a dataset) without any substantial increase in timeline storage capacity or complete discarding of older backup data. This may be achieved by selectively decreasing a granularity level of the timeline as backup data are aging. One or more older portions of raw data backed up for a storage system may be coalesced and/or re-organized into one or more data chunks that reflect write operations in the storage system on a coarser level of granularity (e.g., hourly or daily) than the raw data normally would reflect. Such reduction in the granularity level of the timeline may offer a flexible, user-definable tradeoff wherein the timeline storage is economized without sacrificing older data entirely. As a result, a much longer timeline may be maintained for a storage system without any significant impact on its data protection or data recovery capabilities. The coalescence and/or re-organization process of backup data from one granularity level to another may be referred to as a "timeline rollup" or "rollup."
In the detailed description that follows, references will be made to embodiments of the time-dependent data storage and recovery technique as disclosed in U.S. Patent Application No. 10/924,652 and U.S. Patent Application No. 10/668,833. It should be appreciated that embodiments of the present disclosure are easily adaptable to other data protection methods or systems that maintain historical records of digital content of a storage system.
Referring to Figure Ia, there is shown a timeline maintained for a storage system based on a traditional method. In this example, present day may be Monday of Week 0. The timeline may have been continuously maintained for a storage system for a few weeks (i.e., Week -1, Week -2, Week -3, Week -4 and so on) . If several weeks' worth of backup data were all stored in the form of raw data, a large amount of storage space in a time store would be required. If, for example, there is only enough storage space to store fourteen days' worth of raw data, then, according to traditional approaches, those raw data that are more than fourteen days old must be completely discarded. That is, by the beginning of the present day (i.e., Monday of Week 0), all raw data recorded for Week -3 and earlier may have already been discarded. As the present day goes on and new raw data are accumulated, raw data recorded for Monday of Week -2 may have to be sacrificed in order to make room for the newly recorded raw data. Therefore, at any given time, digital content of the storage system is backed up only for the previous two weeks, while no historical record is available beyond that two-week period.
Figure Ib shows a timeline maintained for a storage system in accordance with an embodiment of the present disclosure. This timeline may be generated by subjecting raw data to a timeline compression process that selectively reduces a granularity level of the timeline. It is recognized that, as time goes by, the oldest backup data are the least likely to be needed on the finest granularity level. Therefore, it might suffice to keep only a few days' worth of raw data in order to be able to restore the storage system to any point in time in the past few days . For older backup data, the granularity level of the timeline may be progressively reduced. As shown in Figure Ib, on Monday of Week 0, for example, backup data for the past three days (i.e., Friday, Saturday and Sunday of Week -1) are kept in the form of raw data. In a second time period, that is, more than three days ago and up to the beginning of Week -2, for example, the backup data may be kept in the form of hourly data. That is, the original raw data may be selectively coalesced and/or discarded, as will be described in more detail below, such that only enough backup data is kept to be able to restore digital content of the storage system to any hour during the second time period. In a third time period that spans Week -3 and Week -4, for example, the backup data may be kept in the form of daily data. Prior to the beginning of Week -4, for example, only weekly data may be kept available. As a result of this exemplary timeline compression scheme, it may be possible to maintain a much longer timeline than the traditional approach illustrated in Figure Ia. Even if there is only enough storage space for fourteen days' worth of raw data, a timeline much longer than two weeks, maybe a few months, may be maintained. As a result, digital content of the storage system that is several weeks old may still be restored. The only tradeoff is that such restoration of the older content may be available on a coarser level of granularity than what raw data can facilitate. For example, instead of being able to pick and choose a data recovery point by the second or by the millisecond, a user may only be able to select recovery points on an hourly, daily or weekly scale.
A timeline compression functionality in accordance with embodiments of the present disclosure may be implemented in any type of storage systems, preferably in connection with a storage management system havάng a current store and a time store. A set of parameters, known as Timeline Lifecycle Profile (TLP) , may be configured by a user to control the timeline compression process. According to one embodiment, the TLP may specify four levels of backup data and a user configurable amount of time to keep each level of backup data before that level of backup data may be rolled up to a next level. The TLP may also specify a minimum amount of timeline storage used before a rollup takes place. Referring again to Figure Ib, the timeline illustrated therein reflects one exemplary TLP relating to four levels of backup data. Level-0 TLP may specify conditions that must be fulfilled before raw data can be rolled up to the next level. The conditions may be defined as an amount of raw data, in terms of time length and/or timeline storage capacity, to keep before some raw data may be rolled up to the next level. For example, the Level-0 TLP may require that at least 3 days' worth of raw data using 40% of the timeline storage capacity be accumulated before raw data older than 3 days or beyond the 40% storage limit may be rolled up to the next level. According to this configuration, even if there are more than 3 days of raw data, the raw data older than 3 days will not be rolled up until the raw data have also used up at least 40% of the timeline storage capacity. This configuration may also require that, even if 40% of the timeline storage capacity is occupied by raw data, a rollup is not performed unless more than 3 days' worth of raw data have been accumulated. In the Level-0 TLP, a default value for the time length may be infinite, which means that all other levels may be ignored and there will be no rollup of Level-0 raw data. A default limit for timeline storage capacity may be 0%, which means the amount of timeline storage in use will not be considered in determining whether to initiate a rollup of the raw data.
Level-1 TLP may specify a reduced granularity level (e.g., hourly) of the timeline compared with Level-0, as well as conditions that must be met before Level-1 data (e.g., hourly data) can be rolled up to the next level. Similar to Level-0 TLP, the conditions may be defined as an amount of Level-1 data, in terms of time length and/or timeline storage capacity, to keep before Level-1 data may be rolled up to the next level (e.g., as shown in Figure Ib, 11 days' worth of hourly data using 20% of the timeline storage capacity) . In the Level-1 TLP, a default value for the time length may be infinite, which means that all other levels may be ignored and rollups do not continue beyond Level-1 data. A default limit for timeline storage capacity may be 0%, which means the amount of timeline storage in use will not be considered in determining whether to initiate a rollup of the Level-1 data. Level-2 TLP may specify a further reduced granularity level (e.g., daily) of the timeline as well as conditions that trigger a rollup of the Level-2 data. For example, the Level- 2 TLP may require that at least 14 days' worth of daily data using 20% of the timeline storage capacity be accumulated before the older daily data may be rolled up to the next level .
Level-3 TLP may specify an even further reduced granularity level (e.g., weekly) of the timeline as well as conditions that trigger a rollup of the Level-3 data to the next level (e.g., monthly data) . For example, the Level-3 TLP may require that at least 12 weeks' worth of weekly data using 10% of the timeline storage capacity be accumulated before the older weekly data may be rolled up to the next level.
According to embodiments of the present disclosure, a user typically does not explicitly create a TLP since a default TLP may already exist when a quota group is created in a storage system. Upon creation of the quota group, the user may have the option of modifying the default parameters of the TLP. Similarly, a user typically does not explicitly delete a TLP. The TLP may be deleted when the associated quota group is deleted. A user may modify a TLP in order to change the desired behavior of timeline compression. The TLP may be modified at any time without any immediate effect on the timeline. The default TLP, upon creation of a quota group, may specify that no rollups take place. A user may also modify a TLP when modifying attributes of a quota group. When an LU is added to a dataset, the LU may inherit an existing TLP for the corresponding quota group. The effect on the timeline may be that the start of the timeline may shift forward. This behavior may be the same as when there are no rollups defined. However, rollups may continue at the current rollup level for the entire dataset, and the new LU' s current rollup state may be set to reflect that of the rest of the LUs in the dataset. When an LU is removed from a dataset, the start of remaining timeline may shift backward. This may be the same behavior exhibited when there are no rollups defined.
Referring to Figure 2, there is shown a flow chart illustrating an exemplary timeline compression method in accordance with an embodiment of the present disclosure.
In step 202, a rollup may be started for a storage device in a storage system. The method steps in Figure 2 illustrate a simplest rollup operation of backup data recorded for a portion of a timeline from one level to a next level, wherein it is assumed that the timeline is maintained for a particular storage device only. Timeline compression involving multiple storage devices will be described separately below.
In step 204, a time interval may be selected for a rollup operation. Selection of the time interval is typically based on conditions specified in the TLP. For example, if it is a rollup from raw data to hourly data, the time interval may be one hour long and selected from a portion of the timeline where hourly data are desired. This portion of the timeline may span multiple hours. Thus, the method steps 204 through 212 may be repeated for every hour in this portion of the timeline. Similarly, if it is a rollup from hourly data to daily data, the time interval may be 24 hours long and selected from a portion of the timeline where daily data are desired. In step 206, COW data and corresponding metadata may be identified to represent backup data recorded for the selected time interval. For example, a unit of storage (e.g., a block) in the storage device may have been overwritten one or more times during the selected time interval. If a block has been overwritten only once during the selected time interval, the resultant set of COW data and corresponding metadata may be identified to represent backup data for this block. If a block has been overwritten multiple times during the selected time interval, a set of COW data and corresponding metadata that results from the earliest write operation may be identified to represent backup data for this block. Alternatively, a set of COW data and corresponding metadata that results from the latest write operation during the selected time interval may be identified. Additional or alternative criteria may be used to identify the representative backup data for the storage device during the selected time interval.
In step 208, other backup data that have been recorded for the selected time interval but are not selected in step 206 may be discarded or simply ignored. For example, metadata or other indexing data for the unselected backup data may be deleted or erased such that the unselected backup data are effectively deleted from the timeline. In step 210, the COW data and corresponding metadata identified or selected in step 206 may be coalesced. According to one embodiment, these COW data and/or corresponding metadata are preferably coalesced into fixed size allocation units known as "buckets." For example, when rolling up raw data into hourly data, one hour's worth of raw data may be coalesced into one 512 KB fixed-size hourly- bucket. Later on, 24 hourly buckets of backup data may be coalesced into one 12 MB fixed-size daily bucket. Coalescence of the selected COW data and corresponding metadata may be carried out in a number of ways. According to one embodiment, the metadata for the selected time interval may be coalesced first. Then, the COW data (pointed to by the coalesced metadata) may be coalesced and copied into memory. The coalesced COW data may then be stored as new, higher level COW data for the selected time interval. Accordingly, the coalesced metadata may be modified and stored as corresponding metadata for the new COW data.
In step 212, it may be determined whether the rollup has been done for this storage device. If there are additional time intervals to roll up, the process may loop back to step 204 to repeat the coalescence of backup data until the rollup for all appropriate time intervals has been completed according to the requirements specified in the TLP. Then, in step 214, the rollup may end for this storage device. A timeline rollup operation may be configured (e.g., as a thread or sub-routine) to start or restart upon initiation by a user or upon triggering of one or more events defined in the TLP. For example, the rollup thread may be activated whenever a pre-determined percentage of the timeline storage has been used, before or after a deprecation of timeline, and/or on a periodic basis. A rollup thread may also be awoken when a second rollup thread on another node determines that it must rollup data for an LU on that node . Referring to Figure 3, there is shown a state diagram illustrating an exemplary method for timeline compression in accordance with an embodiment of the present disclosure. The state diagram shows five phases in a timeline rollup operation. As mentioned above, the rollup operation may be preferably a thread running on or in coordination with a storage management system. Once started, the rollup thread may coalesce and/or re-organize backup data for a storage system by going through a Determination Phase, a Scan Phase, a Coalescence Phase, a Copy Phase, and a Replacement Phase. In the Determination Phase, it may be determined what work needs to be done, such as, for example, what level of backup data to perform the rollup for and for which LU. A typical environment for implementation of a timeline compression may be a storage management system coupled to a storage system having a plurality of storage devices (e.g., LUs) . One typical requirement for timeline compression involving multiple LUs is consistency of granularity levels of the timeline across all LUs. Accordingly, there may be a need to determine which level of backup data to roll up and which LU to start with. The level of backup data to perform the rollup for, also known as a "rollup level," may be determined based on rollup state data (described in detail below) that have been maintained for the LUs . In order to determine which LU to perform the rollup for, the LUs may be examined one at a time, typically by analyzing the rollup state data and/or other informational data associated with the LUs. For each LU, the oldest backup data in the timeline may be identified for the current rollup level. If, for example, the LU in question is owned by a local node for which the rollup thread is running, and if there are enough valid, sealed backup data for the time range in question (e.g., at least two data chunks), then the rollup operation may proceed to the next phase (i.e., Scan Phase). Otherwise, another LU may be chosen and analyzed. If no LU is found that meets the criteria defined in the TLP, then the rollup operation may end. If an LU is found that meets the criteria to perform a rollup, then all related LUs (e.g., those associated with the same quota group) may be rolled up as well. If it is determined that a rollup must occur, the rollup thread on other nodes may be awoken using a remote message.
In the Scan Phase, for backup data that can be rolled up, a scan of the metadata may be performed in order to identify the time period defined by the TLP and to retrieve relevant metadata. The scan may be a query of the metadata on a slice by slice basis in time order. According to embodiments of the present disclosure, each LU may be divided into a plurality of fixed-size logical partitions (e.g., 16 Gigabytes (GB) each) for ease of management and for load balancing purposes, wherein each fixed-size logical partition may be referred to as one "slice." When a slice has been scanned, the identified metadata may be coalesced in the Coalescence Phase, after which a next slice may be scanned in the Scan Phase. The slice by slice cycle may repeat until all slices have been exhausted for the LU and time period in question.
In the Coalescence Phase, the metadata that have been identified in the Scan Phase may be coalesced into fixed size allocation units. Coalescence of the metadata may be achieved in any of a variety of ways. According to one embodiment, the identified metadata may first be stored in memory in a time- ascending order according to their timestamps. Then, starting from the oldest metadata, the identified metadata may be inserted into a binary tree (B-tree) that is indexed by starting Logical Block Addresses (LBA' s) recorded in the metadata. The B-tree may be first scanned for LBA overlap before the coalesced metadata are inserted. The newer COW data containing LBA overlaps may be discarded. Splits may also be done on COW data where needed to achieve coalescence. For example, for a particular time interval, if metadata for Blocks 1-5 are already stored in the B-tree, then another metadata row associated with Blocks 3-8 may be split into two portions, one associated with Blocks 3-5 and the other associated with Blocks 6-8, where the former may be discarded ' while the latter may be entered into the B-tree. The resulting metadata may be coalesced into relatively large fixed sized allocation units (e.g., 512 KB), each allocation unit representing a single COW operation. Statistics kept as records may be coalesced and inserted into the B-tree. These statistics may be kept on an LU basis so that a determination can be made in the Copy Phase as to whether to actually copy the COW data into a rollup chunk or simply modify the corresponding (coalesced) metadata. The statistics kept may include, for example, the number of original blocks, the number of duplicate blocks (block savings) , the number of original COW operations, and the number of coalesced COW operations (metadata savings) .
Each resulting metadata row may be that of the earliest original operation in a particular slice. For example, if Block 128 was written twice in a row, once at time Tl and again at time 12, the resulting coalesced metadata may only reflect the write operation at time Tl. Once the metadata for a slice has been coalesced, the next slice may be processed for the same LU in the Scan Phase. This procedure continues until all slices for the LU have been processed, whereupon the Copy Phase may be executed.
In the Copy Phase, the coalesced metadata may be read from memory, and the COW data the coalesced metadata point to may be copied into rollup chunks. Whether or not to actually copy the COW data may depend on an evaluation of the statistics collected in the Coalescence Phase. General, an actual copy of the COW data is performed only when there is some saving of storage space. After the evaluation has passed and all of the metadata have been coalesced for an LU, the COW data may be copied into resulting rollup chunks on a slice by slice basis. The COW data may be copied from a time store (in the storage management system) to the same time store using pre-allocated non-replicated buffers. In order to accomplish the data copy, an event chain may be created and a RollupTimeStoreMove event may be pushed onto the event chain. The RollupTimeStoreMove object may be derived from an SGIO and a WaitableEvent object and may be handled by an IO execution context. The event may have two extents, one for the read of the original COW data and one for the write to the rollup chunk in the time store. The Copy Phase may wait for the event to complete and then update an in-memory array with a data structure representing a new indexing operation. This array may be used in the Replacement Phase to update the coalesced metadata. Once all of the COW data have been copied, the rollup thread may proceed to the Replacement Phase.
In the Replacement Phase, the relevant portion of old COW data may be replaced with the newly created rollup chunks, the corresponding metadata may be replaced or modified to reflect the new chunks and coalesced COW data contained therein, and the rollup state may be updated. The Replacement Phase is typically carried out atomically and may be rolled back should a catastrophic failure event occur. The LU whose metadata are being updated may be locked to keep configuration from changing and to prevent timeline deprecation from occurring during this phase. The old COW data coalesced in the previous phases may be freed, and the new rollup chunks may be added to the appropriate place in the timeline. The original metadata may be deleted and replaced by the new, coalesced metadata. Finally, the LU may be unlocked, and a next LU that meets the Determination Phase criteria may be processed.
According to one embodiment, the old COW data may be transformed into new rollup chunks without an actual copy taking place. The original data chunks may simply be updated to reflect the rollup timestamps, and their rollup level may be updated accordingly.
The rollup operation runs through a number of phases one of which involves copying COW data to newly rolled-up chunks, which may take a significant amount of time. As a result, other critical components of the system that interfere with rollups or change the state of the timeline, such as Instant Restore, Time Images, or Timeline Deprecation, may cause an in-progress rollup to be canceled. If a rollup is canceled during processing of a particular level, all other levels may¬ be cancelled as well. Therefore, in the state diagram shown in Figure 3, there is a Cancel route from almost every phase to End. The Replacement Phase may not be arbitrarily cancelled and may proceed while the LU in question is locked. To avoid excessive interruption of the rollups, the timeline compression process may be preferably scheduled to start when resources in the storage system and/or the storage management system are in low demand.
It may be desirable to track the state of rollups that have occurred on an LU by LU basis. This way, other components in the storage system can determine what backup data have been rolled up, and what LUs have not yet had their backup data rolled up. For example, the determination of a common timeline start across multiple LUs requires rollup state information associated with the LUs of interest. The state of rollups may also be needed for future rollups in order to determine where to start a rollup.
The rollup state may be stored in a database table in a global database called "rollup_state, " one example of which is shown in Table 1.
Table 1: Rollup State Table
Figure imgf000023_0001
Each entry in Table 1 may have a generation number that uniquely identifies the rollup level for each LU. The generation number may be updated whenever a rollup is completed for an LU.
In addition to rollup state on an LU, each LU entry in the global database may have a field describing the last rollup level for it. This may be used to determine the timeline for an LU within a rollup level.
There may be cases where multiple rollups for the same rollup level and LU may exist in a same rollup chunk. In order to return valid image times for this case, a history of rollups that have taken place may be kept. The start and end time ranges for each rollup may be stored in a table called "rollup_history, " one example of which is shown as Table 2.
Table 2: Rollup History Table.
Figure imgf000024_0001
This information may be used to determine valid image times for an LU and rollup level. Once a rollup level is rolled up (e.g. from Level-1 to Level-2) or a rollup level has been deprecated, the entry representing that particular rollup may be deleted.
Since an LU is typically related to or grouped with other LUs, the result of a rollup on one LU may affect how the timeline for a group of LUs is represented. When a timeline rollup' involves a group of LUs (e.g., in a dataset or quota group) , the start of a timeline for the group of LUs may be the earliest common timeline start (ECTS) among all the LUs. However, when there are multiple levels of rollup data, there may be points in time in the timeline that become invalid for the start of an image time. Figure 4 illustrates two different rollup levels across three related LUs. Each tick on the timelines may represent a data chunk in a time store. The start of the timeline for hourly data may be time t3 since it is the ECTS among the three LUs. In this example, valid image times are t3, t4, and t5 for the hourly data. The times tO, tl, and t2 can only be chosen through dissociation with the other related LUs. Since times t3, t4, and t5 are hourly buckets of backup data and are essentially single-point-in- time (SPIT) images, image times chosen in between these times may be invalid. The Level-0 data in this example runs from time t6 through a present time. Any Level-0 time between t6 and the present time may be valid image times.
When rollup levels among multiple LUs are inconsistent, the valid image times may differ from those when the rollup levels are consistent among the LUs. If, in the above example, Level-1 rollup is only completed for LU-I, then points t3 and t4 may not be valid image times. Figure 5 illustrates this scenario. Although the ECTS remains the same, t5 may be the only valid image time across all LUs for Level-1 data. Any image time between t6 and the present time may still be valid.
According to embodiments of the present disclosure, a few primitive application program interfaces (APIs) may be provided to represent a timeline that accommodates transient rollup inconsistencies. For example, primitive APIs may be provided to perform the following functions: (a) retrieve start and end of timeline for an LU across all rollup levels, wherein the start and end time range, as well as the generation number for the last rollup, may be returned for the LU; (b) retrieve start and end time of a timeline for an LU witnm each rollup level for an LU (e.g. start and end of Level-1 data for LU-I) , wherein the start and end time range, as well as the generation number for the last rollup, may be returned for Level-0, Level-1, Level-2 and Level-3 data; (c) retrieve the next and previous image times based on an input image time for an LU, wherein the start time before and the start time after the image time may be returned for each of the two times. Using these primitive APIs, a user or client program that has knowledge about the relationship among the LUs may query the information for each LU and determine the start and end of the timeline for each level.
In the exemplary timeline shown in Figure 4, the primitive APIs may be used to find the start and end of the Level-1 timeline for the related Lus as follows. (1) The ECTS may be found for the set of LUs based on what the latest timeline start is for the set of LUs, in this case time t3.
(2) The Level-1 data with earliest start time past the ECTS, in this case t5, may be the start of the Level-1 timeline.
(3) The Level-1 data with the latest end time past the ECTS, in this case t5, may be the end of the Level-1 timeline .
(4) All image times chosen between the start and end times may be validated by using API(c) above for each LU.
Finding the closest time before and after the image time may yield up to two valid data points for an image time. Similarly, the primitive APIs may be used to find the start of the Level-0 timeline for the related LUs in Figure 4. (1) The ECTS may be found for the set of LUs based on what the latest timeline start is for the set of LUs, in this case time t3.
(2) The Level-0 data with the earliest start time past the latest end time of the Level-1 data, in this case time t6, may be the start of the Level-0 timeline. (3) Any image time from this point forward may be valid for Level-0 data.
For a Time Image or Instant Restore operation, an image time may be chosen in a two-stage process wherein the image time is validated (or confirmed) by each storage device before the requested Time Image or Instant Restore operation takes place. In that two-stage process, there may be a window of opportunity for a rollup to change the timeline in such a way that makes a chosen image time invalid. To close this window, the validation phase in that two-stage process may cancel a currently running rollup and prevent other rollups from running. In addition, if a rollup is in a state that cannot be canceled, then the validation phase may complete in error to force a new query of the timeline. Configuration events in the validate phase for Time Image and Instant Restore may also pass in the rollup generation number queried when the timeline was queried. If the generation number has changed since the query, the validation phase may also complete in error to force a new query of the timeline.
In a storage system, each quota group may have an allocated timeline storage space for rollup purposes . According to one embodiment, for example, the amount of storage provisioned may be based on the following formula: (Maximum number of LUs in the storage system x Maximum number of rollup levels possible) + 100 working chunks for doing a rollup .
In order to have an active Level-1, Level-2, and Level-3 rollup chunk for each LU, and to have 100 chunks for performing the active rollup, approximately 20 GB of storage space may be allocated as rollup quota per quota group.
There may not be enough space to accommodate a Copy Phase for a given rollup. This situation may be detected using statistics generated in the Coalescence Phase, and the rollup for that rollup level may be cut short. The rollup state information may then be updated to reflect that the rollup has not yet completed and the next LU chosen by the determination phase may be the same LU, so that the rollup may resume.
Rollup chunks may be essentially transformed into new COW data in the Replacement Phase. The old data chunks may be freed as they are replaced. The rollup quota may be updated to reflect changes in the amount of space used. This guarantees that a rollup does not cause a deprecation of timeline and that there is space for at least 100 rollup chunks available at the start of any given rollup.
When a rollup thread is woken on a node due to a deprecation of timeline or a threshold of the timeline storage capacity being crossed, the rollup thread on other nodes may be woken as well, so that LUs belonging to the same dataset may be processed. The mechanism used to awaken the remote thread may be a simple spread message.
Starting a capture mode, adding LUs to a capturing dataset, and removing LUs from a capturing dataset all have the same effect on rollup chunks as these events have on normal time store data chunks . Every capturing LU may have an active rollup chunk for every level configured in the TLP. When an LU has capture mode turned on a rollup chunk may be activated for each level configured.
Timeline deprecation typically involves discarding older backup data in a timeline once the timeline storage is approaching its quota. If a deprecation of timeline is about to take place, any rollup currently running may be immediately cancelled. When the deprecation is completed, another rollup may be immediately scheduled.
Rolled-up data may typically be deprecated first in the timeline since they may be the oldest data in the timeline. One anomaly in terms of deprecation may be that it is possible for an active rollup chunk to be deprecated. Multiple rollup chunks may contain duplicate start times, much like data chunks copied back during an Instant Restore. The same deprecation rules apply to these rollup chunks as do the copy back chunks . Rollup chunks with duplicate start times may be all deprecated regardless of how much space is needed.
Time images may be short lived entities. As a result, they may be deleted when deprecation of timeline takes place. One goal of timeline compression may be to avoid this deprecation of timeline based on the premise that backup data at a higher level of granularity may be better than no data at all. This being the case, there may be two options:
1. Let rollups behave the same way as deprecation behaves and delete the time image when a rollup runs into a time image.
2. Stop rollups when encountering a time image. The danger being that deprecation may delete the time image anyway .
A global option may be set up by a user to control how rollups behave when encountering a time image. For example, any time image creation may cancel a running rollup.
An instant restore may cause the state of a timeline to change drastically and quickly. As a result, an active rollup may be immediately canceled when an instant restore is initiated.
Much like time images, user-defined timeline annotations may be invalidated when timeline is deprecated. The same holds true for rollups .
On failover, any running rollup may be cancelled. Leftover data for rollups that may have been in progress on a remote node may be cleaned up by a surviving node. Rollup chunks may be scrubbed the same way COW data may be scrubbed on failover.
Figure 6 outlines major objects involved in an exemplary program for timeline compression in accordance with embodiments of the present disclosure. A RollupManager object may be an interface for starting, canceling, maintaining synchronization, and querying state for rollups . In addition, it may be responsible for maintaining TLP objects. The RollupManager may contain an instance of a TimelineRollup object. The TimelineRollup object may be an active object responsible for performing all phases of a rollup. There may also be an object called RollupState which may be an interface for querying and setting state for rollups. It may maintain transient states related to the rollup process as well as the persistent states for LUs which may be stored in a global database. A RegionMaps/lndexing object may be responsible for building B-trees as described above. A tsAlloc object may allocate time store cache for rollup chunks . A tsQuotaGroup object may allocate timeline storage space for a dataset. A TimelineProfile object may record a TLP for a dataset.
At this point it should be noted that the technique for timeline compression in accordance with the present disclosure as described above typically involves the processing of input data and the generation of output data to some extent. This input data processing and output data generation may be implemented in hardware or software. For example, specific electronic components may be employed in a storage area network (SAN) or similar or related circuitry for implementing the functions associated with timeline compression in accordance with the present disclosure as described above. Alternatively, one or more processors operating in accordance with stored instructions may implement the functions associated with timeline compression in accordance with the present disclosure as described above. If such is the case, it is within the scope of the present disclosure that such instructions may be stored on one or more processor readable carriers (e.g., a magnetic disk), or transmitted to one or more processors via one or more signals.
The present disclosure is not to be limited in scope by the specific embodiments described herein. Indeed, other various embodiments of and modifications to the present disclosure, in addition to those described herein, will be apparent to those of ordinary skill in the art from the foregoing description and accompanying drawings. Thus, such other embodiments and modifications are intended to fall within the scope of the present disclosure. Further, although the present disclosure has been described herein in the context of a particular implementation in a particular environment for a particular purpose, those of ordinary skill in the art will recognize that its usefulness is not limited thereto and that the present disclosure may be beneficially implemented in any number of environments for any number of purposes. Accordingly, the claims set forth below should be construed in view of the full breadth and spirit of the present disclosure as described herein.

Claims

1. A method for timeline compression in a storage system, wherein digital content of the storage system is backed up to enable restoration of the digital content to one or more points in a timeline, the method comprising: selecting a time interval in the timeline; identifying one or more sets of backup data recorded for the selected time interval, wherein the identified one or more sets of backup data represent at least a portion of old data overwritten during the selected time interval; and discarding other backup data recorded for the selected time interval, thereby reducing a granularity level of the timeline in the selected time interval.
2. The method according to claim 1, wherein the digital content of the storage system is backed up through copy-on- write operations into a plurality of sets of copy-on-write data and corresponding metadata, and wherein the step of identifying further comprises identifying one or more sets of copy-on-write data and corresponding metadata recorded for the selected time interval.
3. The method according to claim 2, wherein a length of the time interval is selected based at least in part on a desired granularity level of the timeline.
4. The method according to claim 2, wherein the step of identifying further comprises: determining whether a storage unit in the storage system has been overwritten more than once during the selected time interval; if the storage unit has been overwritten once during the selected time interval causing a sole set of copy-on-write αata and corresponding metadata to be recorded, selecting the sole set; and if the storage unit has been overwritten more than once during the selected time interval causing multiple sets of copy-on-write data and corresponding metadata to be recorded, selecting one of the multiple sets.
5. The method according to claim 4, wherein, if the storage unit has been overwritten more than once during the selected time interval, the selected set of copy-on-write data and corresponding metadata is the earliest set recorded for the selected time interval.
6. The method according to claim 2, further comprising: coalescing metadata in the one or more identified sets of copy-on-write data and corresponding metadata.
7. The method according to claim 6, further comprising: identifying copy-on-write data that correspond to the coalesced metadata; and replacing all sets of copy-on-write data and corresponding metadata previously recorded for the selected time interval with a new set comprising the identified copy- on-write data and the coalesced metadata.
8. The method according to claim 2, further comprising: selecting multiple time intervals in a portion of the timeline based on a desired granularity level for the portion of the timeline; and repeating the steps of identifying and discarding for the selected multiple time intervals .
9. The method according to claim 2, wherein the storage system comprises a plurality of storage devices, the method further comprising: repeating the steps of identifying and discarding for one or more of the plurality of storage devices to cause the plurality of storage devices to have a consistent granularity level of the timeline with respect to one another.
10. The method according to claim 2, wherein the steps of selecting, identifying and discarding are triggered when one or more of the following conditions are met: a predetermined storage capacity for the timeline has been consumed; a predetermined amount of data have been accumulated for a granularity level of the timeline; granularity levels of the timeline for at least two storage devices in the storage system are inconsistent; an instruction to reduce the granularity of the timeline is received; and a scheduled time for reducing the granularity of the timeline is reached.
11. The method according to claim 2, further comprising: scanning the storage system for a storage device for which the granularity of the timeline can be reduced.
12. At least one signal embodied in at least one carrier wave for transmitting a computer program of instructions configured to be readable by at least one processor for instructing the at least one processor to execute a computer process for performing the method as recited in claim 1.
13. At least one processor readable carrier for storing a computer program of instructions configured to be readable by at least one processor for instructing the at least one processor to execute a computer process for performing the method as recited in claim 1.
14. A system for timeline compression in a storage system, wherein digital content of the storage system is backed up to enable restoration of the digital content to one or more points in a timeline, the system comprising: means for selecting a time interval in the timeline; means for identifying one or more sets of backup data recorded for the selected time interval, wherein the identified one or more sets of backup data represent at least a portion of old data overwritten during the selected time interval; and means for discarding other backup data recorded for the selected time interval, thereby reducing a granularity level of the timeline in the selected time interval.
15. A system for timeline compression in a storage system, wherein digital content of the storage system is backed up to enable restoration of the digital content to one or more points in a timeline, the system comprising: a storage medium for storing instructions; and ' at least one processor for: selecting a time interval in the timeline; identifying one or more sets of backup data recorded for the selected time interval, wherein the identified one or more sets of backup data represent at least a portion of old data overwritten during the selected time interval; and discarding other backup data recorded for the selected time interval, thereby reducing a granularity level of the timeline in the selected time interval.
PCT/US2006/039857 2005-10-14 2006-10-13 Technique for timeline compression in a data store WO2007047346A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP06816785.7A EP1952236B1 (en) 2005-10-14 2006-10-13 Technique for timeline compression in a data store

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US72618705P 2005-10-14 2005-10-14
US60/726,187 2005-10-14

Publications (2)

Publication Number Publication Date
WO2007047346A2 true WO2007047346A2 (en) 2007-04-26
WO2007047346A3 WO2007047346A3 (en) 2007-09-07

Family

ID=37963075

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2006/039857 WO2007047346A2 (en) 2005-10-14 2006-10-13 Technique for timeline compression in a data store

Country Status (4)

Country Link
US (1) US7536583B2 (en)
EP (1) EP1952236B1 (en)
CN (2) CN103927238B (en)
WO (1) WO2007047346A2 (en)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007131190A2 (en) 2006-05-05 2007-11-15 Hybir Inc. Group based complete and incremental computer file backup system, process and apparatus
US8943281B1 (en) * 2008-02-19 2015-01-27 Symantec Corporation Method and apparatus for optimizing a backup chain using synthetic backups
US8452736B2 (en) 2008-03-05 2013-05-28 Ca, Inc. File change detection
US8214332B2 (en) * 2009-06-08 2012-07-03 International Business Machines Corporation Data retention using logical objects
KR20100134433A (en) * 2009-06-15 2010-12-23 엘지전자 주식회사 Mobile terminal with function control module and the method thereof
US8423088B2 (en) * 2009-07-22 2013-04-16 Microsoft Corporation Aggregated, interactive communication timeline
US9581976B2 (en) * 2012-11-05 2017-02-28 Schweitzer Engineering Laboratories, Inc. Recording of operating parameters of an intelligent electronic device
US9542423B2 (en) * 2012-12-31 2017-01-10 Apple Inc. Backup user interface
US9805052B2 (en) * 2013-01-28 2017-10-31 Netapp, Inc. Coalescing metadata for mirroring to a remote storage node in a cluster storage system
US9785510B1 (en) 2014-05-09 2017-10-10 Amazon Technologies, Inc. Variable data replication for storage implementing data backup
CN105224546B (en) * 2014-06-04 2020-10-30 创新先进技术有限公司 Data storage and query method and equipment
US20170024140A1 (en) * 2015-07-20 2017-01-26 Samsung Electronics Co., Ltd. Storage system and method for metadata management in non-volatile memory
US10007352B2 (en) 2015-08-21 2018-06-26 Microsoft Technology Licensing, Llc Holographic display system with undo functionality
US10423493B1 (en) * 2015-12-21 2019-09-24 Amazon Technologies, Inc. Scalable log-based continuous data protection for distributed databases
US20180336339A1 (en) * 2016-06-25 2018-11-22 Huawei Technologies Co., Ltd. Method And Apparatus For Generating Password By Means of Press Touch
CN106407295A (en) * 2016-08-31 2017-02-15 成都九华圆通科技发展有限公司 Method for storing data of grid monitoring system based on radio stations
US10270859B2 (en) 2016-10-17 2019-04-23 Schweitzer Engineering Laboratories, Inc. Systems and methods for system-wide digital process bus fault recording
US11269731B1 (en) 2017-11-22 2022-03-08 Amazon Technologies, Inc. Continuous data protection
WO2020055902A1 (en) * 2018-09-10 2020-03-19 Aveva Software, Llc System and server for best-fit data storage
US11599559B2 (en) * 2019-04-19 2023-03-07 EMC IP Holding Company LLC Cloud image replication of client devices
CN110658395A (en) * 2019-07-08 2020-01-07 南京铁道职业技术学院 Subway train traction inverter test system and method
CN110780100B (en) * 2019-09-24 2020-09-22 北京航空航天大学 Oscilloscope automatic setting method based on frequency rapid measurement algorithm

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6023710A (en) 1997-12-23 2000-02-08 Microsoft Corporation System and method for long-term administration of archival storage
US20010034737A1 (en) 2000-01-10 2001-10-25 Cane David A. Administration of a differential backup system in a client-server environment
US6513065B1 (en) 1999-03-04 2003-01-28 Bmc Software, Inc. Enterprise management system and method which includes summarization having a plurality of levels of varying granularity
US6625623B1 (en) 1999-12-16 2003-09-23 Livevault Corporation Systems and methods for backing up data files
EP1522926A2 (en) 2003-09-30 2005-04-13 Live Vault Corporation Systems and methods for backing up data files

Family Cites Families (157)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3444528A (en) 1966-11-17 1969-05-13 Martin Marietta Corp Redundant computer systems
US3533082A (en) 1968-01-15 1970-10-06 Ibm Instruction retry apparatus including means for restoring the original contents of altered source operands
US3715729A (en) 1971-03-10 1973-02-06 Ibm Timing control for a multiprocessor system
GB1509193A (en) 1974-04-17 1978-05-04 Nat Res Dev Computer systems
US4228496A (en) 1976-09-07 1980-10-14 Tandem Computers Incorporated Multiprocessor system
US4156907A (en) 1977-03-02 1979-05-29 Burroughs Corporation Data communications subsystem
US4191996A (en) 1977-07-22 1980-03-04 Chesley Gilman D Self-configurable computer and memory system
US4141066A (en) 1977-09-13 1979-02-20 Honeywell Inc. Process control system with backup process controller
US4351023A (en) 1980-04-11 1982-09-21 The Foxboro Company Process control system with improved system security features
US4403303A (en) 1981-05-15 1983-09-06 Beehive International Terminal configuration manager
ATE25779T1 (en) 1981-10-01 1987-03-15 Stratus Computer Inc DIGITAL DATA PROCESSING SYSTEM WITH RELIABILITY BUS PROTOCOL.
US4486826A (en) 1981-10-01 1984-12-04 Stratus Computer, Inc. Computer peripheral control apparatus
US4459658A (en) 1982-02-26 1984-07-10 Bell Telephone Laboratories Incorporated Technique for enabling operation of a computer system with a consistent state of a linked list data structure after a main memory failure
DE3215177A1 (en) 1982-04-23 1983-10-27 Hartmann & Braun Ag, 6000 Frankfurt MONITORING SYSTEM FOR ONE OR MULTIPLE, SIMILAR DESIGN PROCESS STATIONS
US4483001A (en) 1982-06-16 1984-11-13 International Business Machines Corporation Online realignment of memory faults
US4479214A (en) 1982-06-16 1984-10-23 International Business Machines Corporation System for updating error map of fault tolerant memory
US4498145A (en) 1982-06-30 1985-02-05 International Business Machines Corporation Method for assuring atomicity of multi-row update operations in a database system
US4507751A (en) 1982-06-21 1985-03-26 International Business Machines Corporation Method and apparatus for logging journal data using a log write ahead data set
US4648031A (en) 1982-06-21 1987-03-03 International Business Machines Corporation Method and apparatus for restarting a computing system
US4521847A (en) 1982-09-21 1985-06-04 Xerox Corporation Control system job recovery after a malfunction
JPS5960667A (en) 1982-09-30 1984-04-06 Hitachi Ltd Discriminating method of magnetic tape journal
WO1984002409A1 (en) 1982-12-09 1984-06-21 Sequoia Systems Inc Memory backup system
US4819154A (en) 1982-12-09 1989-04-04 Sequoia Systems, Inc. Memory back up system with one cache memory and two physically separated main memories
JPH0670880B2 (en) 1983-01-21 1994-09-07 株式会社日立マイコンシステム Semiconductor memory device
US4639856A (en) 1983-11-04 1987-01-27 International Business Machines Corporation Dual stream processor apparatus
US4607365A (en) 1983-11-14 1986-08-19 Tandem Computers Incorporated Fault-tolerant communications controller system
US4608688A (en) 1983-12-27 1986-08-26 At&T Bell Laboratories Processing system tolerant of loss of access to secondary storage
US4959774A (en) 1984-07-06 1990-09-25 Ampex Corporation Shadow memory system for storing variable backup blocks in consecutive time periods
US4674038A (en) 1984-12-28 1987-06-16 International Business Machines Corporation Recovery of guest virtual machines after failure of a host real machine
US4754397A (en) 1985-02-15 1988-06-28 Tandem Computers Incorporated Fault tolerant modular subsystems for computers
US4703481A (en) 1985-08-16 1987-10-27 Hewlett-Packard Company Method and apparatus for fault recovery within a computing system
US4814971A (en) 1985-09-11 1989-03-21 Texas Instruments Incorporated Virtual memory recovery system using persistent roots for selective garbage collection and sibling page timestamping for defining checkpoint state
US4713811A (en) 1985-11-07 1987-12-15 Tytronix Corporation Automatic mode switching unit for a serial communications data system
US4736339A (en) 1985-12-16 1988-04-05 Gte Communication Systems Corporation Circuit for simplex I/O terminal control by duplex processors
US4703421A (en) 1986-01-03 1987-10-27 Gte Communication Systems Corporation Ready line synchronization circuit for use in a duplicated computer system
US4878167A (en) 1986-06-30 1989-10-31 International Business Machines Corporation Method for managing reuse of hard log space by mapping log data during state changes and discarding the log data
US5089958A (en) 1989-01-23 1992-02-18 Vortex Systems, Inc. Fault tolerant computer backup system
DE69032614T2 (en) 1989-11-03 1999-04-15 Compaq Computer Corp Data distribution method in a disk array
JP2772103B2 (en) 1990-03-28 1998-07-02 株式会社東芝 Computer system startup method
US5201044A (en) 1990-04-16 1993-04-06 International Business Machines Corporation Data processing method for file status recovery includes providing a log file of atomic transactions that may span both volatile and non volatile memory
US5479654A (en) 1990-04-26 1995-12-26 Squibb Data Systems, Inc. Apparatus and method for reconstructing a file from a difference signature and an original file
EP0465018B1 (en) 1990-06-29 1997-05-14 Oracle Corporation Method and apparatus for optimizing undo log usage
US5544347A (en) 1990-09-24 1996-08-06 Emc Corporation Data storage system controlled remote data mirroring with respectively maintained data indices
US5212784A (en) 1990-10-22 1993-05-18 Delphi Data, A Division Of Sparks Industries, Inc. Automated concurrent data backup system
US5255270A (en) 1990-11-07 1993-10-19 Emc Corporation Method of assuring data write integrity on a data storage device
JP2603757B2 (en) 1990-11-30 1997-04-23 富士通株式会社 Method of controlling array disk device
US5235601A (en) 1990-12-21 1993-08-10 Array Technology Corporation On-line restoration of redundancy information in a redundant array system
JP2993528B2 (en) 1991-05-18 1999-12-20 富士通株式会社 Text management and restoration method
EP0516900B1 (en) 1991-06-04 1996-05-01 International Business Machines Corporation Data backup and recovery in a data processing system
US5764877A (en) 1991-06-25 1998-06-09 Digital Equipment Corporation Media recovery with time-split B-trees
US5287501A (en) 1991-07-11 1994-02-15 Digital Equipment Corporation Multilevel transaction recovery in a database system which loss parent transaction undo operation upon commit of child transaction
US5325519A (en) 1991-10-18 1994-06-28 Texas Microsystems, Inc. Fault tolerant computer with archival rollback capabilities
US5280611A (en) 1991-11-08 1994-01-18 International Business Machines Corporation Method for managing database recovery from failure of a shared store in a system including a plurality of transaction-based systems of the write-ahead logging type
US5369758A (en) 1991-11-15 1994-11-29 Fujitsu Limited Checking for proper locations of storage devices in a storage array
US5802264A (en) 1991-11-15 1998-09-01 Fujitsu Limited Background data reconstruction in a storage device array system
US5297258A (en) 1991-11-21 1994-03-22 Ast Research, Inc. Data logging for hard disk data storage systems
US5450546A (en) 1992-01-31 1995-09-12 Adaptec, Inc. Intelligent hardware for automatically controlling buffer memory storage space in a disk drive
US5339406A (en) 1992-04-03 1994-08-16 Sun Microsystems, Inc. Reconstructing symbol definitions of a dynamically configurable operating system defined at the time of a system crash
US5241670A (en) 1992-04-20 1993-08-31 International Business Machines Corporation Method and system for automated backup copy ordering in a time zero backup copy session
US5331646A (en) 1992-05-08 1994-07-19 Compaq Computer Corporation Error correcting code technique for improving reliablility of a disk array
JPH05341918A (en) 1992-05-12 1993-12-24 Internatl Business Mach Corp <Ibm> Connector for constituting duplex disk storage device system
JPH0643604A (en) * 1992-07-25 1994-02-18 Konica Corp Method for processing silver halide photographic sensitive material
US5404361A (en) 1992-07-27 1995-04-04 Storage Technology Corporation Method and apparatus for ensuring data integrity in a dynamically mapped data storage subsystem
JPH06101539A (en) * 1992-09-18 1994-04-12 Nissan Motor Co Ltd Device for processing evaporative fuel of engine
US5497483A (en) * 1992-09-23 1996-03-05 International Business Machines Corporation Method and system for track transfer control during concurrent copy operations in a data processing storage subsystem
US5375232A (en) * 1992-09-23 1994-12-20 International Business Machines Corporation Method and system for asynchronous pre-staging of backup copies in a data processing storage subsystem
US5530855A (en) 1992-10-13 1996-06-25 International Business Machines Corporation Replicating a database by the sequential application of hierarchically sorted log records
US5483468A (en) 1992-10-23 1996-01-09 International Business Machines Corporation System and method for concurrent recording and displaying of system performance data
US5404508A (en) 1992-12-03 1995-04-04 Unisys Corporation Data base backup and recovery system and method
US5487160A (en) 1992-12-04 1996-01-23 At&T Global Information Solutions Company Concurrent image backup for disk storage system
US5469573A (en) 1993-02-26 1995-11-21 Sytron Corporation Disk operating system backup and recovery system
US5557770A (en) 1993-03-24 1996-09-17 International Business Machines Corporation Disk storage apparatus and method for converting random writes to sequential writes while retaining physical clustering on disk
US5659747A (en) 1993-04-22 1997-08-19 Microsoft Corporation Multiple level undo/redo mechanism
US5809340A (en) 1993-04-30 1998-09-15 Packard Bell Nec Adaptively generating timing signals for access to various memory devices based on stored profiles
US5440735A (en) 1993-10-08 1995-08-08 International Business Machines Corporation Simplified relational data base snapshot copying
GB9323453D0 (en) * 1993-11-13 1994-01-05 Calluna Tech Ltd Security system for portable hard disk drive
US5454039A (en) 1993-12-06 1995-09-26 International Business Machines Corporation Software-efficient pseudorandom function and the use thereof for encryption
US5530846A (en) 1993-12-29 1996-06-25 International Business Machines Corporation System for decoupling clock amortization from clock synchronization
JP2846837B2 (en) 1994-05-11 1999-01-13 インターナショナル・ビジネス・マシーンズ・コーポレイション Software-controlled data processing method for early detection of faults
US5638509A (en) 1994-06-10 1997-06-10 Exabyte Corporation Data storage and protection system
WO1995034860A1 (en) 1994-06-10 1995-12-21 Sequoia Systems, Inc. Main memory system and checkpointing protocol for fault-tolerant computer system
US5729719A (en) 1994-09-07 1998-03-17 Adaptec, Inc. Synchronization circuit for clocked signals of similar frequencies
US5535188A (en) 1994-10-03 1996-07-09 International Business Machines Corporation Data security protection for information recorded on a rewritable storage medium using a write-once read-many storage medium
US5649152A (en) 1994-10-13 1997-07-15 Vinca Corporation Method and system for providing a static snapshot of data stored on a mass storage system
US5634096A (en) 1994-10-31 1997-05-27 International Business Machines Corporation Using virtual disks for disk system checkpointing
US5623598A (en) 1994-11-22 1997-04-22 Hewlett-Packard Company Method for identifying ways to improve performance in computer data storage systems
US5590274A (en) * 1995-01-23 1996-12-31 Tandem Computers Incorporated Multi-volume audit trails for fault tolerant computers
US5740433A (en) 1995-01-24 1998-04-14 Tandem Computers, Inc. Remote duplicate database facility with improved throughput and fault tolerance
US5604862A (en) 1995-03-14 1997-02-18 Network Integrity, Inc. Continuously-snapshotted protection of computer files
US5799141A (en) 1995-06-09 1998-08-25 Qualix Group, Inc. Real-time data protection system and method
US5758057A (en) 1995-06-21 1998-05-26 Mitsubishi Denki Kabushiki Kaisha Multi-media storage system
US5715438A (en) 1995-07-19 1998-02-03 International Business Machines Corporation System and method for providing time base adjustment
WO1997008623A1 (en) 1995-08-23 1997-03-06 Symantec Corporation Coherent file system access during defragmentation operations on a storage media
US5740397A (en) 1995-10-11 1998-04-14 Arco Computer Products, Inc. IDE disk drive adapter for computer backup and fault tolerance
US5745906A (en) 1995-11-14 1998-04-28 Deltatech Research, Inc. Method and apparatus for merging delta streams to reconstruct a computer file
US5729743A (en) * 1995-11-17 1998-03-17 Deltatech Research, Inc. Computer apparatus and method for merging system deltas
US5751939A (en) 1995-11-29 1998-05-12 Texas Micro, Inc. Main memory system and checkpointing protocol for fault-tolerant computer system using an exclusive-or memory
US5864657A (en) * 1995-11-29 1999-01-26 Texas Micro, Inc. Main memory system and checkpointing protocol for fault-tolerant computer system
US5790773A (en) 1995-12-29 1998-08-04 Symbios, Inc. Method and apparatus for generating snapshot copies for data backup in a raid subsystem
US5777874A (en) 1996-02-12 1998-07-07 Allen-Bradley Company, Inc. Programmable controller backup system
US5724501A (en) 1996-03-29 1998-03-03 Emc Corporation Quick recovery of write cache in a fault tolerant I/O system
US5778392A (en) 1996-04-01 1998-07-07 Symantec Corporation Opportunistic tile-pulling, vacancy-filling method and apparatus for file-structure reorganization
US6044444A (en) * 1996-05-28 2000-03-28 Emc Corporation Remote data mirroring having preselection of automatic recovery or intervention required when a disruption is detected
US5857208A (en) * 1996-05-31 1999-01-05 Emc Corporation Method and apparatus for performing point in time backup operation in a computer system
US5893140A (en) * 1996-08-14 1999-04-06 Emc Corporation File server having a file system cache and protocol for truly safe asynchronous writes
US6347365B1 (en) * 1996-08-23 2002-02-12 Emc Corporation Data storage system having a[n] memory responsive to clock pulses produced on a bus and clock pulses produced by an internal clock
JPH1153235A (en) * 1997-08-08 1999-02-26 Toshiba Corp Data updating method of disk storage device and disk storage control system
US6016553A (en) * 1997-09-05 2000-01-18 Wild File, Inc. Method, software and apparatus for saving, using and recovering data
US6014690A (en) * 1997-10-24 2000-01-11 Digital Equipment Corporation Employing multiple channels for deadlock avoidance in a cache coherency protocol
WO1999022307A1 (en) * 1997-10-27 1999-05-06 Mitsubishi Denki Kabushiki Kaisha Data interface and high-speed communication system using the same
JP4363676B2 (en) * 1997-10-31 2009-11-11 株式会社東芝 Computer system
US6035306A (en) * 1997-11-24 2000-03-07 Terascape Software Inc. Method for improving performance of large databases
US6018746A (en) * 1997-12-23 2000-01-25 Unisys Corporation System and method for managing recovery information in a transaction processing system
US6205527B1 (en) * 1998-02-24 2001-03-20 Adaptec, Inc. Intelligent backup and restoring system and method for implementing the same
US6374363B1 (en) * 1998-02-24 2002-04-16 Adaptec, Inc. Method for generating a footprint image file for an intelligent backup and restoring system
US6532535B1 (en) * 1998-02-24 2003-03-11 Adaptec, Inc. Method for managing primary and secondary storage devices in an intelligent backup and restoring system
US6363487B1 (en) * 1998-03-16 2002-03-26 Roxio, Inc. Apparatus and method of creating a firewall data protection
US6054987A (en) * 1998-05-29 2000-04-25 Hewlett-Packard Company Method of dynamically creating nodal views of a managed network
US6369820B1 (en) * 1998-06-02 2002-04-09 International Business Machines Corporation Method and system for graphically displaying trend and range data for a variety of systems
US6366987B1 (en) * 1998-08-13 2002-04-02 Emc Corporation Computer data storage physical backup and logical restore
US6381635B1 (en) * 1998-11-19 2002-04-30 Ncr Corporation Method for displaying multiple performance measurements of a web site using a platform independent program
US6542975B1 (en) * 1998-12-24 2003-04-01 Roxio, Inc. Method and system for backing up data over a plurality of volumes
US6920537B2 (en) * 1998-12-31 2005-07-19 Emc Corporation Apparatus and methods for copying, backing up and restoring logical objects in a computer storage system by transferring blocks out of order or in parallel
US6553392B1 (en) * 1999-02-04 2003-04-22 Hewlett-Packard Development Company, L.P. System and method for purging database update image files after completion of associated transactions
US6345346B1 (en) * 1999-02-26 2002-02-05 Voom Technologies Substantially instantaneous storage restoration for non-computer forensics applications
US6505248B1 (en) * 1999-03-24 2003-01-07 Gte Data Services Incorporated Method and system for monitoring and dynamically reporting a status of a remote server
AU5424600A (en) * 1999-06-28 2001-01-31 Shashikant Prabhudas Kurani Antiseptic and antimicrobial pharmaceutical preparation of feracrylum
US20020049883A1 (en) * 1999-11-29 2002-04-25 Eric Schneider System and method for restoring a computer system after a failure
US6549992B1 (en) * 1999-12-02 2003-04-15 Emc Corporation Computer data storage backup with tape overflow control of disk caching of backup data stream
US6535967B1 (en) * 2000-01-19 2003-03-18 Storage Technology Corporation Method and apparatus for transferring data between a primary storage system and a secondary storage system using a bridge volume
US6704730B2 (en) * 2000-02-18 2004-03-09 Avamar Technologies, Inc. Hash file system and method for use in a commonality factoring system
US6539402B1 (en) * 2000-02-22 2003-03-25 Unisys Corporation Using periodic spaces of block ID to improve additional recovery
JP3868708B2 (en) * 2000-04-19 2007-01-17 株式会社日立製作所 Snapshot management method and computer system
US20020010872A1 (en) * 2000-05-31 2002-01-24 Van Doren Stephen R. Multi-agent synchronized initialization of a clock forwarded interconnect based computer system
US6711572B2 (en) * 2000-06-14 2004-03-23 Xosoft Inc. File system for distributing content in a data network and related methods
US6701456B1 (en) * 2000-08-29 2004-03-02 Voom Technologies, Inc. Computer system and method for maintaining an audit record for data restoration
US6711693B1 (en) * 2000-08-31 2004-03-23 Hewlett-Packard Development Company, L.P. Method for synchronizing plurality of time of year clocks in partitioned plurality of processors where each partition having a microprocessor configured as a multiprocessor backplane manager
US6687322B1 (en) * 2000-10-06 2004-02-03 Adaptec, Inc. Dual mode clock alignment and distribution device
US6691245B1 (en) * 2000-10-10 2004-02-10 Lsi Logic Corporation Data storage with host-initiated synchronization and fail-over of remote mirror
US6928607B2 (en) * 2000-10-19 2005-08-09 Oracle International Corporation Data integrity verification mechanism
US6557089B1 (en) * 2000-11-28 2003-04-29 International Business Machines Corporation Backup by ID-suppressed instant virtual copy then physical backup copy with ID reintroduced
US7027051B2 (en) * 2001-06-29 2006-04-11 International Business Machines Corporation Graphical user interface for visualization of sampled data compared to entitled or reference levels
GB0116686D0 (en) * 2001-07-07 2001-08-29 Hewlett Packard Co Data backup
US20030018657A1 (en) * 2001-07-18 2003-01-23 Imation Corp. Backup of data on a network
US6996668B2 (en) * 2001-08-06 2006-02-07 Seagate Technology Llc Synchronized mirrored data in a data storage device
US7043651B2 (en) * 2001-09-18 2006-05-09 Nortel Networks Limited Technique for synchronizing clocks in a network
JP2003108420A (en) * 2001-09-27 2003-04-11 Hitachi Ltd Data storage system and method of controlling the system
US20030220949A1 (en) * 2002-01-22 2003-11-27 Columbia Data Products, Inc. Automatic deletion in data storage management
US6728898B2 (en) * 2002-03-06 2004-04-27 Marathon Technologies Corporation Producing a mirrored copy using incremental-divergence
US6907505B2 (en) * 2002-07-31 2005-06-14 Hewlett-Packard Development Company, L.P. Immediately available, statically allocated, full-logical-unit copy with a transient, snapshot-copy-like intermediate stage
US6957362B2 (en) * 2002-08-06 2005-10-18 Emc Corporation Instantaneous restoration of a production copy from a snapshot copy in a data storage system
US6975963B2 (en) * 2002-09-30 2005-12-13 Mcdata Corporation Method and system for storing and reporting network performance metrics using histograms
US6981114B1 (en) * 2002-10-16 2005-12-27 Veritas Operating Corporation Snapshot reconstruction from an existing snapshot and one or more modification logs
US6983352B2 (en) * 2003-06-19 2006-01-03 International Business Machines Corporation System and method for point in time backups
US7577806B2 (en) * 2003-09-23 2009-08-18 Symantec Operating Corporation Systems and methods for time dependent data storage and recovery
US7353241B2 (en) * 2004-03-24 2008-04-01 Microsoft Corporation Method, medium and system for recovering data using a timeline-based computing environment
KR20060023392A (en) * 2004-09-09 2006-03-14 삼성전자주식회사 Manufacturing method of three dimensional image display and assembling apparatus for the same

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6023710A (en) 1997-12-23 2000-02-08 Microsoft Corporation System and method for long-term administration of archival storage
US6513065B1 (en) 1999-03-04 2003-01-28 Bmc Software, Inc. Enterprise management system and method which includes summarization having a plurality of levels of varying granularity
US6625623B1 (en) 1999-12-16 2003-09-23 Livevault Corporation Systems and methods for backing up data files
US20010034737A1 (en) 2000-01-10 2001-10-25 Cane David A. Administration of a differential backup system in a client-server environment
EP1522926A2 (en) 2003-09-30 2005-04-13 Live Vault Corporation Systems and methods for backing up data files

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP1952236A4

Also Published As

Publication number Publication date
CN101313279A (en) 2008-11-26
EP1952236A4 (en) 2009-04-01
US20070088973A1 (en) 2007-04-19
EP1952236B1 (en) 2017-06-14
WO2007047346A3 (en) 2007-09-07
CN103927238A (en) 2014-07-16
CN103927238B (en) 2017-04-12
US7536583B2 (en) 2009-05-19
EP1952236A2 (en) 2008-08-06

Similar Documents

Publication Publication Date Title
US7536583B2 (en) Technique for timeline compression in a data store
US7237080B2 (en) Persistent snapshot management system
US7237075B2 (en) Persistent snapshot methods
US7162601B2 (en) Method and apparatus for backup and recovery system using storage based journaling
US8145603B2 (en) Method and apparatus for data recovery using storage based journaling
US6839819B2 (en) Data management appliance
US7398422B2 (en) Method and apparatus for data recovery system using storage based journaling
US7756831B1 (en) Cooperative locking between multiple independent owners of data space
US7966354B2 (en) Method and computer for supporting construction of backup configuration
US7849257B1 (en) Method and apparatus for storing and retrieving data
US8533158B1 (en) Reclaiming data space by rewriting metadata
US7610320B2 (en) Technique for remapping data in a storage management system
US8862639B1 (en) Locking allocated data space
US9454536B1 (en) Space compaction and defragmentation mechanisms in data space

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200680043342.5

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

REEP Request for entry into the european phase

Ref document number: 2006816785

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2006816785

Country of ref document: EP