Optimizing recovery time objective and cost for cloud-based recovery

Abstract

The invention relates to optimizing recovery time objective and cost for cloud-based recovery. Disaster recovery operations are disclosed. A copy of data can include segments and a delta log or journal. RTO can be reduced by pre-processing the delta log after uploading the segments and the delta log. RTO is improved since the delta log no longer needs to be processed during recovery. By using a graph to apply the delta log, cost and RTO can be reduced.

Description

Technical Field

[0001] The embodiments of the present invention generally relate to data protection and data protection operations. More specifically, at least some embodiments of the present invention relate to systems, hardware, software, computer-readable media, and methods for data protection operations including backup operations, replication operations, and disaster recovery operations. Background Technology

[0002] Data protection is a critical aspect of modern computing systems. Failure to protect data can have catastrophic consequences. Unsurprisingly, most entities ensure their data is protected. However, some data protection schemes are better than others. For example, the ability to recover from a disaster can be measured by the time required to recover the data. RTO (Recovery Time Objective) is an important metric for data protection systems.

[0003] At the same time, the cost of data protection systems often needs to be considered. For example, systems offering extremely low RTO may incur unacceptable costs. Storing backups in the cloud, for instance, can generate costs in a variety of different ways. These costs typically stem from storage, CPU, processor cores, and other factors.

[0004] One of the problems leading to higher costs is the fact that data is often stored unnecessarily. Furthermore, when data is needed, there are costs associated with processing data that isn't necessarily required. There is a need to reduce the workload and data transfers associated with data protection operations (such as recovery operations) and to lower costs while still maintaining an acceptable RTO. Attached Figure Description

[0005] To describe how at least some of the advantages and features of the present invention can be obtained, embodiments of the invention will be described more specifically with reference to the specific embodiments of the invention shown in the accompanying drawings. It should be understood that these drawings depict only typical embodiments of the invention and are therefore not intended to be considered as limiting the scope of the invention. Embodiments of the invention will be described and explained with additional features and details using the drawings, in which:

[0006] Figure 1 An example of a computing environment in which embodiments of the present invention are implemented is shown;

[0007] Figure 2 An example of a backup is shown, which may include fragments and a delta journal;

[0008] Figure 3 An example of a method for processing backups after they have been stored in the cloud is shown;

[0009] Figure 4Examples of fragment and differential logs and their relationships are shown;

[0010] Figure 5 An example of splitting the differential log into offset or sub-differential logs is shown;

[0011] Figure 6 An example of processing differential logs to associate chunks with fragments is shown;

[0012] Figure 7 This illustrates the relationship between fragments and differential logs after the differential logs have been processed and are ready to be applied to the fragments;

[0013] Figure 8 An example of a chart is shown;

[0014] Figure 9 An example of applying differential logging to fragments is shown, illustrating a graphical representation based on fragments and differential logs; and

[0015] Figure 10 An example chart is shown, which is divided into sub-charts, each of which can be treated as a separate chart. Detailed Implementation

[0016] The embodiments of the present invention generally relate to data protection and data protection operations. More specifically, at least some embodiments of the present invention relate to systems, hardware, software, computer-readable media, and methods for data protection operations such as backup operations, replication operations, recovery operations including disaster recovery operations, cost optimization operations, snapshot operations, log operations, merging operations, and combinations thereof.

[0017] Data protection can be provided for a variety of computing systems, including those with virtual machines and those using virtualization in data centers. RTO is typically used to describe recovery time, and it is desirable to keep RTO as short as possible. Generally, RTO is the maximum acceptable amount of time to repair a virtual machine or application and regain data access after an unexpected outage.

[0018] In data protection services such as DRaaS (Disaster Recovery as a Service or Cloud Object Storage Disaster Recovery), recovery is performed to restore the backup to the target VM. During recovery, the repair VM creates the target VM and provides it with disks of appropriate size. The repair VM then downloads all complete fragments sequentially and writes these fragments to the relevant disks. The differential log is then downloaded and written to the target VM's disk. Writing the differential log may overwrite data previously written when fragments were written to disk. Embodiments of the present invention advantageously eliminate this aspect of the recovery operation.

[0019] Embodiments of this invention relate to protecting virtual machines and replicating virtual machines to the cloud (e.g., Amazon S3). Embodiments of this invention also relate to disaster recovery in the cloud. By way of example and not limitation, embodiments of this invention can be implemented as DRaaS or in VMC (VMware Cloud in AWS) or Dell CloudDR.

[0020] Data can be protected using either replication or snapshot operations. One example of replication is vSphere Replication, which uses a protocol called LWD (Light Weight Delta) to replicate a point-in-time image of the disk without using a full snapshot. When an LWD snapshot is generated, the snapshot data is transferred to a component called SDM (Snapshot Data Mover), which exists both on-premises and in the cloud. The on-premises SDM sends the data to the cloud-based SDM, which stores the data in object storage (such as S3) and creates descriptor files that describe the copy.

[0021] Embodiments of this invention can be implemented or incorporated into LWD replication. SDM and / or other components are an example of a (virtual or physical) data protection device.

[0022] The following discussion involves fragments or data blocks. A fragment can refer to data of a fixed size. A block can refer to data that is not necessarily of a fixed size.

[0023] When a snapshot (e.g., an LWD snapshot) is generated, the device receives data fragments and then receives an differential log containing data blocks. For example, the differential log typically represents the IO (write IO) logs that arrive during data protection operations (e.g., backup to the cloud, replication to the cloud, etc.). To perform or prepare for a recovery operation, the device (e.g., an SDM in the cloud) processes the data (data fragments) sent in the first phase and then processes the log (e.g., the differential log), which contains blocks. This process complicates the recovery process, increases latency, and increases the RTO (Recovery Time Objective) of the protected VM.

