Abstract: A method and system for stream optimized backups to a cloud object store. When considering data protection, many prominent applications engage in backup operations by streaming their respective data to the cloud; however, the stream(s) is/are often ill-optimized (e.g., non-uniform data rates, non-uniform block sizes, different backup types, non-uniform data types or formats, etc.) to be written into cloud storage. The disclosed method and system, accordingly, propose a dynamic framework through which any arbitrary backup stream may be optimized according to the profile of any specific cloud-based object data store.

Abstract: Embodiments described herein relate to a method for managing file based backups (FBBs). The method may include obtaining a FBB mount request for a FBB mount of a FBB from an application, wherein the application is executing in a production host environment and the FBB is stored on backup storage; in response to the FBB mount request: capturing an entity context associated with the application; authenticating the entity context; obtaining, when the authenticating is successful, access control information corresponding to the FBB from the backup storage; determining a subset of the FBB for which the access control information indicates the entity context has permission to access; and enabling access to a portion of the FBB by the application.

Abstract: A registry writer is instructed via a copy service on a host to prepare for generation of a snapshot. The registry writer is responsible for saving system hive files to disk before the snapshot is generated. A reporting of the system hive files is received from the registry writer. Communications are exchanged with an API exposed by an operating system of the host to identify user hive files. The system hive files reported by the registry writer and the user hive files identified using the API exposed by the operating system are backed up from the snapshot to secondary storage.

Abstract: Writers participating in a backup are identified. A mapping is generated between the writers and associated files. The mapping includes file properties. The mapping is initialized by tagging the writers with a full backup tag. A base backup copy of the writers is created by conducting a full backup of each writer tagged with the full backup tag. At a current backup operation after creating the base backup, a list of current files that will participate in the current backup operation is generated. The list of current files is compared against the files in the mapping to determine whether a particular writer associated with a current file should be tagged with the full backup tag or an incremental backup tag. The particular writer is tagged with the incremental backup tag when file properties associated with the current file have changed.

Abstract: Network configuration details associated with a host are collected with each bare metal recovery (BMR) backup of the host. The network configuration details are stored in backup storage with each BMR backup copy. A target host is booted into a preinstallation environment. The target host is configured into a DHCP mode to allow the target host to establish a network connection to a backup management server. Details about the host are received from a user. A listing of BMR backup copies corresponding to the host details are retrieved from the backup management server. A selection of a BMR backup copy to be restored onto the target host is received. Network configuration details corresponding to the selected BMR backup copy are downloaded from backup storage. A recovery wizard at the target host is populated with the network configuration details.

Abstract: Communications are exchanged with a copy service of a host to identify writers associated with the copy service. The identification includes a type of a writer as being a system or application writer. Writers identified as system writers are added to a list of writers that should participate in a backup operation. For writers identified as application writers, components of an application writer are iterated through to determine whether a component of the application writer has a name or logical path that includes a name of a system service. When any component has the name or logical path that includes the name of the system service, the application writer is promoted to be of type system writer by adding the application writer to the list of writers that should participate in the backup operation. Components of each writer listed in the list of writers are backed up.

Abstract: A data structure is generated to store information about a set of writers associated with a copy service. The information is gathered from the copy service and populated into the data structure. The information includes names of the writers, writer types as being system or application writers, and system writer subtypes as being one of bare metal recovery (BMR) writers or system state recovery (SSR) writers. The data structure is reviewed to determine whether a particular writer should participate in the backup. Based on the review, a list is generated including a subset of the participating writers. Instructions are issued, via the copy service, for the writers in the list to prepare for creation of a snapshot. Upon creation of the snapshot, data is backed up from the snapshot to secondary storage.

Abstract: Writers on a host and associated with a copy service are identified. The identification includes names of the writers and writer types as being system or application writers. For each writer identified as a system writer, a size of the system writer is calculated and a check is made as to whether a volume associated with the system writer includes system data. When the volume include system data, the volume is marked as a critical volume and a size of the critical volume is obtained. A tally is maintained summing the sizes of the system writer and critical volume.

Abstract: A target host is booted into a preinstallation environment. A request to register as a recovery agent is issued from a REST API of the target host to a backup management server. A TLS certificate to establish a secure channel is received from the backup management server. A request identifying a backup copy to be stored on the target host is issued from the REST API of the target host and over the secure channel to the backup management server. Credentials required to access a backup storage at which the backup copy is stored is received. Using the credentials, the backup copy is retrieved from the backup storage.

Abstract: Writers participating in a backup are identified. A mapping is generated between the writers and associated files. The mapping includes file properties. The mapping is initialized by tagging the writers with a full backup tag. A base backup copy of the writers is created by conducting a full backup of each writer tagged with the full backup tag. At a current backup operation after creating the base backup, a list of current files that will participate in the current backup operation is generated. The list of current files is compared against the files in the mapping to determine whether a particular writer associated with a current file should be tagged with the full backup tag or an incremental backup tag. The particular writer is tagged with the incremental backup tag when file properties associated with the current file have changed.

Abstract: Described is a system (and method) for providing multiple types of granular delete operations for a cloud-based object storage. The system may include a server that acts as an intermediary between a client device and an object storage that stores client data. The server may allow a client to perform a hard delete (or permanent) delete and a soft delete. The server may perform a specialized processing to synthetically create the soft delete feature using a permanent object delete operation provided by the object storage. The specialized processing may include manipulating retention periods associated with objects depending on whether the object is subject to a hard delete or a soft delete. As a result, the server may provide the ability for clients to perform a soft delete at an object level using existing storage level APIs that do not directly support such a feature.

