Netapp, Inc.

Network Appliance, Inc.

Dastratum, Inc.

Vijay Mohan Deshmukh

Kiyoshi James Komatsu

Atul Ramesh Pandit

Ling Zheng

Michael Lee Federwisch

Rachita Kothiyal

Benjamin Swartzlander

Srishylam Simharajan

Xin Wang

Jonathan Curley

Gurmeet Singh

Laura Beegle

Blake H Lewis

Pawan Saxena

Ravindra Kuramkote

Timothy J Thompson

John K Edwards

Pranab Patnaik

Rajesh Desai

Kapil Kumar

Uday Madhav Joshi

Stephen Lee Manley

Paul Yuedong Mu

Michael Robin Eisler

Sisir Shekhar

Collin Park

Barry Schwartz

Prashant Saraswat

Anil Kumar Sharma

Sudheer K Rao Miryala

Data is replicated on a backup node, where the granularity of the replication can be less than a full volume. A data consistency group comprising a subset of data for a volume is defined for a primary node. A set of differences for the data consistency group is sent to a backup node. The backup node creates change logs in response to receiving the set of differences. In response to receiving a request to access a file having data in the data consistency group, the backup node creates a clone of the file. The backup node determines whether an update to a data block of the file exists in the change logs. In response to determining that the update to the data block exists in the change logs, the backup node updates a copy of the data block for the cloned file with data in the change logs.

Granular replication of volume subsets

One or more techniques and/or computing devices are provided for cross-platform replication. For example, a replication relationship may be established between a first storage endpoint and a second storage endpoint, where at least one of the storage endpoints, such as the first storage endpoint, lacks or has incompatible functionality to perform and manage replication because the storage endpoints have different storage platforms that store data differently, use different control operations and interfaces, etc. Accordingly, replication destination workflow, replication source workflow, and/or a proxy representing the first storage endpoint may be implemented at the second storage endpoint comprising the replication functionality. In this way, replication, such as snapshot replication, may be implemented between the storage endpoints by the second storage endpoint using the replication destination workflow, the replication source workflow, and/or the proxy that either locally executes tasks or routes tasks to the first storage endpoint such as for data access.

Cross-platform replication

To replicate a source LUN to a different storage system platform, a first storage system transmits a request to replicate a LUN along with attributes for the LUN to a second storage system. The second storage system maps the attributes to attributes used and understood by the platform of the second storage system. The second storage system then creates a destination LUN based on the mapped attributes. Since the destination LUN is created with similar attributes as the source LUN, the destination LUN can store the replicated data of the source LUN while still being accessed and recognized as a LUN by the second storage system. The second storage system also stores any proprietary attributes received from the first storage system so that the proprietary attributes can be supplied to the first storage system to recover the source LUN after a data loss event.

Cross-platform replication of logical units

The disclosed techniques enable push-based piggybacking of a source-driven logical replication system. Logical replication of a data set (e.g., a snapshot) from a source node to a destination node can be achieved from a source-driven system while preserving the effects of storage efficiency operations (deduplication) applied at the source node. However, if missing data extents are detected at the destination, the destination has an extent pulling problem as the destination may not have knowledge of the physical layout on the source-side and/or mechanisms for requesting extents. The techniques overcome the extent pulling problem in a source-driven replication system by introducing specific protocols for obtaining missing extents within an existing replication environment by piggybacking data pushes from the source.

Push-based piggyback system for source-driven logical replication in a storage environment

A technique to name data is disclosed to allow preservation of storage efficiency over a link between a source and a destination in a replication relationship as well as in storage at the destination. The technique allows the source to send named data to the destination once and refer to it by name multiple times in the future, without having to resend the data. The technique also allows the transmission of data extents to be decoupled from the logical containers that refer to the data extents. Additionally, the technique allows a replication system to accommodate different extent sizes between replication source and destination while preserving storage efficiency.

Handling data extent size asymmetry during logical replication in a storage system

The technology disclosed relates to a STRADL file system that transparently deploys file blocks across multiple tiers of storage. In a cloud-based storage platform, multiple storage tiers host data via file system APIs. This includes a volatile storage (VS) tier with a VS API, a reliable non-volatile storage (RNVS) tier with a RNVS API, and a highly reliable non-volatile storage (HRNVS) tier with a HRNVS API. The STRADL file system provides an intermediary file system API that presents to a host system a single interface and translates get, put, and other file system requests into commands compatible with the VS API, the RNVS API, and the HRNVS API, without host system awareness of which of the multiple tiers holds requested data and metadata.

Multi-tier cloud file system

An enterprise may use file level and block level storage for operational access to reap the performance benefits, and use object storage for back-up storage and scale out. Data of objects and objects themselves can be organized to allow for efficient storage management operations, including storage snapshot operations and deduplication operations. A root file container can be represented in object storage with a metadata object ('file container object') and child file container can be represented in object storage with a metadata object ('file group object'). Each file can be represented in object storage with a metadata object that indicates the data units of the file depending upon the storage technology hosting the file (e.g., a file data block in file level storage). The data units of the file can be represented in object storage as elements of a data object.

Cloud object data layout (CODL)

Growing community of inventors

Fremont, CA, United States of America

Vijay Mohan Deshmukh