[0024] Embodiments of this invention relate to the efficient merging of differential logs with device data or fragments during protection operations. This reduces the amount of processing and data transfer required during recovery operations and reduces RTO.

[0025] Embodiments of the present invention perform data protection operations without requiring virtual machines to pause their activity for a short period of time (which would impact performance). Embodiments of the present invention allow for the protection of point-in-time images of devices (e.g., volumes, virtual machines, applications / data, consistency groups, or other configurations) without resorting to full snapshot mechanisms or stopping virtual machines.

[0026] Figure 1 An example of a data protection system that performs data protection operations in a computing environment is shown. Figure 1 A device 108 (e.g., a local device) is shown communicating with device 122 (e.g., cloud-based or cloud-operated). Devices 108 and 122 can be implemented as physical devices, virtual devices, etc. Device 108 can be associated with a production site or a production VM.

[0027] exist Figure 1 In this configuration, device 108 is associated with tracker 106, which can also be part of a data protection system. Tracker 106 resides in the I / O path between virtual machine 102 and data 104 stored on memory 130 (e.g., in the kernel or hypervisor layer). Tracker 106 can intercept any I / O from virtual machine 102 and send or copy I / O to device 108.

[0028] More specifically, tracker 106 (and / or device 108) can track changes to data 104 relative to a previous point in time, such as a previous snapshot. In one example, a bitmap is used to track changes to data 104. Each time a snapshot is generated, a new bitmap is created to track changes after the snapshot time. The old or previous bitmap is used to identify dirty areas of memory 130 (areas that have changed since a previous backup or snapshot). In one example, each time a snapshot or backup is performed, the current bitmap becomes the old bitmap, and a new bitmap is generated to track subsequent changes to memory 130 or data 104.

[0029] Therefore, changes to data 104 are tracked in the bitmap. Each entry in the bitmap can correspond to a region of memory 130 and can have a fixed size. For example, each entry in the bitmap can correspond to a 64KB disk segment or a 64KB data segment. Other segment sizes can be used in embodiments of the invention.

[0030] The data protection system generates snapshots when taking snapshots of virtual machine 102 and / or data 104 or volumes of virtual machine 102.

[0031] This example assumes that some processes are performed or controlled by tracker 106 and / or device 108, at least locally or at a production site. These processes can be performed by any combination of tracker 106 and / or device 108.

[0032] Initially, tracker 106 opens or creates a new bitmap 112, which is initially empty when a snapshot is triggered. At snapshot time, the old bitmap (bitmap 110) is closed, and bitmap 110 identifies regions or data fragments that have changed since the previous snapshot. The data corresponding to dirty bits will be referred to as fragments in the following discussion. In some examples, fragments and blocks in the differential log are examples of objects.

[0033] After the bitmap is ready for processing, bitmap 110 is synchronized. Synchronizing bitmap 110 involves reading segments from data 104 corresponding to dirty bits in bitmap 110. For each bit set in the old bitmap 110 (dirty bits), tracker 106 can read the corresponding segment from data 104 stored on storage device 130. These segments can be read by device 108, and the segments read based on dirty bits in bitmap 110 are transferred to device 122 and stored together with data 124 stored in cloud storage.

[0034] As a segment corresponding to a set or dirty bit in bitmap 110 is read, a new I / O may arrive from virtual machine 102. When a new I / O arrives, tracker 106 sets the corresponding bit in bitmap 112. The new bitmap 112 will be used for the next snapshot. If the new I / O points to a segment that has not yet been synchronized (e.g., read by device 108 and / or transferred to device 122), the block (or a portion of disk or data) corresponding to the new I / O is read and stored in the log, also referred to here as the differential log. This operation is performed only for the first I / O sent to that segment during synchronization or snapshotting.

[0035] By retaining the block before submitting new IO to data 104, the block can be used to overwrite the fragment once the fragment is synchronized. This ensures that the fragment or fragment data is preserved or protected as it existed when the snapshot was taken.

[0036] After a block has been stored in the differential log, a new IO is then written to data 104 on memory 130. This fragment is overwritten by the new IO. Because the block size may differ from the fragment size represented in the bitmap, a block may affect one or more fragments or entries in the bitmap. If the new IO is a block larger than the fragment, multiple bits can be set to overwrite the block. When the synchronization process reaches a fragment that has been (at least partially) overwritten by the new IO, the fragment can still be copied and transferred to device 122. As discussed in more detail below, this fragment is ultimately replaced by the block in the differential log to recover the fragment that existed at the time the snapshot was taken.

[0037] Therefore, initial synchronization of the fragments associated with the dirty bits in bitmap 110 has been performed. This synchronization may include transferring the fragments to device 122. In the second phase, the full contents of the differential log (or multiple differential logs) are provided to or accessed by device 108. The differential logs may be stored by the device. Device 108 sends one or more differential logs to device 122 for storage along with data 124.

[0038] In one example, device 108 can be configured, for example, to collect data in large volumes and efficiently transfer the data to device 122. Therefore, fragment and differential logs can be organized at device 108, making the transfer of fragment and differential logs more efficient.

[0039] In Cloud 120, data can be received in two phases. The first step involves receiving the fragment corresponding to the dirty bits in bitmap 110. The second step corresponds to receiving the differential log. In one example, these two steps or both phases are performed when a single backup or snapshot is generated. Since the snapshot may be an incremental snapshot, other fragments corresponding to that snapshot already exist in Cloud 120.

