Abstract: Techniques are provided for caching data during an on-demand restore using a cloud block map. A client may be provided with access to an on-demand volume during a restore process that copies backup data from a snapshot within a remote object store to the on-demand volume stored within local storage. In response to receiving a request from the client for a block of the backup data not yet restored from the snapshot to the on-demand volume, the block may be retrieved from the snapshot in the remote object store. The block may be cached within a cloud block map stored within the local storage as a cached block. The client may be provided with access to the cached block.

Abstract: Systems and methods are provided for data migration including cloning a multiple-logical unit number (LUN) volume into a plurality of cloned single-LUN volumes on a first storage node of a computing system; creating a plurality of new volumes on a second storage node of the computing system based at least in part on the plurality of cloned single-LUN volumes; selectively copying snapshot data from the plurality of cloned single-LUN volumes to the plurality of new volumes; establishing snapshot mirror relationships between the plurality of cloned single-LUN volumes and the plurality of new volumes; synchronizing the plurality of cloned single-LUN volumes and the plurality of new volumes; and performing a migration of data logical interface failovers (LIFs) from the plurality of cloned single-LUN volumes to the plurality of new volumes.

Abstract: Systems and methods are provided for data migration including cloning a multiple-logical unit number (LUN) volume into a plurality of cloned single-LUN volumes on a first storage node of a computing system; creating a plurality of new volumes on a second storage node of the computing system based at least in part on the plurality of cloned single-LUN volumes; selectively copying snapshot data from the plurality of cloned single-LUN volumes to the plurality of new volumes; establishing snapshot mirror relationships between the plurality of cloned single-LUN volumes and the plurality of new volumes; synchronizing the plurality of cloned single-LUN volumes and the plurality of new volumes; and performing a migration of data logical interface failovers (LIFs) from the plurality of cloned single-LUN volumes to the plurality of new volumes.

Abstract: Techniques are provided for creating file clones of multipart files. Creating clones of files is an integral part of providing backup, restore, and other storage services. However, conventional file cloning techniques are unable to create clones of multipart files that are composed of multiple parts stored across different volumes and/or nodes in a constant time. The disclosed techniques are capable of cloning multipart files by creating a clone parent file into which catalog entries from a source multiple file are moved. A destination multipart file is initially created as an empty clone of the source multipart file. Block sharing of the catalog entries from the clone parent file to the source and destination multipart files is performed, and cloning of the source multipart file is declared complete in a constant time such as within a few seconds or less.

Abstract: Systems and methods for implementing context checks that account for the potential for file movement across nodes of a cluster of a distributed storage system are provided. Context data utilized for performing context checking in connection with performing read operations may include a buffer tree identifier (bufftree ID), a data ID, and an epoch in which the bufftree ID represents a volume ID that is unique across the cluster, the data ID corresponds to a file block number within the file at issue from which data is being read, and the epoch is a value that facilitates cluster-wide timeline checks. In one embodiment, the bufftree ID may be ensured to be unique across the cluster by, during the process of creating a new volume, combining a unique ID of the DEFS hosting the new volume with a monotonically increasing volume count maintained for the DEFS.

Abstract: Techniques are provided for on-demand serverless disaster recovery. A primary node may host a primary volume. Snapshots of the primary volume may be backed up to an object store. In response to failure, a secondary node and/or an on-demand volume may be created on-demand. The secondary node may provide clients with failover access to the on-demand volume while a restore process restores a snapshot of the primary volume to the on-demand volume. In some embodiments, there was no secondary node and/or on-demand volume while the primary node was operational. This conserves computing resources that would be wasted by otherwise hosting the secondary node and/or on-demand volume while clients were able to access the primary volume through the primary node. Modifications directed to the on-demand volume are incrementally backed up to the object store for subsequently restoring the primary volume after recovery.

