Emc IP Holding Company LLC

Maginatics LLC

Kasten, Inc.

Julio Lopez

Thomas Manville

Rajiv Desai

Nathan Rosenblum

Thomas E Sandholm

Vaibhav Kamra

Niraj Tolia

Nishesh Gupta

Dilip N Simha

Shrinand Javadekar

Deepika Dixit

Carl Braganza

Pavan Navarathna Devaraj

Embodiments described herein are directed to backing up and recovering cloud-native applications. In some embodiments, the data engine maps a first set of data volumes to a data repository dedicated to store a backup of the data associated with the application. Furthermore, the data engine transmits, using a dynamically generated process, the data stored in the identified first set of data volumes to the data repository for backup based on the mapping. The data engine may also initiate a recovery of the application. The data engine may use a new dynamically generated process to identify and transmit a respective data set to a corresponding data volume for storage. Moreover, the data engine may use the new process to restore the components of the application using each respective identified data set.

Backing-up application data from cloud-native applications

Disclosed herein are system, method, and computer program products for storing a snapshot of block-level changes in a data volume using a file system-level backup tool. An embodiment operates by receiving the block level changes in the snapshot from the data volume stored in an application in a cluster. The embodiment creates a root directory for the snapshot. The root directory may have one or more subdirectories. The embodiment maps one or more block changes in the data volume onto the one or more subdirectories and creates a manifest for identifying the snapshot in the file system-level backup tool. The manifest may be associated with the root directory. The embodiment then instructs the file system-level backup tool to store the snapshot by storing the root directory in content-addressable object storage based on the one or more subdirectories and storing the manifest in a manifest storage.

Change block tracking in cloud orchestration systems

Disclosed herein are system, method, and computer program product embodiments for encryption key management. An embodiment operates by executing an initial non-backup instance of an application and generates a primary key using a cryptographic algorithm. The embodiment requests a customer to create a passphrase configured to encrypt and decrypt the primary key. The embodiment generates a derived key using a cryptographic algorithm and the customer passphrase as input. The embodiment then encrypts the primary key using the generated derived key and stores the encrypted primary key in a catalog.

Encryption key management

Techniques to reduce database fragmentation are disclosed. In various embodiments, an indication is received to store an attribute value for an entity that has a row or other entry in a first database table, wherein the first database table does not have a column for the attribute. It is determined that the value corresponds to a mapped value that is associated with not having an entry in a separate, second database table configured to store the attribute. Entries are made in the second database table only for values of the attribute other than the mapped value. Application level software code is configured to associate absence of a row in the second database table with the mapped value for the attribute.

Reducing database fragmentation

Systems and methods for deduplicating data are provided. An index used in deduplicating data is distributed to clients. The clients can use the distributed index to provide hints as to whether the data is deduplicated at the server. The server may be associated with a main index used to confirm whether the data is deduplicated based on the hints.

Distributed client side deduplication index cache

A request is received to copy a file from a source to a target in a file system. The source is associated with a source inode, and the target is associated with a target inode. A list is generated of the one of the source or target inodes followed by another of the source or target inodes according to inode numbers identifying the source and target inodes. A first determination includes determining that the one inode is the source inode and the other inode is the target inode. When the first determination is made, a read rename lock is acquired for the source inode, followed by a write rename lock for the target inode, followed by a read inode lock for the source inode, followed by a write inode lock for the target inode. After the locks have been acquired, a chunk map of the source inode is copied to the target inode.

Deadlock-free locking for consistent and concurrent server-side file operations in file systems

A combined object associated with a data chunk included in a request file is determined. An encryption key associated with the combined object and a corresponding chunk hash value associated with the data chunk are used to determine a corresponding chunk key associated with the data chunk. At least a locator to be used to retrieve the combined object and the corresponding chunk key associated with the data chunk are provided to a requesting system.

Secure cloud-based storage of data shared across file system objects and clients

Techniques to provide a de-duplicating distributed file system using a cloud-based object store are disclosed. In various embodiments, a request to store a file comprising a plurality of chunks of file data is received. A determination to store at least a subset of the plurality of chunks is made. The request is responded to at least in part by providing an indication to store two or more chunks comprising the at least a subset of the plurality of chunks comprising the file as a single stored object that includes the combined chunk data of said two or more chunks.

De-duplicating distributed file system using cloud-based object store

Epoch-based management of file system data is disclosed. In various embodiments, for each of a plurality of snapshots, data that associates with the snapshot a corresponding last chunk identifier assigned as of a time at which the snapshot is or was created is stored a in a first data structure. For each of a plurality of chunks of file system data no longer referenced by any live file system object, an epoch identifier associated with an epoch in which the chunk became no longer referenced by any live file system object is stored in a second data structure. A chunk identifier and associated epoch comprising an entry in the second data structure are compared with one or more entries in the first data structure to determine whether a chunk associated with the chunk identifier is associated with a snapshot that continues to be retained.

Epoch based snapshot summary

Systems and methods for protecting and deduplicating streams of data in a cloud based platform. A platform is configured with multiple services and can communicate with multiple clients. The platform receives all requests at an endpoint and distributes the requests to workers using multiple queues. The platform may be stateless and is scalable. The meta-data is handled separately from the data in one example.

Scalable cloud hosted metadata service

Techniques to provide secure cloud-based storage of data shared across file system objects and clients are disclosed. In various embodiments, a primary encryption key is determined for an object associated with a plurality of component chunks of file system data. The primary encryption key is used to generate for each of said component chunks a corresponding chunk key, based at least in part on the primary encryption key and data comprising or otherwise associated with the chunk. The respective chunk keys are provided to a file system client configured to create and store the object at least in part by encrypting each chunk included in the plurality of component chunks using the chunk key provided for that chunk to generated encrypted chunk data, and combining the encrypted chunk data to create and store the object.

A partitioned Bloom filter is disclosed. In various embodiments, a representation of an item is received. The representation is used to determine a partition with which the item is associated. A partition-specific Bloom filter is used to determine at least in part whether the item may be an element of a set with which the partition is associated.

Bloom filter partitioning

A request is received to copy a file from a source to a destination, the source being associated with a source inode, and the destination being associated with a destination inode. The source and destination inodes are sorted into a sorted order according to inode numbers identifying the source and destination inodes. Based on the sorted order, rename locks are acquired on the source and destination inodes. Based on the sorted order, inode locks are acquired on the source and destination inodes. After the rename and inode locks have been acquired, chunk map entries of the source inode are copied as entries of the destination inode to fulfill the request.

Growing community of inventors

Mountain View, CA, United States of America

Julio Lopez