DE112021000935T5 - USING BUSINESS CONTINUITY AND DISASTER RECOVERY FOR ANY POINT-IN-TIME BACKUPS - Google Patents

Abstract

Create any-point-in-time backups without creating native snapshots. Production data is split so that a journal stream is sent to a data protection system, which can be local or remote. The journal stream includes a data stream and a metadata stream. Backups are synthesized in the data protection system by rolling at least part of the journal. A backup can be synthesized for each time point represented in the journal.

Description

RELATED APPLICATIONS

This application relates to U.S. Patent Application No. 16/785,288 entitled "USING ANY-PIT BACKUPS FOR RETROACTIVE BACKUP COMPLIANCE AND HARDENING," filed February 7, 2020, the entire disclosure of which is incorporated herein by this reference.

FIELD OF THE INVENTION

Embodiments of the present invention relate generally to data protection and data protection operations. More particularly, at least some embodiments of the invention relate to systems, hardware, software, computer-readable media, and methods for data protection operations, including any-point-in-time backups.

BACKGROUND

Computer systems often store data that has significant value. Any business that has a problem with its data can experience economic problems, customer problems, trust problems and the like. Therefore, the ability to protect data is an important aspect of many computer systems. The ability to recover data as quickly and with as little loss as possible reduces the scope and scale of problems caused by problematic data.

Computer systems often use virtual machines to run applications. However, protecting virtual machines can be difficult. Conventionally, snapshots are used to take backups of the virtual machines. However, in order to perform snapshots, the virtual machines must be hibernated and quiesced. This can disrupt the applications running on the virtual machines.

In addition, from a practical point of view, it is difficult to take frequent snapshots. There are many system-wide limitations that affect the number of snapshots that can be created. In fact, most systems are limited to taking snapshots in the range of minutes to hours. While mirroring systems can be used to compensate for the frequency of snapshots, these solutions require significant storage resources and are associated with significant management overhead.

All of these factors affect an organization's recovery point objective (RPO). RPO expresses a relationship between the time between backups and the amount of data that could be lost between backups. When a company's RPO is kept low, the company is in a better position when data is corrupted or lost than it is in a higher RPO situation. Therefore, there is a need to improve the way data is protected.

character list

• 1 ein Beispiel für ein Datenschutzsystem zeigt, das so konfiguriert ist, dass es Datenschutzoperationen durchführt und Point-in-Time-Backups ohne die Verwendung nativer Snaphots erstellt;
• 2 ein Beispiel für ein Journal zeigt, das bei der Erstellung von Point-in-Time-Backups verwendet wird;
• 3 ein Beispiel für Backups zeigt, die von einem Journal in einem Datenschutzsystem erzeugt werden; und
• 4 ein Beispiel für ein Verfahren zur Erzeugung von Any-Point-in-Time-Backups zeigt.

In order to describe the manner in which at least some of the advantages and features of the invention may be achieved, a more detailed description of embodiments of the invention will be given by reference to specific embodiments thereof that are illustrated in the accompanying drawings. Realizing that these drawings represent only typical embodiments of the invention and are therefore not to be considered as limiting its scope, embodiments of the invention will be described and explained with additional specificity and detail with reference to the accompanying drawings, wherein:

• 1 shows an example of a data protection system configured to perform data protection operations and create point-in-time backups without using native snapshots;
• 2 shows an example of a journal used when creating point-in-time backups;
• 3 shows an example of backups created by a journal in a data protection system; and
• 4 shows an example of a method for creating any-point-in-time backups.

DETAILED DESCRIPTION OF SOME EXEMPLARY EMBODIMENTS

Embodiments of the present invention relate generally to data protection operations. In particular, at least some embodiments of the invention relate to systems, hardware, software, computer-readable media, and methods for data protection operations, including data protection (backup) operations, restore operations, imaging operations, replication operations, point-in-time (PiT) operations, deduplication operations, or the like, or combinations from that.

Embodiments of the invention relate to systems and methods for performing backup operations including PiT operations. This includes creating, synthesizing and/or storing images or snapshots or other backups on secondary storage (e.g. DELL EMC Data Domain). Embodiments of the invention continuously replicate an IO stream. The replicated IO stream can be formatted as a journal that keeps the data and metadata in separate streams. The journal is stored on the secondary storage device and backups can be generated or synthesized from the journal. This is achieved without having to take snapshots of the source data (therefore native snapshots are not required). Embodiments of the invention involve significantly less overhead compared to native snapshots (which often require shut down and/or dormant applications) and also enable any-point-in-time backup functionality. Backups can also be stored on a second storage tier.

