Abstract: A smart prefetching of operations technique prefetches metadata and/or data of objects stored in a multi-cloud snapshot technology (MST) service associated with an object store. One or more data objects (e.g., an application) at a primary site may be designated for backup or failover to a secondary site, e.g., in the event of failure of the primary site. Smart prefetching logic of the MST is configured to prefetch the object metadata and/or object data from the object store to serve subsequent requests without accessing the object store. To that end, when storing data to the object store as one or more objects, MST maintains specific metadata along with the data of the objects. The technique utilizes the specific metadata to prefetch the object metadata and/or object data before receiving actual read requests for that data to improve the read latency and throughput when restoring the application as soon as possible.

Abstract: A technique enables coordination of unrelated software components to facilitate extensive recovery point management on a snapshot or recovery point through the use of a flexible tag structure. The tag is organized and arranged as a {key=value,[value] . . . } structure wherein the key denotes an operation that requires coordination between the unrelated software components and the value(s) denote multi-cardinality that provide parameters for coordination of the operation. The multi-cardinality aspect of the flexible tag structure provides a set of values associated with the key of the tag that enables a software component and/or protocol to insert its value(s) into the tag structure for its interpretation. The technique thus provides an extensible model where multiple components/protocols use the tag to coordinate operations on the RP by conveying certain meaning/interpretations of the tag and its values.

Abstract: A technique enables recovery of failover data used to generate one or more High Frequency Snapshots (HFSs) at a source and replicated to a target for storage and recovery. The target is illustratively an intermediary repository embodied as a long-term storage service (LTSS) configured to organize and store the HFSs as recovery points (RPs) in an object store. The LTSS stores a HFS identifier (ID), a logical offset in an object of the object store storing data of the HFS, and a logical timestamp associated with each replicated HFS as a key of a segment descriptor in a key-value database configured to store metadata describing the failover data of the HFS stored as one or more objects in the object store. Upon recovery of the failover data, the technique enables identification of the HFS stored in the object store and creation of a HFS index metadata structure (B+ tree) to extract the identified HFS as a RP.

Abstract: A technique enables coordination of unrelated software components to facilitate extensive recovery point management on a snapshot or recovery point through the use of a flexible tag structure. The tag is organized and arranged as a {key=value,[value] . . . } structure wherein the key denotes an operation that requires coordination between the unrelated software components and the value(s) denote multi-cardinality that provide parameters for coordination of the operation. The multi-cardinality aspect of the flexible tag structure provides a set of values associated with the key of the tag that enables a software component and/or protocol to insert its value(s) into the tag structure for its interpretation. The technique thus provides an extensible model where multiple components/protocols use the tag to coordinate operations on the RP by conveying certain meaning/interpretations of the tag and its values.

Abstract: A technique enables recovery of failover data used to generate one or more High Frequency Snapshots (HFSs) at a source and replicated to a target for storage and recovery. The target is illustratively an intermediary repository embodied as a long-term storage service (LTSS) configured to organize and store the HFSs as recovery points (RPs) in an object store. The LTSS stores a HFS identifier (ID), a logical offset in an object of the object store storing data of the HFS, and a logical timestamp associated with each replicated HFS as a key of a segment descriptor in a key-value database configured to store metadata describing the failover data of the HFS stored as one or more objects in the object store. Upon recovery of the failover data, the technique enables identification of the HFS stored in the object store and creation of a HFS index metadata structure (B+ tree) to extract the identified HFS as a RP.