Patent Description:
In order to prevent data loss, data can be backed up. Data backup operations produce backup images. A backup image includes a backup copy of application data or the contents of a given storage entity, such as a file system or disk drive. Such backup images can be stored and/or maintained in remote cloud-based storage devices in the form of cloud backups for retrieval and restoration at a later time, for example, in case of hardware failure, and the like.

Data replication involves making duplicate copies of data and improves reliability, fault-tolerance, and/or accessibility. The purpose of data replication is to prevent data loss if failures or disasters occur in one location. If such failures or disasters do occur that destroy or damage a copy of the data in one location, the copy of the data at a secondary site can be accessed. For these purposes, among others, replicated data can also be stored and/or maintained in remote cloud-based storage devices, for example, in the form of replicas.

Backup and replication solutions each have their own advantages and drawbacks, and are therefore frequently implemented (and packaged) together, for example, in cloud backup and cloud-based disaster recovery (DR) services (e.g., as backup destinations and DRaaS (Disaster Recovery as a Service)). For example, backup involves making a secondary copy of data that can be restored to use if the primary copy becomes lost or unusable. Backup images include a point-in-time copy of primary data typically taken on a repeated cycle (e.g., daily, monthly, yearly, and the like). On the other hand, replication is either synchronous or asynchronous, and transfer of data to a remote copy of achieved either immediately or within a short time delay, respectively. In modern computing environments, both backup and replication require large amounts of data to be transmitted over networks (e.g., to a cloud backup and DR service provider).

In addition, because data corruption or user file deletion is immediately or very quickly replicated to a secondary copy, replication is ineffective as a backup method. Further, because replication only maintains only copy of data at a cloud location, a replicated copy does not include historical versions of data (e.g., from preceding weeks, months, and the like). On the contrary, because a backup copy is a point in time copy of data, full and incremental backup images can be created, thus providing appreciable storage benefits.

Therefore, it is not surprising that modern businesses and organizations implement both backup and replication solutions, for example, to protect and guarantee the same data. Unfortunately, such modern businesses and organizations bear significant separate costs related to network bandwidth - for cloud backups, and separately, for cloud-based DR services. For example, the same data transmitted from on premise storage to cloud-based storage as part of a backup operation, has to be re-transmitted from on premise storage to cloud-based storage as part of a replication operation. This re-transmission of data is not only redundant and discourages cloud adoption, but also results in costly and wasteful network bandwidth utilization.

<CIT> describes a recovery system and method for performing site recovery using replicated recovery-specific metadata. However, this document does not disclose, at least, a method comprising: creating a replica of a virtual machine, wherein the replica comprises replicated metadata, wherein the replicated metadata comprises a replica of metadata, the metadata comprises one or more data locations of one or more blocks of data, and the one or more data locations are configured to be used to restore one or more applications executing on the virtual machine; performing a backup operation at the secondary site, wherein the performing the backup operation comprises generating a backup image from the replicated data, and storing the backup image and the replicated metadata at the secondary site, the backup operation is performed at the secondary site by a backup proxy, and the backup proxy is instantiated at the secondary site by a backup server at the primary site.

Other advantageous embodiments are indicated in the appended dependent claims. Disclosed herein are methods, systems, and processes to perform backup operations using replicas. One such method involves creating a replica of a virtual machine as part of a replication operation. In this example, the replica includes data associated with the virtual machine and metadata associated with applications executing on the virtual machine. The method then performs a backup operation by generating a backup image from the replica using the metadata.

In one embodiment, the metadata includes information for granular restore of the virtual machine, is generated by quiescing the applications, and is stored on the virtual disks. In another embodiment, generating the backup images includes generating a snapshot that identifies a reference point in time to create the backup image of the data prior to performing the backup operation, retrieving the metadata from the replica, and generating a full backup image or an incremental backup image based on the reference point in time.

The metadata includes data locations of blocks of the data, and the data locations are used by the backup server to restore the virtual machine from the backup image. The backup operation is performed by a backup proxy instantiated on a cloud computing device as part of performing the backup operation, the backup proxy is another virtual machine, a container, or a server-less module, the quiescing of the applications is performed by a replication agent executing on the virtual machine, the metadata is generated by a backup agent executing on the virtual machine, and the replication operation is performed by the replication agent.

In certain embodiments, generating the backup images includes generating the snapshot of the data at the reference point in time, generating the backup image in a backup format, mounting the snapshot, retrieving granular metadata for the one or more applications from the metadata in the replica, and sending the granular metadata to the backup server.

The foregoing is a summary and thus contains, by necessity, simplifications, generalizations and omissions of detail; consequently those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any limiting. Other aspects, features, and advantages of the present disclosure, as defined solely by the claims, will become apparent in the non-limiting detailed description set forth below.

The present disclosure may be better understood, and its numerous objects, features and advantages made apparent to those skilled in the art by referencing the accompanying drawings.