[0040] More specifically, the segments transmitted to device 122 or cloud 120 are the result of processing dirty bits in bitmap 110. In one example, the segments read during the first phase are fixed-size regions. In another example, this size depends on the size of the region represented by each bit in bitmap 110. For example, if each bit in bitmap 110 marks a 64KB region, then each segment sent in the first step or first phase will be a full 64KB of data. Other segment sizes are also possible.

[0041] Furthermore, data is transmitted in an ordered manner. In other words, the offset of a segment determines the order in which segments are transmitted to device 122. This facilitates write and restore operations because segments can be written sequentially.

[0042] Data in the differential log (referred to herein as blocks to distinguish them from fragments) can have different sizes, at least because blocks correspond to new IOs directed to memory 130. For example, and assuming a fragment size of 64KB, if a 4KB IO arrives, tracker 106 or device 108 reads the associated 4KB block from memory 130 and stores the 4KB block in the differential log. In one implementation, and only as an example, since the bitmap resolution is 64KB in this example, a 64KB block can be read instead of a 4KB block. When using a bitmap to track dirty fragments, the bitmap resolution thus identifies the fragment, or in this example, a backup of 64KB is required. In an example where the same fragment has two 4KB IOs, it is unknown whether the fragment has been read into the differential log without additional overhead. Therefore, reading the entire fragment allows for the protection of all partial IOs (in terms of fragment size). In one example, the block size can be smaller than the resolution of the bitmap (fragment). Using the previous example where the fragment and bitmap resolution are 64KB, 4KB is input and the entire 64KB of undo data is read—not just 4KB in one example. In one example, tracking of the region where undo information has been read is done at a fragment resolution (64KB in this example). Therefore, all read undo blocks can be read and aligned in multiples of 64KB. If 4KB is written to offset 140KB, then 64KB needs to be read from offsets 128KB to 196KB. The differential log can contain differential log packets of a predetermined size. Therefore, the differential log may contain multiple differential log packets. Each packet can aggregate many blocks.

[0043] Furthermore, blocks within each differential log are placed in the differential log in the order they arrive. For example, an I / O pointing to the beginning of disk can be followed immediately by an I / O pointing to the end of disk. The order of blocks in the differential log is effectively determined by the original workload that generated the I / O. Device 122, located at the target site or in the cloud, writes the differential log to object storage (e.g., AWS S3) upon receiving it.

[0044] Figure 2 An example is shown of how fragments and differential logs corresponding to snapshot operations can be stored in cloud storage. Figure 2 A memory 202 (e.g., object memory) including a bucket 204 is shown. Segments 206 received during the first phase are stored in an ordered manner. Figure 2 As shown, segments 206 corresponding to data associated with at least some dirty bits are written sequentially and have a predetermined size. As an example, Figure 2 Each segment 206 in the dataset is only 4MB in size and the offsets are sorted.

[0045] In this example, the differential log can include more than one packet. The differential log packets within the differential log are shown as differential log 208 and differential log 210. Differential log 208 illustrates that the blocks in differential log 208 are not of fixed size and are not ordered, except possibly regarding the order in which the VM receives or writes the blocks. However, the blocks in differential logs 208 and 210 are not ordered by offset and do not have a specific size.

[0046] Figure 2 Examples of snapshots or backups generated from virtual machine 102 or from a production site are shown. In some examples, the differential log may also contain objects with metadata. In this example, for ease of explanation, objects in the differential log begin at MB boundaries. However, writes can begin at any block boundary.

[0047] When preparing for a recovery operation, embodiments of the present invention perform processing (or preprocessing for a recovery operation at a later time) to substantially merge the differential logs into fragments. This allows virtual machines to be recovered by writing fragments, avoiding the time and cost associated with processing differential logs during recovery.

[0048] In contrast, an example of a recovery operation without preprocessing is described. To perform a recovery operation up to a specific point in time, data protection systems (e.g., Figure 1 Device 122) can perform the process step by step. Regarding Figure 2 And in order to restore it to its original state Figure 2 The snapshot shown represents a point in time from which segment 206 can be applied to the disk or volume used to restore the VM (to mix the VMs, it may be necessary to write appropriate segments from another backup, because...). Figure 2 The snapshot shown may be an incremental snapshot.

[0049] Next, the entire differential log (e.g., differential logs 208 and 210) is applied to overwrite the segments that have already been written. This is done because the differential log contains data blocks from a selected point in time, while some segments may contain data written after that point in time. In other words, data in some segments 206 might have been collected after new writes or I / O had already been applied at the production site. Applying blocks to the differential log allows segments to be restored to the selected point in time.

[0050] For example, segment 206 with an offset of 0 and a size of 4MB may not contain data applicable to the selected point in time. For instance, this segment may have been synchronized after a new IO write to disk. Therefore, in order to recover the actual data at the selected point in time, blocks must be applied to the differential log as described above.

[0051] In this example, differential log 208 includes a block with an offset of 2MB and a length of 64KB. The fragment at offset 0 (or a portion thereof) is overwritten by the block with an offset of 2MB. Second differential log 210 also includes a block with an offset of 1MB and a length of 2KB. This block is also applied to the fragment at offset 0. These two stages allow recovery to a selected point in time. Storing fragments and differential logs can result in customers paying for unnecessary storage. This process can also lead to unnecessary computation or CPU time. More specifically, some data in fragment 206 is not needed at that particular point in time. Therefore, the storage cost exceeds the requirement. Furthermore, at least because the differential log needs to be downloaded and then the block stored in the differential log applied to the target VM, the direct method of simply overwriting fragments with blocks from the differential log increases the recovery process time.

