Comm Vault Systems, Inc.

Knobbe, Martens, Olson & Bear Llp

Sanjay Kumar

Amit Mitkar

Sumedh Pramod Degaonkar

Henry Wallace Dornemann

Satish Chandra Kilaru

Vikash Kumar

Manas Bhikchand Mutha

Shankarbabu Bhavanarushi

Data protection resources are automatically scaled to the needs of data source(s) in an application orchestrator computing environment, such as a cluster in a Kubernetes deployment. The approach is adaptable to data sources in production clusters or application suites that are not application orchestrator deployments, such as a cloud-based database-as-a-service (DBaaS). A data storage management system protects cluster-based data with an elastic number of data protection resources (e.g., data agents, media agents), which are deployed on demand. The number of data protection resources deployed for a particular job are appropriate to the workload(s) at present and depend on a variety of scaling factors. In some embodiments, data protection resources are deployed within the same cluster as the data sources. In other embodiments, a separate infrastructure cluster provides the data protection resources on demand, and connects to any number and types of data sources, whether cloud-based or otherwise, without limitation.

Scaled deployment of data protection resources for data originating in an application orchestrator

A 'backup services container' comprises “backup toolkits,” which include scripts for accessing containerized applications plus enabling utilities/environments for executing the scripts. The backup services container is added to Kubernetes pods comprising containerized applications without changing other pod containers. For maximum value and advantage, the backup services container is “over-equipped” with toolkits. The backup services container selects and applies a suitable backup toolkit to a containerized application to ready it for a pending backup. Interoperability with a proprietary data storage management system provides features that are not possible with third-party backup systems. Some embodiments include one or more components of the proprietary data storage management within the illustrative backup services container. Some embodiments include one or more components of the proprietary data storage management system in a backup services pod configured in a Kubernetes node. All configurations and embodiments are suitable for cloud and/or non-cloud computing environments.

Backup of containerized applications using a backup services container and a backup services container-orchestration pod