While the disclosure is susceptible to various modifications and alternative forms, specific embodiments of the disclosure are provided as examples in the drawings and detailed description. It should be understood that the drawings and detailed description are not intended to limit the disclosure to the particular form disclosed. Instead, the invention is defined by the scope of the claims.

Data backup and data replication are not mutually exclusive, and are thus typically implemented together by modern businesses and organizations to safeguard and provision the same data. For example, cloud-based service providers frequently provide both cloud-based backup (e.g., for data restoration, data security, and the like) and cloud-based replication services (e.g., Disaster Recovery as a Service (DRaaS), and the like).

Backup operations produce a point in time copy of data that includes a copy of the operating system (OS) and the data associated with a computing device and/or virtual machine, including the system state and application configurations. The backup is typically saved as a single file called a backup image (e.g., on a cloud storage device), and the backup process uses snapshots to ensure that even deleted files and empty disk blocks are backed up. Therefore, backup operations produce backup metadata that is collected during the backup process and stored as part of a backup image to identify the state of a system and corresponding applications at a point in time (e.g., for granular restore purposes). Such backup metadata can be used to create future incremental backup images, and thus provides significant network and storage savings, as well as the capability to restore a computing device from a backup image by reassembling the computing device's data from one or more previous backup images.

On the other hand, replication operations produce an identical copy of data associated with a computing device and/or virtual machine. Such identical copies are stored as replicas (e.g., on cloud storage devices). Because a replication process only produces a single identical copy of data (e.g., either synchronously or asynchronously, which can then be copied back in full in the case of a disaster), the replication process does not (and indeed has no need to) replicate metadata associated with replicated data (e.g., information regarding historical versions of data, block and/or file location information, block-level information for granular restore, data location(s), and the like). Therefore, replicas do not contain information that enables the creation of backup images and/or permits the granular restore of data from such backup images.

Unfortunately, and as previously noted, in modern computing environments, both backup and replication operations involve the transmission of large amounts of data over networks. Because enterprises implement both backup and replication solutions to protect and guarantee the same data, these enterprises bear significant and distinct costs related to network bandwidth - for cloud backups, and separately, for cloud-based DR services. For example, the same data transmitted from on premise storage to cloud-based storage as part of a backup operation, has to be re-transmitted from on premise storage to cloud-based storage as part of a replication operation. This re-transmission of data is not only redundant and discourages cloud adoption, but also results in costly and wasteful network bandwidth utilization.

Disclosed herein are methods, systems, and processes to generate full or incremental backup images using replicas (e.g., replicated data), while at the same time requiring only a single transmission of the data as part of a replication operation.

<FIG> is a block diagram <NUM> of a backup and replication computing system, according to one embodiment. As shown in <FIG>, an example integrated backup and replication computing environment includes at least virtual machines <NUM>(<NUM>)-(N) that are communicatively coupled with (corresponding) virtual disks <NUM>(<NUM>)-(N). It should be noted that in addition to virtual machines and virtual disks, the example integrated backup and replication computing environment can also include physical computing devices and physical storage disks.

Virtual machine <NUM>(<NUM>) implements at least a backup agent <NUM>(<NUM>) and a replication agent <NUM>(<NUM>). Backup agent <NUM>(<NUM>) generates metadata associated with a backup operation and replication agent <NUM>(<NUM>) quiesces one or more applications executing on virtual machine <NUM>(<NUM>) (e.g., instructs the applications to flush their in-memory data to virtual disk <NUM>(<NUM>)). Virtual disk <NUM>(<NUM>) stores data <NUM>(<NUM>) and metadata <NUM>(<NUM>) (e.g., backup metadata generated by backup agent <NUM>(<NUM>)). Virtual machines <NUM>(<NUM>)-(N) (including virtual disks <NUM>(<NUM>)-(N)) are part of computing systems <NUM>(<NUM>)-(N)), and are communicatively coupled to a backup server <NUM>.

Backup server <NUM> performs backup, replication, and/or restore operations, and implements at least a backup manager <NUM>, a replication manager <NUM>, and a catalog <NUM>. Backup manager <NUM> manages backup operations to a cloud computing device <NUM> (e.g., in conjunction with a backup proxy <NUM>), replication manager <NUM> manages replication operations performed to cloud computing device <NUM> (e.g., by replication agents <NUM>(<NUM>)-(N)), and catalog <NUM> is stored and used by backup server <NUM> to perform restore operations (e.g., granular restore).

As shown in <FIG>, cloud computing device <NUM> is communicatively coupled to backup server <NUM> by network <NUM> and implements at least a disaster recovery (DR) coordinator <NUM> (which provides DRaaS service(s)) and backup proxy <NUM> (instantiated to perform backup operations). Cloud computing device <NUM> is communicatively coupled to a cloud storage device <NUM>, and together with cloud storage device <NUM> is part of cloud computing systems <NUM>(<NUM>)-(N). Cloud storage device <NUM> stores replicas <NUM>(<NUM>)-(N) and backup images <NUM>(<NUM>)-(N).