1 Figure 1 shows an example of a computing environment in which embodiments of the invention may be implemented. 1 shows an example of a data protection system configured to produce PiT backups. The PiT backups can be synthesized from a journal and the PiT backups can be generated without requiring snapshots from a production site or system or application.

In 1 a host 102 is shown. The host 102 can be a host machine, a virtual machine, or other configuration. In this example, the host 102 may be a virtual machine operating with or on a virtualization platform 104 . The virtualization platform 104 can connect to multiple virtual machines and virtualize the hardware for those virtual machines. Hypervisors and VMware ESX and ESXI are examples of the virtualization platform 104. The virtualization platform 104 allows applications to run in virtual machines on the host 102 or other hardware.

In this example, the virtualization platform 104 can be connected to a splitter 106 . The splitter 106 may be embedded in the virtualization platform 104 or operate within the virtualization platform 104 or as a separate layer. The splitter 106 is configured for replication of data and can, for example, replicate data serially or in parallel. In fact, the splitter 106 catches IOs such as B. writes, from. The write is forwarded to or traverses production memory 108 . A copy of the data is sent to the data protection system.

In particular, the splitter 106 may intercept writes to the production storage 108 and replicate the writes to an RPA (e.g., Recover Point Appliance) 120 . The RPA 120 can be physical or virtual. The splitter 106 (which may be a mirror-type device) can replicate the data in parallel. In parallel replication or splitting, a copy of the data is sent to the RPA 120 in parallel or nearly parallel to the data being sent to production storage 108 . With parallel splitting, the splitter 106 does not have to wait for an acknowledgment to commit the write to the production storage 108 before transmitting the data or a copy of the data to the RPA 120 .

With serial transfer or serial splitting, in one embodiment, the splitter may send the write to production storage 108 . After receiving an acknowledgment, the splitter 106 can then transmit the data or a copy of the data to the RPA 120. As explained below, the confirmation may be sent by the aggregator 110 in some cases.

The RPA 120 may include the aggregator 110 and a secondary storage 112, which is an example of a second level storage, for example. The secondary storage may also include other components, such as a processor and/or controller, that enable processing of the data for storage and/or backup creation. Thus, the writes or stream of data coming from the splitter 106 can be committed to a journal 116 and stored in secondary storage 112 . Data 114 may include images or backups synthesized or generated from journal 116 . DELL Datadomain is an example of the RPA 120. The aggregator 110 may or may not be integrated with the RPA 120. However, the aggregator 110 may be part of the RPA 120 and included in the data protection system.

For example, secondary storage 112 is deduplicated. For example, data 114 (which journal 116 may include) may be stored in a pool with signatures (e.g., hashes) computed for each block or datum. In other words, the data 114 stored in secondary storage 112 includes, by way of example only, the blocks or packets (chunks) of data, signatures for each of the blocks, a journal, and backups or images. A volume in storage can be a sequence of data signatures - similar to a list of pointers to the data. In this way, each piece of data can be stored once and referenced multiple times, resulting in data deduplication on secondary storage 112 . The signatures are usually arranged in a tree structure. The journal can be stored using the signatures and is also deduplicated and doesn't take up as much space as the data itself.

Data copy operations on storage systems such as secondary storage 112 can be very efficient because the data itself does not need to be copied. Only the signatures need to be copied. This is an example of a quick copy. The advantage is that entire disks/volumes can be copied in a fraction of the time that a full copy would require.

In deduplicated systems, such as secondary storage 112 or, more generally, RPA 120, deduplication can be done with a fixed chunk size (e.g., 4K or 8k chunks or blocks). Additionally, deduplication targets multiples of the chunk size. Consequently, IOs or writes should be aligned with these boundaries. With a chunk size of 4K, the IOs should be aligned on 0, 4K, 8k, 12k, etc. boundaries or addresses. If an IO is not aligned (e.g. a 4K IO targets address 2k), the IOs will be rejected or broken along the alignment boundaries.