A native cloud-based VM in a cloud computing environment of choice is live-mounted without requiring nesting techniques. All operating system data needed to live-mount the VM is accessed over ISCSI. The disclosed technology: supports both Windows and Unix-like (e.g., Linux) operating systems; handles any number of partitions of the root file system without repeated mounting, exporting, and unmounting; and uses only internet protocols (e.g., HTTP, (SCSI) to live-mount the VM. The live-mounted VM gains access to a variety of secondary copies, e.g., made with file-level techniques or with block-level techniques, made within or outside the public cloud computing environment, made from other VMs having the same or a different hypervisor than the public cloud computing environment, and/or made from non-virtualized sources. Access to snapshots as a data source for the live-mounted VM is also disclosed. Thus, a streamlined and source-agnostic technology is disclosed for live-mounting VMs in a public cloud.

Live mounting a virtual machine in a public cloud based on accessing a simulated virtual disk as an internet small computer systems interface (ISCSI) target

Live mounting a virtual machine (VM) causes the VM to run off a backup copy or snapshot previously taken of a 'live' production VM. The live-mounted VM is generally intended for temporary use such as to validate the integrity and contents of the backup copy for disaster recovery validation, or to access some contents of the backup copy from the live-mounted VM without restoring all backed up files. These uses contemplate that changes occurring during live mount are not preserved after the live-mounted VM expires or is taken down. Thus, live mounting a VM is not a restore operation and usually does not involve access to every block of data in the backup copy. However, live mounting provides live VM service in the cloud sooner than waiting for all of the backup copy/snapshot to be restored.

Live recovery of virtual machines in a public cloud computing environment based on temporary live mount

Using an application orchestrator computing environment for automatically scaled deployment of data protection resources needed for data in a production cluster distinct from the application orchestrator or in another application orchestrator computing environment

Illustrative systems and methods enable a virtual machine ('VM') to be powered up at any hypervisor regardless of hypervisor type, based on live-mounting VM data that was originally backed up into a hypervisor-independent format by a block-level backup operation. Afterwards, the backed up VM executes anywhere anytime without needing to find a hypervisor that is the same as or compatible with the original source VM's hypervisor. The backed up VM payload data is rendered portable to any virtualized platform. Thus, a VM can be powered up at one or more test stations, data center or cloud recovery environments, and/or backup appliances, without the prior-art limitations of finding a same/compatible hypervisor for accessing and using backed up VM data. An illustrative media agent maintains cache storage that acts as a way station for data blocks retrieved from an original backup copy, and stores data blocks written by the live-mounted VM.

Cross-hypervisor live-mount of backed up virtual machine data

A system according to certain aspects improves the process of performing snapshot replication operations (e.g., maintaining a mirror copy of primary data at a secondary location by generating snapshots of the primary data). The system can collect and maintain cumulative block-level changes to the primary data after each sub-interval of a plurality of sub-intervals between the snapshots. When a snapshot is generated, any changes to the primary data not reflected in the cumulative block-level changes are identified based on the snapshot and transmitted to the secondary location along with the cumulative block-level changes. By the time the snapshot is generated, some or all of the changes to the primary data associated with the given snapshot have already been included in the cumulative block-level changes, thereby reducing the time and computing resources spent to identify and collect the changes for transmission to the secondary location.

Snapshot replication operations based on incremental block change tracking

Aspects of the present disclosure enable data protection operations including differential and incremental backups by performing changed-block tracking in network or cloud computing systems with architectures that do not natively support changed-block tracking or do not expose changed-block tracking functionality to an information management system. In certain aspects, an identity of changed blocks may be obtained by using a hypervisor configured to interface with the cloud computing architecture. The identified changed blocks may be used to generate a map of the changed blocks. The maps of the changed blocks can be used by a virtual server agent to extract the changed blocks from a copy of a virtual machine disk and backed up to perform a differential or incremental backup.

Systems and methods for change block tracking for backing up changed data

Certain embodiments described herein relate to an improved virtual machine restoration system. In one embodiment, an information management system receives a request to perform a restore of a virtual machine using virtual machine data stored on a secondary storage device. In response, the information management system boots up the virtual machine after restoring only a portion of the virtual machine data that is needed to boot up the virtual machine, thereby reducing latencies associated with virtual machine boot-up. The information management system continues to retrieve additional portions of the virtual machine data from the secondary storage device as such portions are requested by the virtual machine, thereby reducing or minimizing unnecessary data transfer from the secondary storage device.

Cross-hypervisor live recovery of virtual machines

Live mount of virtual machines in a public cloud computing environment

A 'backup services container' comprises 'backup toolkits,' which include scripts for accessing containerized applications plus enabling utilities/environments for executing the scripts. The backup services container is added to Kubernetes pods comprising containerized applications without changing other pod containers. For maximum value and advantage, the backup services container is &#x201c;over-equipped&#x201d; with toolkits. The backup services container selects and applies a suitable backup toolkit to a containerized application to ready it for a pending backup. Interoperability with a proprietary data storage management system provides features that are not possible with third-party backup systems. Some embodiments include one or more components of the proprietary data storage management within the illustrative backup services container. Some embodiments include one or more components of the proprietary data storage management system in a backup services pod configured in a Kubernetes node. All configurations and embodiments are suitable for cloud and/or non-cloud computing environments.

Preparing containerized applications for backup using a backup services container and a backup services container-orchestration pod

Live recovery generates a new 'recovery VM' that operates as an ongoing 'live' production platform. A previously created non-cloud-native backup copy is the data source for the recovery VM. Live recovery restores data blocks from the backup copy on backup media directly to cloud-based virtual disk(s) assigned to the recovery VM. As a result, the cloud-based recovery VM can become fully operational in the cloud computing environment on a going-forward basis. The advantage of live recovery over a traditional restore is that live recovery provides a cloud-based VM that begins operating well before the backup copy is fully restored. This is accomplished by temporarily mounting a &#x201c;temp-mounted VM&#x201d; in the cloud while the backup copy is methodically restored in the background. VM reads and writes begin issuing from the temp-mounted VM and writes are retained on completion. Downtime is minimized when switching from the temp-mounted VM to the recovery VM.

Growing community of inventors

Morganville, NJ, United States of America

Sanjay Kumar