Abstract: A storage tier manager efficiently creates different representations of a dataset backup for different retention periods. Each of the representations of the dataset backup is distinctly identifiable despite initially representing a same dataset backup. The representations are structured metadata corresponding to the dataset backup. One representation is a cached backup version of the dataset backup (“cached backup” or “cached representation”) provided for low latency access while residing at a storage tier of the backup appliance for a relatively short retention period according to a lifecycle management policy. The other representation is a cloud backup version of the dataset backup (“cloud backup” or “cloud representation”) provided for persisting into cloud storage for a longer retention period according to the lifecycle management policy.

Abstract: A storage tier manager creates different versions of a dataset backup for different retention periods. Each of the versions is distinctly identifiable despite initially representing a same dataset backup. One version can be referred to as a cached version of the dataset backup and another version can be referred to as a cloud version of the dataset backup. When the retention period expires for the cached version of the dataset backup, the storage tier manager migrates the cloud version of the dataset backup from the caching storage tier to the cloud storage tier. The storage tier manager can then recover storage space occupied by data that has been migrated, as long as that data is not shared with other cached versions of other dataset backups due to deduplication.

Abstract: A storage tier manager creates different representations of a dataset backup for different retention periods. Each of the representations of the dataset backup is distinctly identifiable despite initially representing a same dataset backup. The representations are structured metadata corresponding to the dataset backup. One representation is a cached backup version of the dataset backup (“cached backup” or “cached representation”) provided for low latency access while residing at a storage tier of the backup appliance for a relatively short retention period according to a lifecycle management policy. The other representation is a cloud backup version of the dataset backup (“cloud backup” or “cloud representation”) provided for persisting into cloud storage for a longer retention period according to the lifecycle management policy.

Abstract: A cloud storage gateway device can be used to deduplicate data across different namespaces while complying with SLOs that govern data of the different namespaces. A cloud storage gateway device can use multiple fingerprint indexes to comply with different SLOs. Each fingerprint index corresponds to a different SLO. Thus, the cloud storage gateway device deduplicates data against other data governed by a same SLO. Assuming an SLO aligns or indicates a cloud storage target, the cloud storage gateway device will deduplicate data against other data that will eventually migrate from the device to a same cloud storage target. The cloud storage gateway device ensures satisfaction of the governing SLO(s) from receipt of data, through deduplication, to the migration of the data to a cloud storage target.

Abstract: Exemplary embodiments relate to cache replacement schemes. Incoming data may be sorted into buckets. When it comes time to replace information in the cache, an entire bucket may be eliminated or replaced at once. By sorting incoming data into the buckets and performing cache replacement on a bucket-by-bucket basis, cache fragmentation is reduced. Moreover, the buckets may be scored based on characteristics of the data in the buckets (e.g., whether a data item is cold archived, whether a customer has pinned the data item, or whether the customer has requested early eviction of the data item). By accounting for these metrics when the cache score is calculated, cache usage and hit rates may be improved. According to exemplary embodiments, scoring may be applied to entire buckets, or may be applied to individual cache items (e.g., for use as a cache replacement metric in a cache eviction scheme).

Abstract: Exemplary embodiments relate to cache replacement schemes. Incoming data may be sorted into buckets. When it comes time to replace information in the cache, an entire bucket may be eliminated or replaced at once. By sorting incoming data into the buckets and performing cache replacement on a bucket-by-bucket basis, cache fragmentation is reduced. Moreover, the buckets may be scored based on characteristics of the data in the buckets (e.g., whether a data item is cold archived, whether a customer has pinned the data item, or whether the customer has requested early eviction of the data item). By accounting for these metrics when the cache score is calculated, cache usage and hit rates may be improved. According to exemplary embodiments, scoring may be applied to entire buckets, or may be applied to individual cache items (e.g., for use as a cache replacement metric in a cache eviction scheme).

Abstract: A storage tier manager creates different versions of a dataset backup for different retention periods. Each of the versions is distinctly identifiable despite initially representing a same dataset backup. One version can be referred to as a cached version of the dataset backup and another version can be referred to as a cloud version of the dataset backup. When the retention period expires for the cached version of the dataset backup, the storage tier manager migrates the cloud version of the dataset backup from the caching storage tier to the cloud storage tier. The storage tier manager can then recover storage space occupied by data that has been migrated, as long as that data is not shared with other cached versions of other dataset backups due to deduplication.

Abstract: A storage tier manager creates different representations of a dataset backup for different retention periods. Each of the representations of the dataset backup is distinctly identifiable despite initially representing a same dataset backup. The representations are structured metadata corresponding to the dataset backup. One representation is a cached backup version of the dataset backup (“cached backup” or “cached representation”) provided for low latency access while residing at a storage tier of the backup appliance for a relatively short retention period according to a lifecycle management policy. The other representation is a cloud backup version of the dataset backup (“cloud backup” or “cloud representation”) provided for persisting into cloud storage for a longer retention period according to the lifecycle management policy.

Abstract: A storage tier manager efficiently creates different representations of a dataset backup for different retention periods. Each of the representations of the dataset backup is distinctly identifiable despite initially representing a same dataset backup. The representations are structured metadata corresponding to the dataset backup. One representation is a cached backup version of the dataset backup (“cached backup” or “cached representation”) provided for low latency access while residing at a storage tier of the backup appliance for a relatively short retention period according to a lifecycle management policy. The other representation is a cloud backup version of the dataset backup (“cloud backup” or “cloud representation”) provided for persisting into cloud storage for a longer retention period according to the lifecycle management policy.

Abstract: Exemplary embodiments address the problem of disk fragmentation by using the heuristics of write operations to assign block sizes. As write requests are received, a storage system may register a size of the write request. Using the registered sizes, the storage system may identify one or more clusters of sizes at which write requests are particularly prevalent. The storage system may calculate a distribution or variance for block sizes centered on each cluster. The distribution or variance may be used to distribute the block sizes such that the block sizes change by a small amount in the vicinity of the cluster, and by a larger amount as the blocks move away from the center of the cluster. When it comes time to allocate new blocks, the clusters and distribution may be consulted to determine what sizes of blocks to allocate, and how many blocks of each size.