Abstract: Techniques are provided for storage tier verification checks. A determination is made that a mount operation of an aggregate of a set of volumes stored within a multi-tier storage environment has completed. A first metafile and a second metafile are maintained to track information related to the storage of objects of a volume of the aggregate within a remote object store that is a tier of the multi-tier storage environment. A distributed verification is performed between the first metafile and the second metafile to identify an inconsistency. Accordingly, the first metafile and the second metafile are reconciled to address the inconsistency so that storage information within the first metafile and the second metafile are consistent.

Abstract: Techniques are provided for caching data during an on-demand restore using a cloud block map. A client may be provided with access to an on-demand volume during a restore process that copies backup data from a snapshot within a remote object store to the on-demand volume stored within local storage. In response to receiving a request from the client for a block of the backup data not yet restored from the snapshot to the on-demand volume, the block may be retrieved from the snapshot in the remote object store. The block may be cached within a cloud block map stored within the local storage as a cached block. The client may be provided with access to the cached block.

Abstract: Techniques are provided for on-demand serverless disaster recovery. A primary node may host a primary volume. Snapshots of the primary volume may be backed up to an object store. In response to failure, a secondary node and/or an on-demand volume may be created on-demand. The secondary node may provide clients with failover access to the on-demand volume while a restore process restores a snapshot of the primary volume to the on-demand volume. In some embodiments, there was no secondary node and/or on-demand volume while the primary node was operational. This conserves computing resources that would be wasted by otherwise hosting the secondary node and/or on-demand volume while clients were able to access the primary volume through the primary node. Modifications directed to the on-demand volume are incrementally backed up to the object store for subsequently restoring the primary volume after recovery.

Abstract: Techniques are provided for caching data during an on-demand restore using a cloud block map. A client may be provided with access to an on-demand volume during a restore process that copies backup data from a snapshot within a remote object store to the on-demand volume stored within local storage. In response to receiving a request from the client for a block of the backup data not yet restored from the snapshot to the on-demand volume, the block may be retrieved from the snapshot in the remote object store. The block may be cached within a cloud block map stored within the local storage as a cached block. The client may be provided with access to the cached block.

Abstract: Techniques are provided for storage tier verification checks. A determination is made that a mount operation of an aggregate of a set of volumes stored within a multi-tier storage environment has completed. A first metafile and a second metafile are maintained to track information related to the storage of objects of a volume of the aggregate within a remote object store that is a tier of the multi-tier storage environment. A distributed verification is performed between the first metafile and the second metafile to identify an inconsistency. Accordingly, the first metafile and the second metafile are reconciled to address the inconsistency so that storage information within the first metafile and the second metafile are consistent.

Abstract: Techniques are provided for caching data during an on-demand restore using a cloud block map. A client may be provided with access to an on-demand volume during a restore process that copies backup data from a snapshot within a remote object store to the on-demand volume stored within local storage. In response to receiving a request from the client for a block of the backup data not yet restored from the snapshot to the on-demand volume, the block may be retrieved from the snapshot in the remote object store. The block may be cached within a cloud block map stored within the local storage as a cached block. The client may be provided with access to the cached block.

Abstract: Systems and methods for preserving storage efficiency during restoration of data from the cloud are provided. In one embodiment, a CBMAP is maintained that maps cloud block numbers (CBNs) to respective corresponding block numbers of a volume of a data storage system in which previously restored data has been stored by a previously restored file. By making use of the CBMAP during the restoration process, storage of duplicate file data blocks on the volume may be avoided by sharing with a current file being restored a reference to the corresponding file data block previously stored on the volume and associated with the previously restored file. In addition to preserving storage efficiency, use of the CBMAP facilitates avoidance of repeated GET operations for data associated with CBNs previously retrieved from the cloud and stored to the volume, thereby reducing data access costs as well as latency of the restore operation.