Backup server <NUM>, physical computing devices that are part of computing systems <NUM>(<NUM>)-(N), and/or cloud computing device <NUM> can be any of a variety of different computing devices, including a server, personal computing device, laptop computer, cellular phone, or the like. Network <NUM> can be any type of network and/or interconnection (e.g., the Internet, a Wide Area Network (WAN), and the like). Cloud storage device <NUM> and/or physical storage devices associated with computing systems <NUM>(<NUM>)-(N) can include one or more of a variety of different storage devices, including hard disks, compact discs, digital versatile discs, solid state drive (SSD) memory such as Flash memory, and the like, or one or more logical storage devices such as volumes implemented on one or more such physical storage devices.

In one embodiment, replication agent <NUM>(<NUM>) implemented by virtual machine <NUM>(<NUM>) creates a replica of virtual machine <NUM>(<NUM>) as part of a replication operation. In this example, the replica (e.g., replica <NUM>(<NUM>)) includes data associated with virtual machine <NUM>(<NUM>) (e.g., data <NUM>(<NUM>)) and metadata associated with applications executing on virtual machine <NUM>(<NUM>) (e.g., metadata <NUM>(<NUM>). Backup proxy <NUM> then generates a backup image (e.g., backup image <NUM>(<NUM>)) from the replica using the metadata.

In some embodiments, metadata <NUM>(<NUM>) includes information for granular restore of virtual machine <NUM>(<NUM>) (e.g., data location(s), and the like). Replication agent <NUM>(<NUM>) generates and/or collects metadata <NUM>(<NUM>) by quiescing one or more applications executing on virtual machine <NUM>(<NUM>) (e.g., by instructing one or more applications to flush their in-memory data to virtual disk <NUM>(<NUM>) - thus, storing metadata <NUM>(<NUM>) on virtual disk <NUM>(<NUM>)). In this example, metadata <NUM>(<NUM>) includes locations of blocks of data and the data locations are used by backup server <NUM> to restore virtual machine <NUM>(<NUM>) from backup image <NUM>(<NUM>), if needed.

In other embodiments, generating backup images includes generating a snapshot that identifies a reference point in time to create a backup image of data <NUM>(<NUM>) prior to performing the backup operations, retrieving metadata <NUM>(<NUM>) from replica <NUM>(<NUM>), and generating a full backup image or an incremental backup image based on the reference point in time. In this example, the backup operation (e.g., generating backup images) is performed by backup proxy <NUM> which is instantiated on cloud computing device <NUM> by backup manger <NUM> as another virtual machine, a container, or a server-less module.

In certain embodiments, generating backup images <NUM>(<NUM>)-(N) includes generating the snapshot of data (e.g., data <NUM>(<NUM>)-(N) of virtual machines <NUM>(<NUM>)-(N)) at the reference point in time, generating backup image <NUM>(<NUM>) in a backup format, mounting the snapshot, retrieving metadata <NUM>(<NUM>) for applications from replica <NUM>(<NUM>) (e.g., granular metadata captured by replication agent <NUM>(<NUM>) and replicated to cloud storage device <NUM> by replication manager <NUM> and DR coordinator <NUM>), and sending the granular metadata to backup server <NUM> (e.g., to be used as catalog <NUM> for granular restore).

As previously noted, replica <NUM>(<NUM>) contains replicated data of virtual machine <NUM>(<NUM>) and is stored in cloud storage device <NUM> in the same format as data <NUM>(<NUM>) is stored on virtual disk <NUM>(<NUM>). Therefore, replica <NUM>(<NUM>) a mirrored copy of data <NUM>(<NUM>) (e.g., there exists a <NUM>:<NUM> correspondence between data blocks of replica <NUM>(<NUM>) and data <NUM>(<NUM>)), and is thus useful for failover operations performed to cloud computing device <NUM>. For example, a cloud virtual machine can be created and/or instantiated from replica <NUM>(<NUM>).

On the other hand, and also as previously noted, a backup can be generated in a format that is different than the original data (e.g., as the result of incremental backups, deduplication, and the like). Therefore, a backup image, at least on its own, does not maintain a <NUM>:<NUM> correspondence between data blocks of backup image <NUM>(<NUM>) and data <NUM>(<NUM>). In addition, a backup image can be generated in a format that is different than the original format of data <NUM>(<NUM>). For example, data <NUM>(<NUM>) can be a single virtual machine disk image, where as backup image <NUM>(<NUM>) can include several one megabyte blocks.

<FIG> is a block diagram <NUM> of a backup and replication computing environment, according to one embodiment. As shown in <FIG>, cloud <NUM> (e.g., cloud computing systems <NUM>(<NUM>)-(N)) includes at least a backup proxy <NUM>, replicas <NUM>(<NUM>) and <NUM>(<NUM>), and DR coordinator <NUM>. DR coordinator <NUM> continuously replicates virtual machine disk images of virtual machines <NUM>(<NUM>) and <NUM>(<NUM>) to cloud <NUM> (e.g., a corresponding virtual machine disk image is created in cloud <NUM> and is continuously replicated to keep the virtual machine disk image in sync with virtual disk <NUM>(<NUM>)).

Backup server <NUM> monitors and manages quiescing and application granular restore (GRT) metadata gathering performed by on premise backup agents and replication agents (e.g., metadata of an email database and associated information such as emails, locations, files, and the like). When on premise replication agents (e.g., replication agents <NUM>(<NUM>)-(N)) perform replication, replication consistency checkpoints as part of the GRT metadata capture process. For example, when the need for a backup operation is conveyed to replication agent <NUM>(<NUM>) by backup agent <NUM>(<NUM>), replication agent <NUM>(<NUM>) quiesces application <NUM>(<NUM>) and sets a marker, a flag, or similar type of indicator indicating a consistent point in time for a backup operation to pick up from if and when the backup operation is performed in cloud <NUM> by backup proxy <NUM>. It should be noted that replication agents <NUM>(<NUM>)-(N) and backup agents <NUM>(<NUM>)-(N) can be implemented on guest virtual machines as well as by host hypervisors.

In one embodiment, to create a backup image on schedule through a DRaaS system (e.g., DR coordinator <NUM>), an on premise backup agent (e.g., backup agent <NUM>(<NUM>)) first interacts with a DRaaS replication agent (e.g., replication agent <NUM>(<NUM>)) indicating the need for a backup. Replication agent <NUM>(<NUM>) next performs application quiescing and invokes custom-action of backup agent <NUM>(<NUM>). For example, replication agent <NUM>(<NUM>) requests and/or instructs application <NUM>(<NUM>) to push in-memory data to virtual disk <NUM>(<NUM>), and backup agent <NUM>(<NUM>) registers a callback function with replication agent <NUM>(<NUM>).

As part of the custom-action, backup agent <NUM>(<NUM>) collects and stores high-level metadata (e.g., granular metadata such as metadata for emails in a database, data locations for application data, block-level information, and the like) on virtual disk <NUM>(<NUM>) (e.g., as metadata <NUM>(<NUM>)). Backup agent <NUM>(<NUM>) also conveys backup method information (e.g., whether the backup is a full backup or an incremental backup) to replication manager <NUM>. Next, replication manager <NUM>, in conjunction with replication agent <NUM>(<NUM>), synchronizes the captured metadata (e.g., granular metadata, GRT metadata, and the like) to cloud <NUM>. For example, after replication agent <NUM>(<NUM>) completes application quiescing, backup agent <NUM>(<NUM>) captures metadata information and stores the metadata information (e.g., in a file on virtual disk <NUM>(<NUM>) and/or as metadata <NUM>(<NUM>)). This captured and stored metadata is replicated to cloud <NUM> as part of a replication operation (e.g., stored as part of replicas <NUM>(<NUM>)).

<FIG> is a block diagram <NUM> of a backup and replication computing environment, according to one embodiment. After granular metadata is synchronized with cloud <NUM>, DR coordinator <NUM> invokes backup proxy <NUM>. Backup proxy <NUM>, which as noted previously can be instantiated in cloud <NUM> as a virtual machine, a container, or a server-less module by backup manager <NUM>, generates a snapshot of data at this point in time (e.g., data <NUM>(<NUM>) replicated as replica <NUM>(<NUM>) with a replication consistency checkpoint) and generates a backup image (e.g., backup image <NUM> in a backup-friendly format from the replication consistency checkpoint if backup image <NUM> is generated as an incremental backup image) in backup-friendly storage provided by cloud computing device <NUM> (e.g., writing a block or list of blocks to a block blob, appending blocks to an append blob, writing pages to a page blob, and the like).

Backup proxy <NUM>, which can be instantiated on-demand in cloud <NUM>, then mounts the snapshot and using information gathered from application quiescing (e.g., application information), gathers, extracts, and/or collects full item-level granular metadata from files and applications. For example, backup proxy <NUM> gathers granular metadata for emails in an email database on a machine image (e.g., replica <NUM>(<NUM>)). This granular metadata is read by backup server <NUM> and is stored in catalog <NUM> (e.g., as a rich granular catalog of backup image <NUM>).

As previously noted, backup agent <NUM>(<NUM>) sends information to replication agent <NUM>(<NUM>) informing replication agent <NUM>(<NUM>) that a full backup has been requested by backup manager <NUM>. Replication agent <NUM>(<NUM>) uses this point in time as a base to maintain and/or track changed data (e.g., deltas or logs) as part of the replication process. In addition, depending on whether backup proxy <NUM> is creating a full backup image or an incremental backup image, backup proxy <NUM> reads all or only changed data from the reference/base point in time to create the corresponding backup image.

<FIG> is a flowchart <NUM> of a process for generating backup images from replicas and performing granular restore, according to one embodiment. The process begins at <NUM> by receiving a replica of a virtual machine (e.g., replication agent <NUM>(<NUM>) implemented on virtual machine <NUM>(<NUM>) sends data <NUM>(<NUM>) and metadata <NUM>(<NUM>) to cloud computing device <NUM>). At <NUM>, the process invokes a backup proxy (e.g., backup proxy <NUM> which can be instantiated on-demand in cloud <NUM> by backup manager <NUM> as a virtual machine, a container, a server-less module, and the like). It should be noted that the backup proxy is invoked and the remaining steps of <FIG> are performed according to a backup schedule (e.g., when a backup agent communicates with a replication agent regarding the need for a backup operation). At <NUM>, the process takes a snapshot of data (e.g., data <NUM>(<NUM>) in replica <NUM>(<NUM>)), and at <NUM> creates a backup image in backup format (e.g., backup proxy <NUM> creates backup image <NUM> on backup storage <NUM> as shown in <FIG>). At <NUM>, the process mounts the snapshot, and at <NUM>, extracts granular metadata (e.g., from metadata <NUM>(<NUM>)) in the replica (e.g., replica <NUM>(<NUM>)). At <NUM>, the process sends the backup image and granular metadata to a backup server (e.g., backup image <NUM> and GRT metadata to backup server <NUM> as shown in <FIG>), and at <NUM>, determines if there is more replicated data. If there is more replicated data (and a backup operation followed by a restore operation applicable to the newly replicated data has been requested), the process loops to <NUM>. Otherwise, the process ends.

<FIG> is a flowchart 500A of a process for storing metadata for replication, according to one embodiment. The process begins at <NUM> by instructing (or requesting) a replication agent (e.g., replication agent <NUM>(<NUM>)) to begin backup operation configuration (e.g., that a full backup has been requested and to set a replication consistency checkpoint). At <NUM>, the process receives invocation of custom action from the replication agent after application quiescing has been performed (e.g., by backup agent <NUM>(<NUM>)). The process ends at <NUM> by storing application information (e.g., GRT metadata with data location(s), and the like) associated with the application(s).

<FIG> is a flowchart 500B of a process for replicating metadata, according to one embodiment. The process begins at <NUM> by receiving backup operation instructions from a backup agent (e.g., backup method information from backup agent <NUM>(<NUM>)). At <NUM>, the process performs application quiescing (e.g., in-memory data flush), and at <NUM>, invokes custom-action of the backup agent (e.g., backup agent <NUM>(<NUM>) registers a call back function with replication agent <NUM>(<NUM>)). At <NUM>, the process receives metadata (e.g., high-level metadata about applications, their data locations, and the like, gathered by backup agent <NUM>(<NUM>) by performing one or more queries). The process ends at <NUM> by replicating the metadata along with virtual machine data to cloud storage (e.g., to DR coordinator <NUM>, cloud computing device <NUM> and/or cloud <NUM> as a part of a replica).

<FIG> is a flowchart <NUM> of a process for storing metadata for restore operations, according to one embodiment. The process begins at <NUM> by determining whether replication synchronization is complete. If replication synchronization (e.g., metadata synchronization to compute-friendly cloud storage) is incomplete, the process, at <NUM>, waits. However, if replication synchronization is complete, the process, at <NUM>, takes a snapshot of the replicated data (e.g., data in a replica), and at <NUM>, generates a backup image in a backup format. At <NUM>, the process mounts the snapshot, and at <NUM>, gathers item-level granular metadata for files and applications from the replica. At <NUM>, the process stores the granular metadata for future restore operations from the backup image. At <NUM>, the process determines if there is more replicated data (e.g., whether a new backup operation has been requested). If there is more replicated data, the process loops to <NUM>. Otherwise, the process ends.

<FIG> is a flowchart 700A of a process for tracking changed data as part of replication, according to one embodiment. The process begins at <NUM> by receiving information from a backup agent indicating that a full backup has been requested. The process ends at <NUM> by tracking changed data or log information from this (reference) point in time as part of the replication operation (e.g., a replication consistency checkpoint).

<FIG> is a flowchart 700B if a process for generating full or incremental backups from replicas, according to one embodiment. The process begins at <NUM> by determining whether a backup proxy is creating a full backup or an incremental backup. If backup proxy is creating a full backup, at <NUM>, the process reads all data from the reference point in time, and ends at <NUM> by generating a full backup image. However, if the backup proxy is creating an incremental backup, the process, at <NUM>, only reads changed data from the reference point in time, and ends at <NUM> by generating an incremental backup image.

In this manner, the methods, systems, and processes described herein enable cloud backups to be created from DRaaS replicas as well as providing support for rich granular metadata for backups (e.g., for granular restore). These methods, systems, and processes eliminate the need for performing separate backups from on premise data centers to cloud storage when DRaaS replication is deployed by directly constructing full or incremental backup images along with full granular metadata from replicas stored in the cloud, and thus provide significant benefits with respect to bandwidth usage and network costs.

In one embodiment, application quiescing is performed even when there is no requirement to do so and/or even the applicability of granular restore is present. For example, application quiescing is performed so that a backup is application consistent. In another embodiment, application metadata for granular restore, and the like, includes information such as drives (e.g., C:, D:, and the like), volumes installed on virtual and/or physical machines, applications installed on the virtual and/or physical machines, and associated information (e.g., database version information, database names, and the like), as well as the location of files and folders that contain application data.

In some embodiments, metadata required to generate incremental backups from a replica can be of at least two types. First, in cases where a virtual machine has built in data block change tracking capability, the metadata can include identifiers that capture the state of the virtual machine's disks at the time of a snapshot that is taken for backup. Therefore, when generating an incremental backup from the replica, the underlying change tracking mechanisms can be queried to get a list of changed blocks between the (change tracking identifiers of the) previous full or incremental backups up to a current change tracking identifier. Once a list of changed data blocks is obtained, an incremental backup including those changed data blocks can be created. Second, in cases where the underlying change tracking mechanism does not exist or cannot be used, a replication agent and/or a replication system can keep track of changed blocks (since the replication system detects and replicates only changed blocks) between previous and current snapshots. When creating backups from replicas, a backup proxy can then use this information to obtain the list of changed data blocks since the previous full or incremental backup, and create an incremental backup that includes only those changed data blocks.

In other embodiments, a single backup image may not necessarily be a single file and may include multiple objects created in cloud storage. In certain embodiments, the use of snapshots in the systems, methods, and processes described herein can be at least two- fold. First, a snapshot can be used to obtain a frozen view (e.g., in the case where data is changing while a backup is ongoing resulting in inconsistent backups). In this case, a snapshot provides a view where data is not changing. Second, applications are quiesced first and a snapshot is then generated. This process results in application consistency and application consistent backups because quiescing causes applications to flush their in-memory data, and the like, to disk so that the state of the disk becomes application-consistent. In this example, quiescing of a file system and/or applications is performed to enable consistent backups (e.g., file system consistent and application consistent backups, respectively).

A replication operation involves replication metadata, which may not be the same information that is required for backup operations and restore operations (e.g., granular metadata). In another embodiment, and in certain configurations and deployments, a backup agent and a replication agent may not be implemented in a virtual machine, but instead, may be implemented in a hypervisor host, or even in a different virtual machine (e.g., a virtual machine appliance) on the hypervisor host. Likewise, a replication manager may be implemented on a different computing device other than a backup server.

In certain embodiments, a backup agent quiesces one or more applications, triggers snapshot creation, and generates metadata. The backup agent then communicates with a replication agent to have the replication agent mark this state with a consistency marker in a replication stream so that a replica will have this state marked for a backup proxy to be able to use (the marked state) to create a backup from the replica (e.g., as opposed to using the latest state of the replica which could change frequently). In this example, both virtual machines and physical machines can be sources of data.

In one embodiment, a replication consistency checkpoint involves capturing and/or remembering a time a consistent snapshot is performed for use by a backup operation. This enables a backup proxy in the cloud to have a replica go back to that point in time when creating a backup image out of the replica. Therefore, a replication consistency marker is a point in time that a replication agent notes, remembers, and/or tracks in order to be able to go back to (e.g., to provide a view of data at that point in time to a backup proxy).

<FIG> is a block diagram of a computing system <NUM>, according to one embodiment of the present disclosure. Computing system <NUM> can include cloud computing device <NUM> and broadly represents any single or multi-processor computing device or system capable of executing computer-readable instructions. Examples of computing system <NUM> include, without limitation, any one or more of a variety of devices including workstations, personal computers, laptops, client-side terminals, servers, distributed computing systems, handheld devices (e.g., personal digital assistants and mobile phones), network appliances, storage controllers (e.g., array controllers, tape drive controller, or hard drive controller), and the like. In its most basic configuration, computing system <NUM> may include at least one processor <NUM> and a memory <NUM>. By executing the software that executes backup proxy <NUM>, computing system <NUM> becomes a special purpose computing device that is configured to perform backup operations using replicas (e.g., replicas stored in a public cloud, and the like).

Processor <NUM> generally represents any type or form of processing unit capable of processing data or interpreting and executing instructions. In certain embodiments, processor <NUM> may receive instructions from a software application or module. These instructions may cause processor <NUM> to perform the functions of one or more of the embodiments described and/or illustrated herein. For example, processor <NUM> may perform and/or be a means for performing all or some of the operations described herein. Processor <NUM> may also perform and/or be a means for performing any other operations, methods, or processes described and/or illustrated herein. Memory <NUM> generally represents any type or form of volatile or non-volatile storage devices or mediums capable of storing data and/or other computer-readable instructions. Examples include, without limitation, random access memory (RAM), read only memory (ROM), flash memory, or any other suitable memory device. Although not required, in certain embodiments computing system <NUM> may include both a volatile memory unit and a non-volatile storage device. In one example, program instructions implementing backup proxy <NUM> and DR coordinator <NUM> (or alternatively, backup agent <NUM> and replication agent <NUM>) may be loaded into memory <NUM>.

In certain embodiments, computing system <NUM> may also include one or more components or elements in addition to processor <NUM> and/or memory <NUM>. For example, as illustrated in <FIG>, computing system <NUM> may include a memory controller <NUM>, an Input/Output (I/O) controller <NUM>, and a communication interface <NUM>, each of which may be interconnected via a communication infrastructure <NUM>. Communication infrastructure <NUM> generally represents any type or form of infrastructure capable of facilitating communication between one or more components of a computing device. Examples of communication infrastructure <NUM> include, without limitation, a communication bus (such as an Industry Standard Architecture (ISA), Peripheral Component Interconnect (PCI), PCI express (PCIe), or similar bus) and a network.

Memory controller <NUM> generally represents any type/form of device capable of handling memory or data or controlling communication between one or more components of computing system <NUM>. In certain embodiments memory controller <NUM> may control communication between processor <NUM>, memory <NUM>, and I/O controller <NUM> via communication infrastructure <NUM>. In certain embodiments, memory controller <NUM> may perform and/or be a means for performing, either alone or in combination with other elements, one or more of the operations or features described and/or illustrated herein.

I/O controller <NUM> generally represents any type or form of module capable of coordinating and/or controlling the input and output functions of a virtual machine and/or a physical computing device. For example, in certain embodiments I/O controller <NUM> may control or facilitate transfer of data between one or more elements of computing system <NUM>, such as processor <NUM>, memory <NUM>, communication interface <NUM>, display adapter <NUM>, input interface <NUM>, and storage interface <NUM>.

Communication interface <NUM> broadly represents any type or form of communication device or adapter capable of facilitating communication between computing system <NUM> and one or more other devices. Communication interface <NUM> may facilitate communication between computing system <NUM> and a private or public network including additional computing systems. Examples of communication interface <NUM> include, without limitation, a wired network interface (such as a network interface card), a wireless network interface (such as a wireless network interface card), a modem, and any other suitable interface. Communication interface <NUM> may provide a direct connection to a remote server via a direct link to a network, such as the Internet, and may also indirectly provide such a connection through, for example, a local area network (e.g., an Ethernet network), a personal area network, a telephone or cable network, a cellular telephone connection, a satellite data connection, or any other suitable connection.

Communication interface <NUM> may also represent a host adapter configured to facilitate communication between computing system <NUM> and one or more additional network or storage devices via an external bus or communications channel. Examples of host adapters include, Small Computer System Interface (SCSI) host adapters, Universal Serial Bus (USB) host adapters, Institute of Electrical and Electronics Engineers (IEEE) <NUM> host adapters, Serial Advanced Technology Attachment (SATA), Serial Attached SCSI (SAS), and external SATA (eSATA) host adapters, Advanced Technology Attachment (ATA) and Parallel ATA (PATA) host adapters, Fibre Channel interface adapters, Ethernet adapters, or the like. Communication interface <NUM> may also allow computing system <NUM> to engage in distributed or remote computing (e.g., by receiving/sending instructions to/from a remote device for execution).

As illustrated in <FIG>, computing system <NUM> may also include at least one display device <NUM> coupled to communication infrastructure <NUM> via a display adapter <NUM>. Display device <NUM> generally represents any type or form of device capable of visually displaying information forwarded by display adapter <NUM> (e.g., in a GUI). Similarly, display adapter <NUM> generally represents any type or form of device configured to forward graphics, text, and other data from communication infrastructure <NUM> (or from a frame buffer, as known in the art) for display on display device <NUM>. Computing system <NUM> may also include at least one input device <NUM> coupled to communication infrastructure <NUM> via an input interface <NUM>. Input device <NUM> generally represents any type or form of input device capable of providing input, either computer or human generated, to computing system <NUM>. Examples of input device <NUM> include a keyboard, a pointing device, a speech recognition device, or any other input device.

Computing system <NUM> may also include storage device <NUM> coupled to communication infrastructure <NUM> via a storage interface <NUM>. Storage device <NUM> generally represents any type or form of storage devices or mediums capable of storing data and/or other computer-readable instructions. For example, storage device <NUM> may include a magnetic disk drive (e.g., a so-called hard drive), a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash drive, or the like. Storage interface <NUM> generally represents any type or form of interface or device for transferring and/or transmitting data between storage device <NUM>, and other components of computing system <NUM>. Storage device <NUM> may be configured to read from and/or write to a removable storage unit configured to store computer software, data, or other computer-readable information. Examples of suitable removable storage units include a floppy disk, a magnetic tape, an optical disk, a flash memory device, or the like. Storage device <NUM> may also include other similar structures or devices for allowing computer software, data, or other computer-readable instructions to be loaded into computing system <NUM>. For example, storage device <NUM> may be configured to read and write software, data, or other computer-readable information. Storage device <NUM> may also be a part of computing system <NUM> or may be separate devices accessed through other interface systems.

Many other devices or subsystems may be connected to computing system <NUM>. Conversely, all of the components and devices illustrated in <FIG> need not be present to practice the embodiments described and/or illustrated herein. The devices and subsystems referenced above may also be interconnected in different ways from that shown in <FIG>. Computing system <NUM> may also employ any number of software, firmware, and/or hardware configurations. For example, one or more of the embodiments disclosed herein may be encoded as a computer program (also referred to as computer software, software applications, computer-readable instructions, or computer control logic) on a computer-readable storage medium. Examples of computer-readable storage media include magnetic-storage media (e.g., hard disk drives and floppy disks), optical-storage media (e.g., CD- or DVD-ROMs), electronic-storage media (e.g., solid-state drives and flash media), and the like. Such computer programs can also be transferred to computing system <NUM> for storage in memory via a network such as the Internet or upon a carrier medium.

The computer-readable medium containing the computer program may be loaded into computing system <NUM> (e.g., virtual machines <NUM>(<NUM>)-(N), backup server <NUM>, or cloud computing device <NUM>). All or a portion of the computer program stored on the computer-readable medium may then be stored in virtual disks <NUM>(<NUM>)-(N) and/or cloud storage device <NUM>. When executed by processor <NUM>, a computer program loaded into computing system <NUM> may cause processor <NUM> to perform and/or be a means for performing the functions of one or more of the embodiments described herein. Alternatively, one or more of the embodiments described and/or illustrated herein may be implemented in firmware and/or hardware. For example, computing system <NUM> may be configured as an application specific integrated circuit (ASIC) adapted to implement one or more of the embodiments disclosed herein.

<FIG> is a block diagram of a networked system, illustrating how various computing devices can communicate via a network, according to one embodiment. In certain embodiments, network-attached storage (NAS) devices may be configured to communicate with virtual machines <NUM>(<NUM>)-(N), backup server <NUM>, and/or cloud computing device <NUM> using Network File System (NFS), Server Message Block (SMB), or Common Internet File System (CIFS). Network <NUM> generally represents any type or form of computer network or architecture capable of facilitating communication between virtual machines <NUM>(<NUM>)-(N), backup server <NUM>, and/or cloud computing device <NUM>.

In certain embodiments, a communication interface, such as communication interface <NUM> in <FIG>, may be used to provide connectivity between virtual machines <NUM>(<NUM>)-(N), backup server <NUM>, and/or cloud computing device <NUM>, and network <NUM>. The embodiments described and/or illustrated herein are not limited to the Internet or any particular network-based environment. In some embodiments, network <NUM> can be a Storage Area Network (SAN). In other embodiments, backup agent <NUM> and/or replication agent <NUM> may be part of virtual machines, or may be separate. If separate, backup agent <NUM> and/or replication agent <NUM> and the computing device backup agent <NUM> and/or replication agent <NUM> are implemented in (e.g., cloud backup system <NUM>) may be communicatively coupled via network <NUM>.

In one embodiment, all or a portion of one or more of the disclosed embodiments may be encoded as a computer program and loaded onto and executed by virtual machines <NUM>(<NUM>)-(N), one or more physical machines, backup server <NUM>, and/or cloud computing device <NUM>. All or a portion of one or more of the embodiments disclosed herein may also be encoded as a computer program, stored on storage system <NUM>, and distributed over network <NUM>.

In some examples, all or a portion of cloud backup system <NUM>, cloud computing device <NUM>, and/or cloud storage device <NUM> may represent portions of a cloud-computing or network-based environment. Cloud-computing environments may provide various services and applications via the Internet. These cloud-based services (e.g., software as a service, platform as a service, infrastructure as a service, etc.) may be accessible through a web browser or other remote interface. Various functions described herein may be provided through a remote desktop environment or any other cloud-based computing environment.

In addition, one or more of the components described herein may transform data, physical devices, and/or representations of physical devices from one form to another. For example, backup agent <NUM> and replication agent <NUM>, or alternatively, DR coordinator <NUM> and backup proxy <NUM>, may transform the behavior of virtual machines <NUM>(<NUM>)-(N) and/or backup server <NUM> or cloud computing device <NUM>, respectively, to perform backup operations using replicas stored in a public or private cloud.

Claim 1:
A computer-implemented method comprising:
creating a replica (<NUM>) of a virtual machine (<NUM>), wherein
the virtual machine is at a primary site (<NUM>),
the replica is created at a secondary site (<NUM>) as part of a replication operation, and
the replica comprises
replicated data, wherein the replicated data comprises a replica of data (<NUM>) associated with the virtual machine, and
replicated metadata, wherein the replicated metadata comprises
a replica of metadata (<NUM>), the metadata comprising one or more data locations of one or more blocks of the data, and
the one or more data locations are configured to be used to restore one or more applications executing on the virtual machine; and
performing a backup operation at the secondary site, wherein
the performing the backup operation comprises
generating a backup image (<NUM>) from the replicated data, and
storing the backup image and the replicated metadata at the secondary site, the backup operation is performed at the secondary site by a backup proxy (<NUM>), and
the backup proxy is instantiated at the secondary site by a backup server (<NUM>) at the primary site.