This can cause problems, at least at the destination, since the destination (the RPA 120 or the secondary storage 112) may not have, or not have access to, the data needed to fully cover the entire chunk. As a result, some IOs may need to be handled in a specific way. Unaligned chunks, IOs that are not a multiple of the chunk size, and IOs that are smaller than the chunk size are processed prior to or during the process of ingesting the chunks into the RPA 120 or secondary storage 112 . Processing may occur at splitter 106 or aggregator 110, for example. These chunks can be processed to align and be the right size.

For example, the host 102 (or an application or virtual machine) may be connected to an IO pattern and the data in the IO stream may not conform to the RPA 120 requirements. Embodiments of the invention are capable of different IO patterns to process.

Embodiments of the invention provide a scheme or system for performing data protection operations including data protection (backup) or replication operations without using native snapshots. Thus, a snapshot of the host 102 or a virtual machine or application on the host is not required. A streaming IO source, which may be the splitter 106, captures or intercepts the IO stream that is sent to the production storage 108. A copy of the IO stream is sent to the RPA 120. However, the copy may have a different format than the intercepted IO stream.

Replicated data stored in this way enables near-zero RPO backups, any-point-of-time backups, and requires no source-side stunning or quiescing operations.

As in 1 As illustrated, example components of the data protection system may include a streaming IO source such as the splitter 106, an aggregator 110, and a journal 116. Journal 116 may be processed to create and manage backups stored in data 114 on secondary storage 112 .

In some examples, IOs sent from virtual machines or hosts are sent to at least two places. Mirroring devices and splitters, such as splitter 106, accomplish this result in a similar manner. In both cases, the original IOs end up on the data medium, e.g. the production storage 108, and a second copy is uploaded to the data protection system, e.g. B. the RPA 120 introduced.

There may be some differences in processing unaligned IOs if the IOs are sent in parallel to the two locations or serially to one location and then to the other. A splitter 106 for replication for virtual machines, where the IOs can be processed serially, is discussed below.

For example, the RPA 120 is configured to accept incoming data streams, such as B. incoming backup data streams processed. These data streams are usually large data packets (chunks). However, IOs coming from or being received by splitter 106 depend on an IO pattern associated with an application on the host or a virtual machine that generates the IOs. These IOs can be of different sizes and may not be optimally configured for consumption by the RPA 120. Therefore, although IOs can be divided and transmitted directly to the secondary storage 112 , but embodiments of the invention include an aggregator 110 configured to provide a buffer. In particular, the aggregator 110 may aggregate or stack the IOs before sending them to the secondary storage 112 . Thus, the RPA 120 provides aggregation functionality.

IOs received by the splitter 106 are collected or buffered in a memory of the RPA 120 or in a temporary memory that can handle the load (e.g. VM VMDK, block storage, VSAN, etc.). Once enough IOs have accumulated in the memory or temporary storage used by the aggregator 110, the accumulated IOs are sent (e.g., in batches) to secondary storage as a journal or journal stream. This isolates the secondary storage 112 from high IOPs/low IO patterns and optimizes transfers to the secondary storage 112. The aggregated IOs also conform to, or are processed to conform to, the format associated with the journal 116 . The aggregator 110 also aligns the IOs for the secondary storage 112 to best utilize.

In particular, the aggregator 110 stores the incoming IO stream such that the IO data is aligned at the deduplication boundaries. This helps ensure optimal deduplication once the accumulated IOs are forwarded to the secondary storage 112. Alignment of the IO stream may include splitting the IO stream into a data stream and a metadata stream, as described below.

As already mentioned, certain IOs may require further processing. For example, with a chunk size of 4K, if an IO of 1K arrives, the splitter 106 can read 3K from the production memory 108, so the IO is 4K in size. The resulting chunk can then be sent to the aggregator 110. The data read from production memory 108 typically corresponds to the data adjacent to the 1K data. For example, the 1K IO and the 4K chunk are connected to the same address in production memory 108.

If the splitter 106 does not compensate for small IOs, the aggregator 110 can compensate for small IOs by reading from the production memory 108 . When the 1K-IO arrives at the aggregator 110, the aggregator 110 can: fail to acknowledge the IO, read from the production memory 108, and then acknowledge the original IO. This is typically done when the splitter 106 is serially splitting.

