Netapp, Inc.

Tijin George

Atul Ramesh Pandit

Dnyaneshwar Nagorao Pawar

Roopesh Chuggani

Jagavar Nehra

Sharankumar Yelheri

Kiyoshi James Komatsu

Jose Mathew

Anil Kumar Ponnapur

Sanhita Praveen Dhavale

Sriram Venketaraman

Avanthi Rajan

Ravindra Kuramkote

Ling Zheng

Ching-Yuk Paul Ngan

Sumith Makam

Rakesh Bhargava M R

Murali Subramanian

Anitha Ganesha

Harsha Vardhan Reddy Perannagari

Ananthan Subramanian

Cheryl Marie Thompson

Kiran Nenmeli Srinivasan

Michael Robin Eisler

Abhishek Naidu

Sisir Shekhar

Rachita Kothiyal

Felix Xavier

Jayalakshmi Pattabiraman

Jeffrey David Prem

Chuyi Wei

Ricardo Sanchez Aguilera

Allan Jessie Sur

Sumedh Guha

Kevin Varghese

Adhitya Rajagopalan

Techniques are provided for a data format for efficient management of checkpoint support. The data format corresponds to a base metafile and a set of instance metafiles used to track storage operations such as a directory restore operation. The base metafile and the set of instance metafiles can be used to resume the storage operation from where the storage operation left off in the event of a failure. The base metafile and the set of instance metafiles can be used to track progress of the storage operation processing objects stored within an object store of a cloud storage environment.

Restarting a storage operation utilizing an instance metafile

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.

Incremental backup to object store

Techniques are provided for implementing a snapshot copy operation between endpoints. One or more snapshots (e.g., snapshots of an on-premise volume) is stored within a source endpoint, such as a source bucket of an object store. A post operation is executed to copy objects comprising snapshot data of a snapshot from the source endpoint to a destination endpoint. A get operation and a tracking object such as a cookie is used to track progress of copying the objects from the source endpoint to the destination endpoint. The tracking object is used to restart the copying of the objects from a point where the copying left off (e.g., in the event there is a failure) without having to restart from the beginning.

Snapshot copy operation to copy a snapshot from source endpoint to destination endpoint

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.

Physical size API for snapshots backed up to object store

Techniques are provided for performing a resync transfer to recover from a storage site failure. During normal operation of a first site hosting a first volume, data is replicated to a second volume hosted by a second site. If the first site fails, when clients are redirected to the second volume at the second site. When the first site recovers, data modifications made to the second volume are resynced back to the first volume. As part of synchronizing the first volume, a data warehouse is rebuilt at the first site in order to track the location of blocks present on the replication destination. Typically, the data modifications are transferred after the data warehouse is rebuilt, which results in significantly long resync times. The techniques provided herein decrease the resync time by either rebuilding the data warehouse in parallel with resyncing the data modifications or circumvent the need for rebuild.

Resync transfer for recovering from storage site failure utilizing background pull operations

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.

Snapshot storage and management within an object store

Techniques are provided for performing a storage operation targeting objects stored across multiple storage tiers of a cloud storage environment. A volume may be backed up as objects stored across the multiple storage tiers of the cloud storage environment, such as a standard storage tier directly accessible to the storage operation, an archival storage tier not directly accessible to the storage operation, etc. The storage operation may target the objects, such as where the storage operation is a directory restore operation to restore a directory of the volume. The storage operation can be successfully implemented such as to restore the directory even though objects of the storage operation are stored across the multiple storage tiers of the cloud storage environment.

Granular cloud restore with multi storage class support

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.

On-demand serverless disaster recovery

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.

Object store data management container with integrated snapshot difference interface for compliance scans

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.

Data connector component for implementing integrity checking, anomaly detection, and file system metadata analysis

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.

Flexible tiering of snapshots to archival storage in remote object stores

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.

Volume group restore from remote object store

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.

Transferring snapshot copy to object store with deduplication preservation and additional compression

Containerization and serverless thread implementation for processing objects

Sibling object generation for storing results of operations performed upon base objects

Growing community of inventors

Sunnyvale, CA, United States of America

Tijin George