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

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

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

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

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

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

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

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

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

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

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

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

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