With serial splitting, the splitter 106 or streaming source waits for confirmation of the production data before sending the data to the aggregator 110. The aggregator can confirm separately. Complementing or compensating for small IOs can introduce latency. However, unaligned IOs are typically rare.

Therefore, the alignment of the IOs or write data is performed by the splitter 106 or the aggregator 110. More specifically, the data to be replicated or backed up is prepared for storage in secondary storage 112 .

As mentioned earlier, the journal can contain a data stream and a metadata stream. This is how the IO stream can be processed to produce this format. For example, the journal sent by splitter 106 or output by aggregator 110 may contain two streams: a data stream and a metadata stream.

2 Figure 12 shows an example of a data stream and a metadata stream that make up an example journal. In 2 shows that the journal 200 is divided into a data stream 202 and a metadata stream 204 . In this example, both data stream 202 and metadata stream 204 are organized as time-incremental lists of items. The data stream 202 contains the IOs. The IOs in data stream 202 are aligned at the deduplication boundaries. If the chunk size is 4K, each entry in data stream 202 contains data that is a multiple of 4K in size. Metadata stream 204 stores IO metadata, which may include, but is not limited to, IO volume, location, length, timestamp, tags, user-provided data, and/or descriptive data. As in 2 shown, each entry in metadata stream 204 has a corresponding entry in data stream 202.

Separating the journal 200 into a data stream 202 and a metadata stream 204 ensures that the IO alignment is not compromised or affected by the metadata.

For example, the journal 200 can be stored in one or more files. For example, the journal 202 can be divided into sections based on time intervals. The time intervals can be uniform, but do not have to be. However, data stream 202 and metadata stream 204 may be divided at the same intervals. Each journal section (referred to as a journal file) contains a portion of data stream 202 and a corresponding portion of metadata stream 204.

As previously mentioned, embodiments of the invention create backups without native snapshots. Rather, the images or backups can be generated or synthesized from the journal. In particular, given a full backup at time T and a journal file starting at time T and ending at time T + t, a backup can be synthesized for any time in the interval T + t. Since the data is deduplicated as previously described, the copy operations to create the new backup can be fast copy operations and are therefore efficient.

For example, to create a backup at time T1, a copy of a full backup from time T can be used. The entries in the journal starting at time T and ending at time T1 are then applied to the full backup - this is an example of journal or journal file scrolling. This synthesizes a full backup at time T1. When copying the journal entries, the IOs are copied from the journal to the location specified in the metadata stream.

Since the IOs are stored in the journal in the order in which they arrive, scrolling or applying the entries in the journal in order produces a correct representation of the data at time T1. Since the entries in the journal are arranged in the correct order, copying to the new backup is a fast copy that does not take up additional disk space. Even though the copy operations are fast copy operations (where fingerprints or signatures are copied rather than the actual data), these operations still take time. The time depends on the amount of journal being processed or rolled. Images synthesized in this way or backups can be created in a certain cadence, ad hoc (e.g. in response to a customer request), for internal purposes, disaster recovery purposes, business recovery purposes or the like.

For example, the secondary storage can be optimized for sequential IOs. The journal can be processed to match the secondary storage configuration. For example, the writes in the journal are sorted in an order that makes the writes more sequential while preserving the write order. For example, the IOs can be sorted in ascending order based on IO position or address. If two write processes (completely or partially) overlap, the (chronologically) later IO should be further back in the sorting. If an IO is completely covered by one or more later IOs, at least the IO being overwritten can be skipped since it will be overwritten.

3 shows a more detailed view of the data protection system and illustrates the way in which backups and the journal are stored. In 3 a splitter 302 is shown sending data to an aggregator 304 . The aggregator 304 can send streams of data that together form a journal.

The aggregator 304 may perform some processing such as B. the previously described boundary alignment (boundary alignment) and batching (batching) of the data for large IO transfers to the secondary storage 330. The aggregator 304 can use a temporary storage 306 for these purposes.

The aggregator can generate a stream of data that is representative of a journal. Journal 320 may include metadata stream 306 and data stream 308 . The journal 320 can be used to create or synthesize backups. 3 shows backups that can be synthesized at a specific cadence. The data or backups may include a backup 310, which may correspond to a time T0. Using the journal file 312 corresponding to a time interval of the journal 320, the backup 314 can be created from the backup 310 and the journal file 312. Thus, the backup 314 may correspond to a time T1. With the help of the backup 314 and the journal file 316, a backup can be created which corresponds to the time T2. So the journal or parts of it can be used to synthesize backups. As mentioned, these backups can include signatures, which allows for a quick copy to be performed. The actual chunks 318 may also be stored in secondary storage or other storage.