[0052] Embodiments of the present invention further relate to the efficiency of this process. As previously described, differential logs contain blocks used to overwrite certain segments or portions thereof. Although embodiments of the present invention have been discussed with reference to copied data (e.g., using an LWD mechanism to copy data), embodiments of the present invention can be implemented with other applications when copying applications / data to cloud-based storage.

[0053] For example, embodiments of the present invention can be used to replicate a database that uses transaction logs. When replicating the database, an image of the database's data files can be used. A set of files containing transaction logs can be applied to the database itself to generate the latest point in time. In this example, the transaction logs are essentially overwriting the original data contained in the database image or used to overwrite the original data contained in the database image with data related to a specific point in time.

[0054] One distinction is that differential logs contain "undo" information or data that existed before new I / O was received, while database transaction logs contain "execution" information or data to be applied. Typically, every logging mechanism can benefit from implementations of this invention, including data protection systems, database systems, file system logs, etc.

[0055] Embodiments of this invention improve the storage of fragments and differential logs by merging differential logs into complete fragments stored in cloud storage. This eliminates the need to separately read and apply the differential logs after applying the complete fragments to the target VM's disk. It also reduces storage consumption in the cloud, thus avoiding data storage twice or unnecessarily.

[0056] In one example, blocks in the differential log can be merged into a complete fragment by iterating through the differential log, and for each block in the differential log, that block is applied to the relevant fragment. While this is possible, the differential log blocks (or objects) are not ordered. Therefore, this simple approach requires reading, modifying, and writing the entire fragment for each block in the differential log. Because the differential log blocks are not ordered, the process of reading, modifying, and writing the complete fragment occurs for each block in the differential log. This can be time-consuming and may result in multiple reads, modifications, and writes to the same fragment.

[0057] For example, when differential logs 208 and 210 are processed in this manner, the first 4MB segment in fragment 206 will be processed at least twice. Furthermore, object storage is eventually consistent. Therefore, when a client reads, modifies, and writes to the same fragment or object multiple times, there is no guarantee that the process will be performed on the latest version of the fragment or object.

[0058] Embodiments of the present invention also relate to efficiently applying differential logs to complete storage segments or objects in a manner consistent with object storage.

[0059] Figure 3 An example of a method for performing data protection operations such as optimizing RTO and / or cloud costs is shown. Figure 3 It is for reference. Figure 2 The description is as follows. RTO can be optimized by processing the differential log (preprocessing for potential future recovery operations). Initially, the differential log metadata is loaded with a 302 or accessed. Metadata can be stored as objects in the differential log. For each fragment or object, the metadata may include an offset and / or length, and may identify a bucket or other storage location in the cloud.

[0060] Once the differential log is loaded, it is split into 304s or groups based on the offset. See, for example... Figure 2 The differential log 208 is divided into offset differential logs based on the offsets of objects or fragments in the initial differential log. In other words, an offset differential log is created for each offset in the initial differential log.

[0061] Next, the offset differential log is split or grouped based on the fragment index or considering the fragment size. For example, if the offset and length of a block in the differential log cover more than one fragment, the offset differential log is split or organized so that the offset differential log corresponds to the fragment associated with the changed block. This may result in the creation of additional offset differential log entries.

[0062] The offset differential logs can then be grouped or organized by fragment index (308). In other words, all offset differential logs associated with the same fragment (or the same fragment index, such as offset) can be grouped together.

[0063] For each fragment index (or offset), the associated differential log raw data is retrieved and the fragment (or a portion thereof) is overwritten with differential log blocks as needed. Therefore, all blocks associated with the same index or fragment offset are written simultaneously or during the same fragment access. Advantageously, this process ensures that the same index or the same fragment is not accessed repeatedly, but this could happen if each block in the differential log were processed individually. By grouping or organizing blocks into the index of the offset differential log, all differential log objects for a specific fragment or fragment index can be processed simultaneously for each fragment. In other words, based on how the differential log has been organized or segmented, fragments are overwritten or covered by blocks from the differential log.

[0064] When overwriting a fragment with a block or object from the differential log, you can use the API to overwrite the fragment in the cloud by using offsets and lengths. Alternatively, you can download the fragment, modify it using all relevant blocks in the differential log, and then upload it back to the cloud.

[0065] Finally, the differential logs were removed from cloud storage. This ensures that storage space is not over-consumed, thereby reducing storage costs.

[0066] Figure 3 Method 300 also about Figures 4-7 It is shown. More specifically, Figure 4 Virtual disk 400 is shown, and in this example, its disk size is 1GB. In this example, the virtual disk is divided into 256 segments. Therefore, each segment is 4MB in size. Virtual disk 400 can represent both the production disk and the target disk for restoring the VM.

[0067] When taking a snapshot, you can follow Figure 2 The method shown stores changed fragments, differential logs, and metadata. Therefore, the number of fragments included in fragment 206 depends on the number of dirty bits in the corresponding bitmap and is typically less than all available fragments.

[0068] The modified fragments and differential logs are then sent to and stored in the cloud.

[0069] For example, when preprocessing a backup (which may include fragments and differential logs), assume that the snapshot of virtual disk 400 includes 5 fragments (fragment 0, fragment 1, fragment 253, fragment 254, and fragment 255), differential log 1 (containing 2 blocks), and differential log 2 (containing 1 block). This example assumes... Figure 4 The segments 0, 1, N-2, and N-1 shown represent segments 0, 1, 253, 254, and 255, respectively.