Abstract: Described is a system for predictive storage policy selection for a cloud-based storage based on backup monitoring. The system may reduce storage costs incurred by a subscriber of a backup service that leverages a cloud-based storage. The system may monitor backup operations and collect backup statistics associated with the resource requirements of performing a backup to a cloud-based storage. To collect such information, the system may execute a specialized monitoring process that works in conjunction with a backup application and/or server. The collected information may be stored as part of a metadata database associated with the object storage. Accordingly, the system may retrieve the information from the metadata database to predict storage costs associated with performing future backup operations. Based on the predicted storage costs, the system may automatically select an appropriate storage policy.

Abstract: A method and system for implementing a topological view and insights of organization information technology (IT) environments based on bare-metal recovery and/or system-state recovery data and metadata. Often, one or many IT environment(s), affiliated with an organization, include various network resources, as well active directory service(s) for organizing, locating, and managing said network resources. Active directory service(s) may further gather and provide information pertinent to modeling a topological view of said network resources throughout the organization. Leveraging said information gleaned from any active directory service(s), as well as backup operation metadata generated during or following backup operations targeting workloads and their respective data, which support bare-metal and/or system-state recoveries, embodiments disclosed herein propose the construction of an organization metadata tree.

Abstract: A method for copying source data from a source server to a destination server, that includes initiating, by a source copy manager, a copy operation of the source data, where during the copy operation, the method further includes obtaining resource statistics, setting a data chunk size based on the resource statistics, copying a data chunk to a read queue, where the data chunk includes a portion of the source data, and where the data chunk has the data chunk size, and sending, from the read queue, the data chunk to a network device, and ending the copy operation.

Abstract: Described is a system for synchronizing expiration times for incremental backup data stored on a cloud-based object storage. More particularly, the system may provide a layer of intelligence when updating the expiration times associated with backup data to ensure that a full recovery of the client data to a point-in-time of any incremental backup may be performed. To provide such a capability, the system may maintain specialized metadata identifying expiration times for objects and a list of objects required to perform a full recovery to a point-in-time for each of the performed backups (e.g. full or incremental). The system may access this metadata to identify which objects stored by a previous backup are still referenced by a subsequent backup. Based on the identified objects, the system may synchronize object expiration times to ensure objects are not prematurely deleted from the object storage.

Abstract: One or more embodiments of the invention performs an incremental backup by crawling only those folders which have changed. By comparing a folder's attributes with those in a backup's meta-data, an intelligent file system crawler can determine if the underlying files and sub-folders of the folder have undergone a change. If they have, then the one or more embodiments of the invention proceeds to crawl the underlying sub-folders. If the folder's attributes have not changed, then the intelligent file system crawler of one or more embodiments of the invention proceeds to the next folder and does not crawl the underlying sub-folders. By doing this, one or more embodiments of the invention can crawl the entire file system quicker, since those folders that have not undergone a change since the last backup was performed, do not have their sub-folders crawled.

Abstract: A method and system for workload anomaly detection for standalone hosts based on bare-metal recovery and/or state-system recovery data and metadata. In isolated circumstances, workloads tend to operate as expected, however, their behavior and/or functionality may become unpredictable when said workloads are exposed to other factors outside of isolation. Further, most of these other factors, as well as their influence on workload behavior and/or functionality tend to go unnoticed by administrators. Data and/or metadata, pertinent to bare-metal recovery and/or system-state recovery operations, may capture host-relevant information, including which workload(s) is/are installed on a host, which file-system objects maintained thereon belong to which installed workload, and what is the nature and storage location of each file-system object.

Abstract: A method and system for implementing a topological view and insights of organization information technology (IT) environments based on bare-metal recovery and/or system-state recovery data and metadata. Often, one or many IT environment(s), affiliated with an organization, include various network resources, as well active directory service(s) for organizing, locating, and managing said network resources. Active directory service(s) may further gather and provide information pertinent to modeling a topological view of said network resources throughout the organization. Leveraging said information gleaned from any active directory service(s), as well as backup operation metadata generated during or following backup operations targeting workloads and their respective data, which support bare-metal and/or system-state recoveries, embodiments disclosed herein propose the construction of an organization metadata tree.

Abstract: A method and system for shared workload anomaly detection across multiple hosts based on bare-metal recovery and/or system-state recovery data and metadata. Since at least said bare-metal recovery and/or system-state recovery metadata has information about each workload operating on one or many host(s), comparing said metadata across any set of hosts could provide the pattern of data being generated there-across. Further, other metadata generated by any shared workload instance(s), operating on a set of hosts, should be consistent across the set of hosts. Should a shared workload instance on one or more hosts generate metadata not sync with metadata generated from a baseline shared workload instance, such discrepancies could be a sign of unwanted anomalies that may warrant further analyses, alerts, etc.

Abstract: In accordance with one or more embodiments of the invention, when restoring data from a backup that is at least partially stored on the cloud, the meta-data and data forming the backup are not in sync with the local meta-data. When restoring the data, once the backup data and backup data is copied to the desired location on the production host, the backup data and backup meta-data need to be linked back up. Once the backup data and backup meta-data is copied to the target production host, the backup meta-data is linked with the backup data and then the restoration is indicated as having been completed. By performing the linkage during the restoration, prior to the restore being indicated as being complete, delays in production workloads and productivity can be avoided.