In this example, the cadence at which the backups are taken can be balanced with the number of full backups and the desired RPO. A longer cadence may result in a higher RPO, while a shorter cadence may lower the RPO, but may also impact secondary storage 330 capacity.

In other words, it is difficult to keep a single frame and the journal because the time it takes to scroll the journal to any given point in time can be significant. Creating a full backup for each point in time would allow older images to be deleted. However, this approach can require significant storage space. By choosing the cadence these competing concerns of the number of full backups and the rolling time of the journal can be balanced.

Secondary storage 330 may also provide the ability (e.g., via a controller or other manager) to free up disk space. The older the backups become, the less the need for a full resolution. For example, older full backups can be kept and at least the corresponding journal files can be deleted, since these journals are included in the full backups. Alternatively, older backups can be selectively deleted. Instead of one backup per hour, the number of backups can be reduced to one per day or one per week.

Newer images can be saved in full resolution. Consequently, the newer images offer any-point-in-time functionality. This functionality is reduced as the images age. For example, and if all journal information remains, full images can be deleted without data loss (except for the first backup). However, restoring to a specific point in time can take considerable time to scroll the journal.

Embodiments of the invention are able to create full backups in a certain cadence. However, the decision as to when to create a backup does not have to be determined by a chronological cadence. For example, a new backup can be created based on the number of IOs or the amount of data in the journal. For example, a new backup can be created every 100 MB. Alternatively, backups can be created based on processor/memory resources for rolling or based on expected rolling time. In another example, backups can be created for compliance reasons or based on user requirements.

If the parallelism of updating the image during scrolling is limited (e.g. due to the number of write handles that can open a file), when copying quickly the full backup can be divided into several slabs (e.g. 16- GB slabs) and each slab can be processed in parallel. After the IOs are rolled, the slabs are merged to form the full backup. This is an optimization for scroll speed.

When scrolling the image, the metadata can be analyzed to look for IOs that have been written multiple times in the interval to be processed. Only the last one needs to be copied.

4 shows an example of a procedure for creating backups. Method 400 may begin with partitioning/splitting 402 a source IO stream. The IO stream can occur on a host and be associated with one or more applications. The IO stream can be associated with a specific volume or a range of volumes. For example, the IO stream may include writes by an application to production storage, and the IO stream may be received by a splitter that splits the IO stream. The splitter can send the original IO stream to production storage, and a copy of the IO stream is sent to a data protection system or aggregator. The IO stream can be transmitted in accordance with an IO pattern of the source.

The IO stream is aggregated 404 by the data protection system or an aggregator. Aggregating 404 the IO stream may include splitting the IO stream into a data stream and a metadata stream (if necessary or if not already done by the splitter). The aggregator can also perform targeting and other functions as previously described. The data stream and the metadata stream together form the journal. The journal can be transferred to secondary storage. The journal is then stored 406 in secondary storage. When storing the journal, the data stream and metadata stream may be kept separate. Additionally, the journal may be divided into journal files, with each journal file corresponding to an interval that may be based on various factors such as time, amount of data, RPO expectations, or the like, or a combination thereof.

Once the journal is saved (or while the journal is being saved, at least because the journal is received as a stream and not necessarily stopping), backups can be generated from the journal 408.

For example, the data protection system is started with a full backup before the start of the journal. A new backup can then be created by scrolling the journal relative to the backup. This process can be continued so that the backups can be created based on previous backups and the journal. Over time, parts of the journal and/or existing backups/images may be erased.

Embodiments of the invention, such as the examples disclosed herein, can be advantageous in a number of ways. For example, and as will be apparent from the present disclosure, one or more embodiments of the invention provide one or more beneficial and unexpected effects in any combination, some examples of which are listed below. It should be noted that such effects are not intended nor should they be construed as limiting the scope of the claimed invention in any way. It is further noted that nothing herein should be construed as an essential or indispensable element of any invention or embodiment. Rather, various aspects of the disclosed embodiments can be combined in a variety of ways to define further embodiments. Such other embodiments are considered to be within the scope of this disclosure. Likewise, none of the embodiments that fall within the scope of this disclosure should be construed as solving any particular problem or limited to solving any particular problem or problems. Also, none of these embodiments should be construed as implementing or limited to implementing any particular technical effect(s) or solution(s). Finally, it is not necessary for every embodiment to implement every advantageous and unexpected effect disclosed herein.