[0070] Initially, differential log metadata is loaded or accessed. This metadata is reflected in... Figure 4 middle, Figure 4 The differential log 1 is shown to be associated with the following two blocks: block 1, with an offset of 0 and a length of 6MB; and block 2, with an offset of 1012MB and a length of 10MB. The metadata of differential log 2 shows that differential log 2 is associated with block 1, which has an offset of 6.1MB and a length of 4KB.

[0071] After the metadata is loaded, each differential log is split or organized into offset differential logs or new differential logs.

[0072] Figure 5 The diagram shows that Differential Log 1 is split into Offset Differential Log 1-1 and Differential Log 1-2. Differential Log 1-1 is associated with all blocks at offset 0. Differential Log 1-2 is associated with all blocks at offset 1012MB. Because Differential Log 2 contains only a single offset, it is not split. Therefore, Differential Log 1 is split based on the offsets represented in its metadata.

[0073] Figure 6 This illustrates further segmentation of the offset differential log based on the fragment index. (Brief reference) Figure 4 Each segment from 0 to segment N-1 can have a corresponding index: S0, S1, ... S N-1 There are a total of 256 indices. In this example, each fragment has a fixed size of 4MB. Therefore, the offset differential log is further segmented, allowing objects in the differential log to be split based on fragment offsets or fragment indices.

[0074] In this example, differential log 1-1 is split into offset differential log 1-1-1 and 1-1-2. Differential log 1-1-1 is associated with a fragment whose offset is 0 or has an index 0 (S0) and a length of 4MB (the size of the fragment). This allows the remaining blocks represented by differential log 1-1 to be associated with the next fragment index S1. Differential log 1-1-2 is associated with an object with an offset of 4MB and a length of 2MB. Similarly, differential log 1-2 is split into differential log 1-2-1, 1-2-2, and 1-2-3. Differential log 1-2-1, 1-2-2, and 1-2-3 are associated with offsets of 1012MB, 1016MB, and 1020MB, or fragment index S1. 253 S 254 and S 255 Related.

[0075] Figure 7 This illustrates how differential logs can be grouped by fragment indexes after the splitting process. In this example, fragment index 0 (or offset 0) is associated with differential log 1-1-1, and fragment index 1 is associated with two other differential logs: differential log 1-1-2 and differential log 2. Fragment indices 253, 254, and 255 are associated with differential logs 1-2-1, 1-2-2, and 1-2-3, respectively.

[0076] This allows fragments at these indices to be processed, so that all blocks corresponding to differential logs 1 and 2 for that fragment are applied simultaneously. When processing a fragment with fragment index 0 (S0), the block from differential log 1-1-1 needs to be applied to fragment S0, and then fragment S0 is written to cloud storage. Alternatively, the block associated with differential log 1-1-1 can already be fragment S0 that has been written to the cloud.

[0077] Similarly, when fragment S1 is updated, blocks from differential logs 1-1-2 and 2 are simultaneously applied to fragment S1. Other fragments are processed similarly. In one example, for each fragment index, the raw data blocks of the relevant differential logs are loaded, and these blocks are used, for example, with a cloud API (Application Programming Interface) to update the fragment's raw data. Once this process is complete, all differential logs can be deleted or removed from memory and cloud storage.

[0078] In one example Figure 3 This process may include reading, which can incur costs. For example, suppose the differential log has 1000 entries or objects and there are multiple differential logs. If the length of the raw data in each entry is 1KB, then 1000 read API calls may be needed for each differential log. In some examples, embodiments of the invention can also use graphs to reduce the number of reads.

[0079] The preprocessing segments and delta logs can include constructing a graph G. The following disclosure assumes that a subgraph is another graph formed by a subset of the vertices and boundaries of G. The subset of vertices should include all endpoints of the subset of boundaries, but may also include other vertices. A connected component can be a subgraph of an undirected graph, and any two vertices in the undirected graph can be connected to each other by a path.

[0080] Initially, a graph is established or constructed. The graph can be established from snapshots (segments and chunks) uploaded to the cloud. For example, the process produces a graph G, which is an undirected graph with the following specifications.

[0081] Vertices (V): Consist of copy segments (labeled S i , where i is the segment index) and copy delta logs (labeled D j , where j is the demand log index). Each vertex exists as an object in cloud storage.

[0082] Boundaries (E):

[0083] ((D j ,S i ) | D j has an entry with an offset and length pointing to S i , 0 < i < number of segments, 0 < j < number of demand logs)

[0084] To establish the graph, the following process is performed:

[0085] Traverse the metadata of the delta logs and create nodes with delta log indices (D j );

[0086] For each D j , read the metadata, traverse the entries, and perform:

[0087] Calculate which segment indices the offset and length point to; and

[0088] Create segment nodes based on the results of 0, and for these nodes, create boundaries that connect them to D j ; and

[0089] Return G(V, E).

[0090] Figure 8An example of the graph returned after performing this process is shown. Graph 800 represents the relationship between fragments and blocks or differential logs. In this example, fragments correspond to nodes or vertices in graph 800, and differential logs also correspond to nodes or vertices. In this example, differential log D1 references fragments S1 and S2. Differential log D2 references fragments S2 and S4. Other relationships are also shown in graph 800. Differential log D5 is the only differential log that references fragment S3. Differential log D5 does not reference any other fragments.

[0091] Once the graph is formed, the components of a connection are determined. In this example, vertices are processed and a search algorithm is executed. A component of a connection is a set of vertices connected by boundaries. By forming a graph to identify the components (or segments / blocks) of a connection, unrelated components can be processed in parallel without needing to consider dependencies.

