Abstract: Techniques are provided for incremental snapshot copy to an object store. A list of deallocated block numbers of primary storage of a computing device are identified. Entries for the list of deallocated block numbers are removed from a mapping metafile. A list of changed block numbers corresponding to changes between a current snapshot of the primary storage and a prior copied snapshot copied from the primary storage to the object store is determined. The mapping metafile is evaluated using the list of changed block numbers to identify a deduplicated set of changed block numbers without entries within the mapping metafile. An object, comprising data of the deduplicated set of changed block numbers, is transmitted to the object store for storage as a new copied snapshot.

Abstract: Techniques are provided for on-demand creation and/or utilization of containers and/or serverless threads for hosting data connector components. The data connector components can be used to perform integrity checking, anomaly detection, and file system metadata analysis associated with objects stored within an object store. The data connector components may be configured to execute machine learning functionality to perform operations and tasks. The data connector components can perform full scans or incremental scans. The data connector components may be stateless, and thus may be offlined, upgraded, onlined, and/or have tasks transferred between data connector components. Results of operations performed by the data connector components upon base objects may be stored within sibling objects.

Abstract: Techniques are provided for incremental backup to an object store. A request may be received from an application to perform a backup from a volume hosted by a node to a backup target within the object store. A set of changed files within the volume since a prior backup of the volume was performed to the backup target is identified, along with metadata associated with the set of changed files. The metadata is utilized to identify changed data blocks comprising data of the set of changed files that was modified since the prior backup. The changed data blocks are backed up to the object store.

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 storing immutable snapshot copes in write once read many (WORM) storage. A snapshot of a volume may be stored into one or more objects formatted according to an object format. An expiry time may be assigned to the snapshot and the one or more objects based upon a creation time of the snapshot and a retention time. The one or more objects may be stored within a remote object store. The one or more objects are retained in an immutable state and cannot be deleted until expiration of the expiry time. In response to identifying an existing object within the remote object store comprising shared snapshot data referenced by the snapshot, an assigned expiry time of the existing object may be modified based upon the expiry time of the snapshot to create a modified expiry time for the existing object.

Abstract: Techniques are provided for volume group backup, volume group restore, and volume group garbage collection for volume groups backed up to an object store. A volume group workflow is implemented to orchestrate individual consistent volume workflows that are separately and individually implemented by nodes hosting constituent volumes of a volume group. The volume group workflow and the individual consistent volume workflows are performed to back up the volume group to the object store, restore a volume group backup from the object store to a restore destination, and/or perform garbage collection on slots of objects storing data unique to a volume group backup to delete.

Abstract: Techniques are provided for managing objects within an object store. An object is maintained within an object store. In an embodiment, a rule is enforced for the object that in-use slots of the object are non-modifiable and unused slots of the object are modifiable. Metadata of additional information for a slot within the object is attached to the object header. A first application allowed to access user data within the slot is provided access to the user data without being provided access to the metadata. A second application allowed access to the user data and the additional information is provided with access to the user data and the metadata for identifying a location of additional information within the object.

Abstract: Techniques are provided for on-demand creation and/or utilization of containers and/or serverless threads for hosting data connector components. The data connector components can be used to perform integrity checking, anomaly detection, and file system metadata analysis associated with objects stored within an object store. The data connector components may be configured to execute machine learning functionality to perform operations and tasks. The data connector components can perform full scans or incremental scans. The data connector components may be stateless, and thus may be offlined, upgraded, onlined, and/or have tasks transferred between data connector components. Results of operations performed by the data connector components upon base objects may be stored within sibling objects.

Abstract: Techniques are provided for incremental backup to an object store. A request may be received from an application to perform a backup from a volume hosted by a node to a backup target within the object store. A set of changed files within the volume since a prior backup of the volume was performed to the backup target is identified, along with metadata associated with the set of changed files. The metadata is utilized to identify changed data blocks comprising data of the set of changed files that was modified since the prior backup. The changed data blocks are backed up to the object store.

Abstract: Techniques are provided for an object file system for an object store. Data, maintained by a computing device, is stored into slots of an object. The data within the slots of the object is represented as a data structure comprising a plurality of nodes comprising cloud block numbers used to identify the object and particular slots of the object. A mapping metafile is maintained to map block numbers used to store the data by the computing device to cloud block numbers of nodes representing portion of the data stored within slots of the object. The object is stored into the object store, and the mapping metafile and the data structure are used to provide access through the object file system to portions of data within the object.