Aspects of exemplary operating environments for various embodiments of the invention are discussed below. This discussion is not intended to limit the scope of the invention or the applicability of the embodiments in any way.

In general, embodiments of the invention may be implemented in connection with systems, software, and components that individually and/or collectively implement and/or cause implementation of PiT backup creation operations. Such operations may include, but are not limited to, data read/write/erase operations, data deduplication operations, data backup operations, data restore operations, data cloning operations, data archiving operations, PiT operations, synthesis operations, and disaster recovery operations. More generally, the scope of the invention includes any operating environment in which the disclosed concepts may be useful.

At least some embodiments of the invention enable the disclosed functionality to be implemented in existing data protection platforms, such as e.g. B. the Dell-EMC NetWorker and Avamar platforms and associated backup software, as well as storage environments such as the Dell-EMC Datadomain storage environment. In general, however, the scope of the invention is not limited to any particular backup platform or data storage environment.

New and/or modified data collected and/or generated in connection with some embodiments may be stored in a backup environment, which may take the form of a public or private cloud storage environment, a local (on-premise) storage environment, and hybrid Can accept storage environments that contain public and private elements. Each of these example storage environments may be partially or fully virtualized. The storage environment may include or consist of a data center capable of performing read, write, delete, backup, restore and/or cloning operations requested by one or more clients or other elements of the operating environment are initiated. When a backup includes groups of data, each with different characteristics, that data can be associated and stored with different respective targets in the storage environment, each target corresponding to a group of data with one or more particular characteristics.

Examples of public cloud storage environments that may be used in connection with embodiments of the invention include Microsoft Azure, Amazon AWS, and Google Cloud. In general, however, the scope of the invention is not limited to the use of any particular type or implementation of cloud storage.

In addition to the storage environment, the operating environment may also include one or more clients capable of collecting, modifying, and creating data. As such, a particular client may use or otherwise be associated with one or more instances of one or more applications that perform such operations on data.

Devices in the operating environment may take the form of software, physical machines, or virtual machines (VM), or any combination thereof, but no particular device implementation or configuration is required for any embodiment. Also, the components of the data protection system, such as databases, storage servers, storage volumes (LUNs), storage disks, replication services, backup servers, recovery servers, backup clients, and recovery clients can also take the form of software, physical machines or virtual machines (VM), with no embodiment requiring a specific component implementation. When using VMs, a hypervisor or other VMM (Virtual Machine Monitor) can be used to create and control the VMs. The term VM includes, but is not limited to, any virtualization, emulation, or other representation of one or more computer system elements, such as B. Computer system hardware. A VM can be based on one or more computer architectures and provides the functionality of a physical computer. A VM implementation may involve hardware and/or software, or at least involve the use of hardware and/or software. A mapping of a VM can take various forms, such as: B. a .VMDK file.

As used herein, the term "data" is broad. Thus, for example and not limited to, this term includes data segments such as may be produced by data stream segmentation processes, data blocks (chunks), atomic data, emails, objects of any kind, files of any kind including media files, word processing files, spreadsheet files, and Database files, as well as contacts, directories, subdirectories, volumes, and any group of one or more of the foregoing.

Exemplary embodiments of the invention are applicable to any system capable of storing and processing various types of objects in analog, digital, or other form. Although terms such as document, file, segment, block, or object may be used as examples, the principles of the disclosure are not limited to any particular form of representing and storing data or other information. Rather, these principles are equally applicable to any object capable of representing information.

As used herein, the term "backup" or "backup" is to be interpreted broadly. As such, examples of backups that may be used in connection with embodiments of the invention include, but are not limited to, full backups, partial backups, clones, snapshots, and incremental or differential backups.

Some other exemplary embodiments of the invention follow. These are presented by way of example only and are not intended to limit the scope of the invention in any way.

Embodiment 1. A method comprising splitting an IO stream received from a source, aggregating the IO stream and generating a journal from the IO stream, the journal comprising a data stream and a metadata stream, storing the journal in one Secondary storage and synthesizing backups from the journal.