[0092] To compute the components of a connection, vertices need to be traversed and search algorithms such as BFS (Breadth-First Search) or DFS (Depth-First Search) need to be executed. The output is a list of the components of a connection, where the intersection between any two component vertices of a connection is empty.

[0093] After identifying the components of the connection, perform the following recovery operation. Figure 9 Examples of chart-based recovery operations or operations that prepare segments for recovery operations are shown.

[0094] More specifically, Figure 9 An example of a method for applying differential logs to fragments is shown. After the graph is formed, the components of 902 or the connections are processed. Traversing the components of 902 connections can include traversing the fragment node 904 and the differential log node 906 in the graph.

[0095] More specifically, traversing the 904 fragment node includes downloading the fragment data and storing the fragment data in a mapping in memory. The key to this mapping can be the fragment index, and the value can be the original data. Traversing the 906 demand node can include downloading blocks and storing the blocks as a list, which can be a list of blocks.

[0096] Next, the entries or blocks in the differential log are processed. For example, the offset and length of entry i are read, and the fragment index is determined based on the offset and length of the block in the differential log. For example, for a 6MB block (assuming a fragment size of 4MB), the analysis can identify at least two fragment indices for that block as described above. Each differential log or node can contain more than one block or object.

[0097] Once the index is determined, fragments are overwritten or covered using block overwrite. Once all entries in the differential log or differential log nodes are complete, fragment 908 is removed. Fragment removal may include uploading the fragment back to the cloud and then removing the entry from the fragment map in memory. Finally, differential log 910 is removed from the cloud and / or memory.

[0098] One advantage of method 900 is that the processing of objects (e.g., fragments and / or blocks and / or metadata) is divided into multiple subgroups. These subgroups are typically smaller and easier to fit in memory.

[0099] Each component of a connection can be processed independently by the recovery VM and adapted into the recovery VM's memory. Therefore, each object will be read / written to object memory only once, eliminating multiple reads and the cost of those reads.

[0100] In one example, a component of a connection cannot fit into memory due to the size of that component. This can be determined when the graph is constructed. In this case, one of the aforementioned implementation methods can be applied to at least a portion of the graph.

[0101] The various methods described in this paper can be partially combined. For example, the segmentation differential logs in steps 304 and 306 can be implemented using a graph as described in this paper. Therefore, the various methods disclosed in this paper can be combined in different ways.

[0102] In another example, the chart can be divided into sub-components. Figure 10 Examples of diagrams are shown that are divided into or subdivided into sub-components that can be processed individually and / or independently. Figure 10 A fully connected diagram 1000 is shown. However, node D2 is a node or object connecting two subgroups. Therefore, node D2, which includes or is a differential log, can be replaced by two differential logs as shown in diagram 1002: differential logs D2-1 and D2-2.

[0103] Differential log D2-1 contains references to S1-S4, and differential log D2-2 contains the remaining references to S5. This cleanly separates the components of a single connection into two components.

[0104] Analyzing the components of the connections to detect the minimum required changes is equivalent to finding the minimum vertex cut in known graph theory. Once this is done, the resulting components of the connections can be processed as discussed in this paper. Therefore, subgraphs 1000 and 1002 can be stored in the memory of the VM that processes the graphs.

[0105] In one example, once preprocessing is complete and the differential logs are gone, and the fragment now contains relevant data for that point in time, the recovery process can be performed as follows.

[0106] The data protection system will trigger a disaster recovery operation to create a virtual machine from a specific copy or point-in-time backup. The restored VM is then deployed. The restored VM sequentially downloads all fragments and writes them to the relevant disks.

[0107] The embodiments of the present invention advantageously improve RTO. It is recommended to apply differential logs to relevant segments in the cloud. This is typically performed in situations where disaster recovery operations may be required in the future. Therefore, RTO (for recovery operations) is improved due to the downloading of segments. Differential logs do not need to be downloaded because they have already been applied and deleted (thus saving storage costs). RTO is further reduced, at least because the time associated with writing differential logs to the VM being recovered is eliminated.

[0108] Embodiments of the present invention (such as those disclosed herein) can be advantageous in several respects. For example, and as will be apparent from this disclosure, one or more embodiments of the invention can provide one or more advantages and unexpected effects in any combination, some of which are described below. It should be noted that these effects are not intended and should not be construed as limiting the scope of the invention in any way. It should also be noted that no element herein should be construed as essential or indispensable to the invention or its embodiments. Rather, aspects of the disclosed embodiments can be combined in various ways to define other embodiments. These other embodiments are considered to be within the scope of this disclosure. Furthermore, any embodiment included within the scope of this disclosure should not be construed as solving or being limited to solving a particular problem. No embodiment should be construed as achieving or being limited to achieving a particular technical effect or technical solution. Finally, not every embodiment needs to achieve all the advantages and unexpected effects disclosed herein.

[0109] The following discussion focuses on exemplary operating environments for various embodiments of the present invention. This discussion is not intended to limit the scope of the invention or the applicability of the embodiments in any way.

[0110] Typically, embodiments of the present invention can be implemented using systems, software, and components that individually and / or jointly implement and / or enable data protection operations. These operations may include, but are not limited to, data read / write / delete operations, data deduplication operations, data backup operations, data repair operations, data cloning operations, data archiving operations, and disaster recovery operations. More generally, the scope of the present invention includes any operating environment in which the disclosed concepts can be used.

[0111] However, the scope of this invention is generally not limited to any particular data backup platform or data storage environment.