Abstract: Systems and methods for preserving storage efficiency during restoration of data from the cloud are provided. In one embodiment, a CBMAP is maintained that maps cloud block numbers (CBNs) to respective corresponding block numbers of a volume of a data storage system in which previously restored data has been stored by a previously restored file. By making use of the CBMAP during the restoration process, storage of duplicate file data blocks on the volume may be avoided by sharing with a current file being restored a reference to the corresponding file data block previously stored on the volume and associated with the previously restored file. In addition to preserving storage efficiency, use of the CBMAP facilitates avoidance of repeated GET operations for data associated with CBNs previously retrieved from the cloud and stored to the volume, thereby reducing data access costs as well as latency of the restore operation.

Abstract: Techniques are provided for virtual machine hosting and disaster recovery across virtual machine hosting environments, such as hypervisors, supporting different virtual machine formats. A virtual machine is hosted by a first hypervisor that supports a first virtual machine format. Snapshots capturing virtual machine disks of the virtual machine are created and backed up to a cloud storage environment. The snapshots are used to restore the virtual machine as a destination virtual machine hosted by a second hypervisor supporting a second virtual machine format different than the first virtual machine format. As part of restoring the destination virtual machine, virtual machine disks of the virtual machine are reformatted according to the second virtual machine format supported by the second hypervisor.

Abstract: Techniques are provided for virtual machine hosting and serverless disaster recovery. A virtual machine is hosted by a first hypervisor that may be located on-premise. Snapshots of virtual machine disks of the virtual machine are backed up to a cloud storage environment. The snapshots are used to on-demand host a new instance of the virtual machine within a destination environment such as within the cloud storage environment through a second hypervisor. The new instance of the virtual machine is hosted for various reasons such as part of a disaster recovery operation if the virtual machine fails, load balancing of I/O operations, migration to a different hosting environment (e.g., a cheaper or more performant environment), development testing, etc.

Abstract: Techniques are provided for caching data during an on-demand restore using a cloud block map. A client may be provided with access to an on-demand volume during a restore process that copies backup data from a snapshot within a remote object store to the on-demand volume stored within local storage. In response to receiving a request from the client for a block of the backup data not yet restored from the snapshot to the on-demand volume, the block may be retrieved from the snapshot in the remote object store. The block may be cached within a cloud block map stored within the local storage as a cached block. The client may be provided with access to the cached block.

Abstract: Systems and methods for preserving storage efficiency during restoration of data from the cloud are provided. In one embodiment, a CBMAP is maintained that maps cloud block numbers (CBNs) to respective corresponding block numbers of a volume of a data storage system in which previously restored data has been stored by a previously restored file. By making use of the CBMAP during the restoration process, storage of duplicate file data blocks on the volume may be avoided by sharing with a current file being restored a reference to the corresponding file data block previously stored on the volume and associated with the previously restored file. In addition to preserving storage efficiency, use of the CBMAP facilitates avoidance of repeated GET operations for data associated with CBNs previously retrieved from the cloud and stored to the volume, thereby reducing data access costs as well as latency of the restore operation.

Abstract: Methods and systems for a networked storage system are provided. One method includes: generating, by a first node, a dummy entry in a storage location cache of the first node, the dummy entry associated with a read request received by the first node for data stored using a logical object owned by a second node; receiving, by the first node, an invalidation request to invalidate any storage location entry associated with the data, the invalidation request sent in response to the second node receiving a write request to modify the data; invalidating, by the first node, the dummy entry; receiving, by the first node, a response to the read request from the second node with the requested data; and replacing, by the first node, the dummy entry with a storage location entry and invalidating the storage location entry based on the invalidated dummy entry.

Abstract: Techniques are provided for caching data during an on-demand restore using a cloud block map. A client may be provided with access to an on-demand volume during a restore process that copies backup data from a snapshot within a remote object store to the on-demand volume stored within local storage. In response to receiving a request from the client for a block of the backup data not yet restored from the snapshot to the on-demand volume, the block may be retrieved from the snapshot in the remote object store. The block may be cached within a cloud block map stored within the local storage as a cached block. The client may be provided with access to the cached block.