Embodiment 2. The method of embodiment 1, further comprising creating the backups according to a cadence, the cadence being based on at least one of the following factors: time, journal size, expected journal roll time, expected RPO.

Embodiment 3. The method of embodiment 1 and/or 2, further comprising dividing the journal into journal files, each journal file containing a portion of the data stream and a corresponding portion of the metadata stream.

Embodiment 4. The method of embodiment 1, 2 and/or 3, further comprising creating a new backup from a previous backup and one of the journal files.

Embodiment 5. The method of embodiment 1, 2, 3 and/or 4, further comprising aligning the metadata stream.

Embodiment 6. The method of embodiment 1, 2, 3, 4 and/or 5, further comprising performing a fast copy to synthesize each of the backups.

Embodiment 7. The method of embodiment 1, 2, 3, 4, 5 and/or 6, further comprising storing the backups as backup and journal files.

Embodiment 8. The method of embodiment 1, 2, 3, 4, 5, 6 and/or 7, further comprising setting a cadence for synthesizing the backups to balance an RPO with storage space.

Embodiment 9. The method of embodiment 1, 2, 3, 4, 5, 6, 7 and/or 8, further comprising retrieving additional data from production data when an IO is less than a block size.

Embodiment 10. The method of embodiment 1, 2, 3, 4, 5, 6, 7, 8 and/or 9, wherein the metadata stream includes one or more of the following: IO volume, location length, timestamp, tagging , user information, descriptive data, each entry in the metadata stream having a corresponding entry in the data stream.

Embodiment 11. The method as described in any combination of embodiments 1 to 10, wherein the method is performed by a data protection system, a splitter, an aggregator, a processor, and/or secondary storage systems.

Embodiment 12. The method as described in any one of embodiments 1 to 11, wherein the secondary storage is deduplication storage and another of the storage media types is object storage.

Embodiment 13. Methods for performing any of the operations, methods, or processes disclosed herein, or any portion thereof.

Embodiment 14. A non-transitory storage medium storing instructions executable by one or more hardware processors to perform the operations of any one or more of Embodiments 1 of 13 or portions thereof.

The embodiments disclosed herein may involve the use of a special purpose or general purpose computer with various computer hardware or software modules, as discussed in more detail below. A computer may include a processor and computer storage media carrying instructions that, when executed by the processor and/or caused to be executed by the processor, perform one or more of the methods disclosed herein, or one or more parts of any of the methods disclosed.

As mentioned above, embodiments within the scope of the present invention also encompass computer storage media that are tangible media that carry or have computer-executable instructions or data structures stored thereon. Such computer storage media can be any available physical media that can be accessed by a general purpose or special purpose computer.

By way of example and not limitation, such computer storage media may include hardware memory such as solid state disk/device (SSD), RAM, ROM, EEPROM, CD-ROM, flash memory, phase change memory (PCM), or other optical disk storage , magnetic disk drives or other magnetic storage devices or any other hardware storage devices 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 a general purpose or special purpose computer system to implement the disclosed functionality of the invention. Combinations of the above media should also be included within the scope of computer storage media. Such media are also examples of non-transitory storage media, and non-transitory storage media also include cloud-based storage systems and structures, although the scope of the invention is not limited to these examples of non-transitory storage media.

Computer-executable instructions include, for example, instructions and data that cause a general purpose computer, special purpose computer, or special purpose processing device to perform a particular function or group of functions. Although the subject matter has been described in language specific to structural features and/or methodical acts, the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts disclosed herein are disclosed as example forms of implementing the claims.

As used herein, the term "module" or "component" may refer to software objects or routines that execute on the computer system. The various components, modules, engines, and services described herein may be implemented as objects or processes executing on the computer system, such as separate threads. While the system and methods described herein can be implemented in software, implementations in hardware or a combination of software and hardware are also possible and contemplated. As used herein, a “computing unit” or “computing entity” can be any computing system as defined above, or any module or combination of modules running on a computing system.

In at least some cases, a hardware processor is provided that is capable of executing executable instructions for performing a method or process, such as the methods and processes disclosed herein. The hardware processor may or may not include an element of other hardware, such as a B. the computing devices and systems disclosed herein.