[0112] New and / or modified data collected and / or generated using various implementation methods can be stored in a data protection environment, which may employ public or private cloud storage, local storage, or a hybrid storage environment including public and private elements. Any of these exemplary storage environments can be partially or fully virtualized. The storage environment may include or comprise a data center, operable to serve read, write, delete, backup, repair, and / or cloning operations initiated by one or more clients or other components of the operating environment. Backups include data sets with different characteristics, which can be allocated and stored at various destinations within the storage environment, each destination corresponding to a data set with one or more specific characteristics.

[0113] Exemplary public cloud storage environments that can be used in embodiments of the present invention include, but are not limited to, Microsoft Azure, Amazon AWS, and Google Cloud. However, more generally, the scope of the present invention is not limited to using any particular type of cloud storage or implementing cloud storage.

[0114] In addition to the storage environment, the operating environment may also include one or more clients capable of collecting, modifying, and creating data. Therefore, a particular client may be associated, or otherwise associated with, one or more instances of each of the one or more applications performing these data-related operations.

[0115] Devices in the operating environment can take the form of software, physical machines, virtual machines (VMs), or any combination thereof, although no specific device implementation or configuration is required in any implementation. Similarly, data protection system components such as databases, storage servers, storage volumes (LUNs), storage disks, replication services, backup servers, repair servers, backup clients, and repair clients can also take the form of software, physical machines, or virtual machines (VMs), although no specific component implementation is required in any implementation. VMs are employed, and hypervisors or other virtual machine monitoring programs (VMMs) can be employed to create and control VMs. Data VMs include, but are not limited to, virtualization, emulation, or other representations of one or more computing system elements such as computing system hardware. VMs can be based on one or more computer architectures and provide the functionality of a physical computer. VM implementations may include, or at least involve, the use of hardware and / or software. Images of VMs can take various forms, such as .VMDK files.

[0116] As used herein, the term “data” is intended to have a broad scope. Thus, the term includes, by way of example and not limitation, fragments of data, data chunks, data blocks, atomic data, emails, any type of object that can be produced by segmented processing of a data stream, any type of file including media files, Word processing files, spreadsheet files, and database files, as well as address books, directories, subdirectories, volumes, and any combination of one or more of the foregoing.

[0117] Exemplary embodiments of the present invention can be applied to any system capable of storing and processing objects of various types, in analog, digital, or other forms. Although terms such as document, file, fragment, block, or object may be used by way of example, the principles of this disclosure are not limited to any particular form of representing and storing data or other information. Rather, these principles can be applied equally to any object capable of representing information.

[0118] As used herein, the term "backup" is intended to have a broad scope. Therefore, exemplary backups that can be employed in embodiments of the present invention include, but are not limited to, full backups, partial backups, clones, snapshots, and incremental or differential backups.

[0119] The following are some other exemplary embodiments of the present invention. These are merely examples and are not intended to limit the scope of the invention in any way.

[0120] Implementation 1: A method comprising: loading metadata associated with differential logs stored in a cloud storage, wherein the differential logs and fragments are associated with backups corresponding to points in time; processing the differential logs to create new differential logs based on offsets of blocks included in the differential logs and fragment indices; grouping the new differential logs based on the fragment indices; and overwriting the fragments based on the new differential logs such that all blocks associated with a particular fragment are applied simultaneously.

[0121] Implementation 2, the method as described in Implementation 1, further includes removing the differential log from the memory.

[0122] Implementation 3, the method as described in Implementation 1 and / or 2, further includes generating a graph from the fragments and differential logs associated with the backup.

[0123] Implementation 4, the method as described in Implementation 1, 2, and / or 3, further includes traversing the fragment and traversing the differential log.

[0124] Implementation 5, the method as described in Implementations 1, 2, 3, and / or 4, wherein traversing the fragment includes storing the data of the fragment in memory, and wherein traversing the differential log includes: downloading the block identified in the differential log, storing the block in memory, and determining the fragment index of the block.

[0125] Implementation 6, as described in Implementations 1, 2, 3, 4, and / or 5, wherein some of the blocks are associated with more than one index.

[0126] Implementation 7, the method as described in Implementations 1, 2, 3, 4, 5, and / or 6, further includes: applying the block to the fragment in memory and storing the fragment in the cloud storage.

[0127] Implementation method 8, as described in implementation methods 1, 2, 3, 4, 5, 6, and / or 7, further includes removing the differential log from the cloud storage.

[0128] Implementation method 9, as described in implementation methods 1, 2, 3, 4, 5, 6, 7, and / or 8, wherein the backup corresponds to a point in time after the differential log is applied to the segment.

[0129] Implementation 10, the method as described in Implementations 1, 2, 3, 4, 5, 6, 7, 8, and / or 9, further includes performing a snapshot to obtain the backup.

[0130] Implementation 11: A method for performing any operation, method, or process disclosed herein, or any part thereof.

[0131] Implementation 12: A non-transitory storage medium storing instructions executable by one or more hardware processors to perform operations or portions thereof as described in any one or more of Implementations 1-11.

[0132] The embodiments disclosed herein may include the use of a dedicated or general-purpose computer comprising various computer hardware or software modules, as discussed in more detail below. The computer may include a processor and a computer storage medium carrying instructions that, when executed by the processor and / or causing the processor to execute the instructions, perform any or more of the methods disclosed herein, or any portion thereof.

[0133] As described above, embodiments within the scope of this invention also include a computer storage medium, which is a physical medium for carrying or having computer-executable instructions or data structures stored thereon. Such a computer storage medium can be any available physical medium that can be accessed by a general-purpose or special-purpose computer.

