Provision of a virtual secure cryptoprocessor (VSC) for a guest virtual machine (VM), part of a first guest, of a hypervisor of a computer system, includes (i) storing guest VM state and VSC state together in an encrypted virtual hard disk drive file, (ii) storing a decryption key in a sealed partition, of a second guest, sealed against a physical secure cryptoprocessor, (iii) based on verifying that a host computing environment of the computer system is in a trusted state and on booting the hypervisor thereon, unsealing the sealed partition of the second guest, the unsealing providing the decryption key, and decrypting the encrypted virtual hard disk drive file using the decryption key, where the decrypting decrypts the stored guest VM state for execution of the guest VM and decrypts the VSC state to provide the VSC for use by the guest VM.

Methods and systems for using a hierarchical consistency group (CG) in a storage system are provided. A parent CG is associated with at least a first child CG having a plurality of storage volumes. An atomic application programming interface (API) provisions the parent CG and the first child CG by allocating storage and storing policies for the parent CG and the first CG. A storage service selected from a backup service, a replication service and a cloning service for the parent CG and the first CG is executed based on the stored policies.

In a first virtual storage device managed by a helper virtual machine, first data of a first application is stored, the first application executing on a first system, the helper virtual machine executing on a recovery system. Responsive to determining that a duplicate of the first application should be activated on the recovery system, a compute instance is spawned in a hypervisor executing on the recovery system. In the compute instance, a duplicate of the first application is provisioned. The first data is reassociated from the helper virtual machine to the provisioned duplicate application. The duplicate application is activated, the activating causing the duplicate application to execute on the second system using the first data.

In an example embodiment, a solution is used to provide container volume replication via a container storage replication log and volume buffer synchronization, which is built on top of a container cloud platform whose container metadata and replication runtime configuration are all managed by a storage manager (a service orchestrated by its job scheduler and service orchestrator). This container volume replication ensures the data security for a long-running service in the container. In the case of any disaster, the in-memory database and application data inside of the container can be recovered via volume replication. This provides container volume replication for long-running containerized applications whose states keep changing.

Example implementations relate to virtual persistent volumes for containerized applications. In an example, a plurality of different storage mounts are acquired from a mix of storage types. A containerized storage virtualization system creates and manages a virtual persistent volume that aggregates the acquired storage mounts. A mount point of the virtual persistent volume is provided to the containerized application. The virtual persistent volume includes a hierarchical structure that relates data objects of the containerized application by content-based signatures to a root object.

Techniques are provided for implementing data requests associated with objects of an object store. A data connector component may be instantiated as a container for processing data requests associated with backup data stored within objects of an object store. The data connector component may evaluate the object store to identify snapshots stored as the backup data within the objects of the object store according to an object format. The data connector component may provide a client device with access to backup data of the snapshots.

A uniform model for distinct types of data replication, including receiving, at a source data repository, an update to a dataset; generating, based on the update to the dataset, both metadata describing the update to the dataset and also a metadata representation of the dataset; and initiating, based on the same metadata describing the update to the dataset and also based on the same metadata representation of the dataset, either a first type of data replication or a second type of data replication from among a plurality of types of data replication.

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.

On-the-fly point-in-time recovery operations are disclosed. During a recovery operation, the PiT being restored can be changed on-the-fly or during the existing recovery operation without restarting the recovery process from the beginning. In one example, this improves recovery time operation (RTO) and prevents aspects of the recovery operation to be avoided when changing to a different PiT.

A data storage management system comprises features for initiating failover orchestration jobs that invoke recovery resources on demand in a cloud computing environment. Backed up data that is stored persistently in the cloud computing environment may be rapidly restored within the cloud computing environment for use in disaster recovery and/or in test and verification scenarios. This approach may be contrasted to systems where a failover system is “always on” at the failover destination, such as having failover resources always up and running in the cloud computing environment. Such resources typically include a failover virtual machine (VM), a virtual machine datastore for the restored data, and one or more computing resources for restoring an auxiliary copy to the VM’s datastore. The cloud-based failover resources are deactivated or taken down once the failover event ends.