With regard to computing environments, embodiments of the invention may be used in client-server environments, ie network or local environments, or any other suitable net environment. Suitable operating environments for at least some embodiments of the invention include cloud computing environments in which one or more clients, servers, or other machines may reside and operate in a cloud environment.

One or more entities disclosed or implied in the figures and/or elsewhere in the present invention may take the form of or include a physical computing device, or be implemented on or hosted by a physical computing device. When any of the foregoing includes or consists of a virtual machine (VM), that VM may represent a virtualization of any combination of the physical components.

The physical computing device may include memory, which may include one, some, or all of the following: random access memory (RAM), non-volatile random access memory (NVRAM), read-only memory (ROM) and persistent storage, one or more hardware processors, non-transitory storage media, UI device and data storage. One or more of the storage components of the physical computing device may take the form of solid state device (SSD) storage. Additionally, one or more applications may be provided that include instructions executable by one or more hardware processors to perform any of the operations disclosed herein, or portions thereof.

Such executable instructions may take various forms, including, for example, instructions that are executable to perform any method disclosed herein, or part thereof, and/or that are executable from/at a location, whether on-premises at an enterprise or cloud storage location, client, data center, or backup server to perform any of the functions disclosed herein. Likewise, such instructions may be executable to perform all other operations and methods disclosed herein, and any portion thereof, including but not limited to data protection operations.

The present invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

QUOTES INCLUDED IN DESCRIPTION

This list of documents cited by the applicant was generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Patent Literature Cited

• US16785288 [0001]

Claims (20)

Method comprising: splitting an IO stream received from a source; aggregating the IO stream and generating a journal from the IO stream, the journal comprising a data stream and a metadata stream; storing the journal in secondary storage; and Synthesizing backups from the journal. procedure according to claim 1 , further comprising generating the backups according to a cadence, the cadence being based on at least one of: time, journal size, expected journal roll time, expected RPO. procedure according to claim 1 , further comprising dividing the journal into journal files, each journal file containing a portion of the data stream and a corresponding portion of the metadata stream. procedure according to claim 3 , further comprising creating a new backup from a previous backup and one of the journal files. procedure according to claim 1 , which further includes aligning the metadata stream and deduplication of the data. procedure according to claim 1 , further comprising performing a quick copy to synthesize each of the backups. procedure according to claim 1 , further comprising storing the backups as backup and journal files. procedure according to claim 1 , which further includes setting a cadence for the synthesis of the backups to balance an RPO with disk space. procedure according to claim 1 , further comprising retrieving additional data from production data when an IO is less than a block size. procedure according to claim 1 , wherein the metadata stream contains one or more of the following elements: IO volume, location length, timestamp, identifier, user information, descriptive data, each entry in the metadata stream having a corresponding entry in the data stream. Non-transitory storage medium that stores instructions executable by one or more hardware processors to perform operations, including: splitting an IO stream received from a source; aggregating the IO stream and generating a journal from the IO stream, the journal comprising a data stream and a metadata stream; storing the journal in secondary storage; and Synthesizing backups from the journal. Non-transitory storage medium according to claim 11 , the operations further comprising creating the backups according to a cadence, the cadence being based on at least one of: time, journal size, expected journal roll time, expected RPO. Non-transitory storage medium according to claim 11 , the operations further comprising dividing the journal into journal files, each journal file containing a portion of the data stream and a corresponding portion of the metadata stream. Non-transitory storage medium according to Claim 13 , the operations further comprising creating a new backup from a previous backup and one of the journal files. Non-transitory storage medium according to claim 11 , the operations further comprising aligning the metadata stream and deduplication of the data. Non-transitory storage medium according to claim 11 , the operations further comprising performing a fast copy to synthesize each of the backups. Non-transitory storage medium according to claim 11 , the operations further comprising storing the backups as backup and journal files. Non-transitory storage medium according to claim 11 , the operations further comprising setting a cadence for the synthesis of the backups to balance an RPO with storage space. Non-transitory storage medium according to claim 11 , the operations further comprising retrieving additional data from production data when an IO is less than a block size. Non-transitory storage medium according to claim 11 , wherein the metadata stream contains one or more of the following elements: IO volume, location length, timestamp, identifier, user information, descriptive data, each entry in the metadata stream having a corresponding entry in the data stream.

Images