[0134] By way of example, and not limitation, such computer storage media may include hardware memory such as solid-state drives (SSDs), RAM, ROM, EEPROM, CD-ROM, flash memory, phase-change memory (“PCM”), or other optical disk storage, magnetic disk storage, or other magnetic storage devices, or any other hardware storage device that can be used to store program code in the form of computer-executable instructions or data structures that can be accessed and executed by general-purpose or special-purpose computer systems to perform the functions disclosed in this invention. Combinations of the above should also be included within the scope of computer storage media. These media are also examples of non-transitory storage media, which also include cloud-based storage systems and architectures; however, the scope of this invention is not limited to these examples of non-transitory storage media.

[0135] Computer-executable instructions include, for example, instructions and data that, when executed, cause a general-purpose computer, a special-purpose computer, or a special-purpose processing device to perform a function or a set of functions. Therefore, some embodiments of the present invention can be downloaded to one or more systems or devices, for example, from websites, mesh topologies, or other sources. Furthermore, the scope of the present invention includes any hardware system or device that includes instances of application programs having the disclosed executable instructions.

[0136] Although the subject matter has been described in language specific to structural features and / or methodological actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions disclosed herein are disclosed as exemplary forms for implementing the claims.

[0137] As used herein, the terms "module" or "component" can refer to a software object or routine that executes on a computing system. The various components, modules, engines, and services described herein can be implemented as objects or processes that execute on a computing system, for example, as separate threads. While the systems and methods described herein can be implemented in software, implementation in hardware or a combination of software and hardware is also possible and contemplated. In this invention, a "computing entity" can be any computing system as defined herein, or any module or combination of modules running on a computing system.

[0138] In at least some instances, a hardware processor is provided that is operable to execute executable instructions for performing methods or processes, such as those disclosed herein. The hardware processor may or may not include other hardware, elements of computing devices and systems, such as those disclosed herein.

[0139] Regarding the computing environment, embodiments of the present invention can be executed in a client-server environment (whether a network environment or a local environment) or any other suitable environment. Suitable operating environments for at least some embodiments of the present invention include cloud computing environments, in which one or more of the client, server, or other machines can reside and operate in the cloud environment.

[0140] Any or more of the entities disclosed or implied in the accompanying drawings and this disclosure and / or elsewhere herein may take the form of, include, be implemented on, or be dominated by a physical computing device, such as an example of a physical computing device. Furthermore, any of the foregoing elements includes or comprises a virtual machine (VM), which may construct a virtualization of any combination of the entity components disclosed herein.

[0141] In one example, a physical computing device includes memory (which may include random access memory (RAM), non-volatile random access memory (NVRAM), read-only memory (ROM), and permanent memory), one or more hardware processors, non-transitory storage media, a user interface (UI) device, and data storage. One or more of the memory components of the physical computing device may take the form of solid-state drive (SSD) memory. Furthermore, one or more applications may be provided, which include instructions executable by one or more hardware processors to perform any or any part of the operations disclosed herein.

[0142] Such executable instructions may take various forms, including, for example, instructions executable to perform any method or part thereof disclosed herein, and / or instructions executable by / at any storage site to perform any function disclosed herein, such storage site being a local storage site, a cloud storage site, a client, a data center, or a backup server. Furthermore, such instructions may be executed to perform any other operations and methods disclosed herein, and any part thereof, including, but not limited to, the data protection operations disclosed herein.

[0143] This invention may be implemented in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects as illustrative rather than restrictive. Therefore, the scope of the invention is indicated by the appended claims rather than by the preceding description. All modifications falling within the equivalent meaning and scope of the claims are included within the scope of the claims.

Claims

1. A method comprising: generating a backup of data at a point in time based on a bitmap, wherein each entry in the bitmap corresponds to a segment of the data and each marked bit corresponds to a segment of the data that has changed, wherein each segment has a fixed size, by: performing a synchronization process by reading segments of the data corresponding to the marked bits; and generating a delta log during the synchronization process, wherein the delta log comprises chunks corresponding to data overwritten by writes applied to segments that have not been synchronized by the synchronization process, wherein each chunk has an unfixed size; loading metadata associated with the delta log stored in a cloud storage, wherein the delta log and segments are associated with the backup corresponding to the point in time; processing the delta log to create a new delta log based on offsets and segment indices of chunks included in the delta log; grouping the new delta log based on the segment indices; overwriting the segments based on the new delta log such that all chunks associated with a particular segment are applied simultaneously.

2. The method of claim 1, further comprising removing the delta log from storage.

3. The method of claim 1, further comprising generating a graph from the segments associated with the backup and the delta log.

4. The method of claim 3, further comprising traversing the segments and traversing the delta log.

5. The method of claim 4, wherein, traversing the segments comprises leaving data of the segments in memory, and wherein traversing the delta log comprises downloading chunks identified in the delta log, leaving the chunks in the memory, and determining segment indices of the chunks.

6. The method of claim 5, wherein, some of the chunks are associated with more than one index.

7. The method of claim 5, further comprising: applying the chunks to the segments in memory and storing the segments in the cloud storage.

8. The method of claim 1, further comprising removing the delta log from the cloud storage.

9. The method of claim 1, wherein, the backup corresponds to a point in time after the delta log is applied to the segments.

10. The method of claim 3, further comprising performing a snapshot to obtain the backup.

11. A non-transitory storage medium having stored therein instructions that are executable by one or more hardware processors to perform operations in the method of any of claims 1-10.

Images