Abstract: Techniques are provided for tiering snapshots to archival storage in remote object stores. A restore time metric, indicating that objects comprising snapshot data of snapshots created within a threshold timespan are to be available within a storage tier of a remote object store for performing restore operations, may be identified. A scanner may be executed to evaluate snapshots using the restore time metric to identify a set of candidate snapshots for archival from the storage tier to an archival storage tier of the remote object store. For each candidate snapshot within the set of candidate snapshots, the scanner may evaluate metadata associated with the candidate snapshot to identity one or more objects eligible for archival from the storage tier to the archival storage tier, and may archive the one or more objects from the storage tier to the archival storage tier.

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 restoring a directory from a snapshot of a volume backed up to an object store. The snapshot may be backed up from a node to the object store, such as a cloud computing environment. A user may want to restore the directory within the volume without having to restore the entire volume, which otherwise would waste computing resources, storage, network bandwidth, and time. Accordingly, the techniques provided herein are capable of restoring just the directory from the snapshot that is stored within the object store. Because snapshot data of the snapshot may be stored across multiple objects within the object store, certain objects are identified as comprising snapshot data (backup data) of the directory and content items within the directory. In this way, the snapshot data of the directory is restored from these objects to a restore directory at a restore target.

Abstract: 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.

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 a snapshot difference interface integrated into an object store data management container. The snapshot difference interface is capable of interpreting an object format and snapshot file system format of snapshots backed up to an object store within objects formatted according to the object format. The snapshot difference interface can identify differences between snapshots, such as files that changed between the snapshots, while the snapshots are still resident within the object store. Because the snapshot difference interface does not retrieve the snapshots from the object store, security is improved, resource and network consumption is reduced, and there is less of an impact upon client I/O processing. Also, a compliance scan for the snapshots can be performed much quicker by skipping already scanned snapshot data from a prior compliance scan.

Abstract: Techniques are provided for a snapshot difference interface integrated into an object store data management container. The snapshot difference interface is capable of interpreting an object format and snapshot file system format of snapshots backed up to an object store within objects formatted according to the object format. The snapshot difference interface can identify differences between snapshots, such as files that changed between the snapshots, while the snapshots are still resident within the object store. Because the snapshot difference interface does not retrieve the snapshots from the object store, security is improved, resource and network consumption is reduced, there is less of an impact upon client I/O processing, and a catalog of the snapshots can be more efficiently built and recovered in the event of corruption.

Abstract: Techniques are provided for determining a physical size of a snapshot backed up to an object store. Snapshot data of the snapshot may be backed up into objects that are stored from a node to the object store, such as a cloud computing environment. A tracking object is created to identify which objects within the object store comprise the snapshot data of the snapshot. In order to determine the physical size of the snapshot, the tracking object and/or tracking objects of other snapshots such as a prior snapshot are evaluated to identify a set of objects comprising snapshot data unique to the snapshot and not shared with the prior snapshot. The physical sizes of the set of objects are combined with a metadata size of metadata of the snapshot to determine the physical size of the snapshot.

Abstract: Techniques are provided for volume group backup, volume group restore, and volume group garbage collection for volume groups backed up to an object store. A volume group workflow is implemented to orchestrate individual consistent volume workflows that are separately and individually implemented by nodes hosting constituent volumes of a volume group. The volume group workflow and the individual consistent volume workflows are performed to back up the volume group to the object store, restore a volume group backup from the object store to a restore destination, and/or perform garbage collection on slots of objects storing data unique to a volume group backup to delete.

Abstract: Techniques are provided for volume group backup, volume group restore, and volume group garbage collection for volume groups backed up to an object store. A volume group workflow is implemented to orchestrate individual consistent volume workflows that are separately and individually implemented by nodes hosting constituent volumes of a volume group. The volume group workflow and the individual consistent volume workflows are performed to back up the volume group to the object store, restore a volume group backup from the object store to a restore destination, and/or perform garbage collection on slots of objects storing data unique to a volume group backup to delete.