Abstract: A method and system for machine learning based predictions of upgrade testing outcomes for information technology (IT) environments. At least with respect to computing, an upgrade may entail the replacement of a product—in the form of hardware, software, and/or firmware—with a newer or better version, which may serve to bring the product up to date, improve the characteristic(s) of the product, and/or resolve any issue(s) inflicting the product. Further, through the process of upgrade testing, an upgrade may be assessed to determine its impact on an operability of varying environments following application of the upgrade thereon. Moreover, each environment may reflect a different history of product upgrades that had been applied thereon prior to the upgrade being tested. The disclosed method and system, accordingly, propose a framework directed to ascertaining the post-upgrade outcomes of actual IT environments using machine learning applied to post-upgrade outcomes of simulated IT environments.

Abstract: A method for managing a client environment includes obtaining, by a state processor, a state prediction request associated with an application upgrade on an emulation of a client device; in response to the state prediction request: obtaining live data associated with the application upgrade; performing natural language processing on the live data to obtain processed live data; applying a state prediction model to the processed live data to generate a state prediction; making a first determination that the state prediction indicates that the application upgrade was not successful; and in response to the first determination: making a second determination that the state prediction indicates that the application upgrade is fixable; and in response to the second determination: initiating the remediation of the application upgrade.

Abstract: A method and system for predicting post-upgrade outcomes in information technology environments through proactive upgrade issue testing. At least with respect to computing, an upgrade may entail the replacement of a product—in the form of hardware, software, and/or firmware—with a newer or better version, which may serve to bring the product up to date, improve the characteristic(s) of the product, and/or resolve any issue(s) inflicting the product. Further, the process of upgrading a product in view of an issue therein is often reactive—that is, it is often required that a customer experiences and reports an issue for a product to a vendor prior to the issuance of an upgrade to the customer that addresses the issue for the product by the vendor. Presently, what is lacking is a mechanism through which product upgrades may be presented to customers proactively in order to minimize product failure and/or downtime.

Abstract: A method for managing a client environment includes obtaining, by a remediation orchestrator, a remediation request associated with a failed application upgrade on an emulation of a client device; in response to the remediation request: obtaining a remediation policy associated with the application upgrade; obtaining application upgrade information associated with the application upgrade; identifying remediation steps to service the remediation request using the application upgrade information and the remediation policy; and initiating performance of the application upgrade and the remediation steps on the client device.

Abstract: A method and system for version history based upgrade testing across simulated information technology (IT) environments. At least with respect to computing, an upgrade may entail the replacement of a product - in the form of hardware, software, and/or firmware - with a newer or better version, which may serve to bring the product up to date, improve the characteristic(s) of the product, and/or resolve any issue(s) inflicting the product. Further, through the process of upgrade testing, an upgrade may be assessed to determine its impact on an operability of varying environments following application of the upgrade thereon. The disclosed method and system, accordingly, propose a framework directed to conducting upgrade tests within simulated IT environments - each reflective of different computing resources and upgrade histories - where results of the simulations may be examined to ascertain which environment configurations (if any) may cause the tested upgrade to fail.

Abstract: A standby site is periodically synchronized to a primary site. The synchronizing includes copying blocks of a source volume at the primary site that have changed since a last synchronization to the standby site, and a bitmap specifying locations of the changed blocks. A synthetic full copy of the source volume is generated at the standby site. The synthetic full backup is validated by using the bitmap to identify locations on the synthetic full backup to verify. These locations correspond to the changed blocks. A progress of the validation is tracked. A user can specify a threshold percentage value of data that upon being validated indicates that the standby site is ready to assume production operation from the primary site. A readiness of the standby site to assume production operation is reported based on the progress of the validation and the threshold percentage value.

Abstract: A synthetic full backup of a source volume representing a state of the volume at a current time is retrieved, the synthetic full having been generated by merging a full backup of the volume performed at an initial time with an incremental backup of the volume performed at the current time, after the initial time. A bitmap tracking changes to the volume made between the initial and current times is accessed. The bitmap is used to identify a location on the volume having changes made between the initial and current times. First data written to the location on the volume is read. Second data written to the same location on the synthetic full backup is read. First and second checksums are generated based on the first and second data, respectively. The checksums are compared and if any do not match, an indication is generated that the synthetic full is corrupt.

Abstract: A changed block tracking (CBT) driver at a production host tracks, in a bitmap, changes made to a source volume of the production host since a last backup. A command is received to perform a differential backup of the source volume. A request is issued to a copy service to take a snapshot of the source volume. The bitmap is embedded into the snapshot. The snapshot is mounted on a backup proxy, different from the production host. The backup proxy retrieves the bitmap from the snapshot and conducts the differential backup of the source volume to secondary storage, thereby backing up the changes made to the source volume since the last backup according to the bitmap.

Abstract: An incremental backup is made of a source volume on a production host to on premise secondary storage. The incremental backup includes a bitmap specifying locations of blocks that have changed since a last backup of the source volume, and data of the changed blocks. First checksums are calculated from data of the changed blocks. The incremental backup, including the changed blocks and the bitmap, are moved to cloud storage. The changed blocks are merged, at the cloud storage, with the last backup of the source volume to generate a synthetic full backup of the source volume. The bitmap is consulted to identify locations of the changed blocks. Second checksums are calculated from data written to the locations on the synthetic full backup. The first and second checksums are compared. If the first and second checksums do not match, an indication is generated that the synthetic full backup is corrupt.

Abstract: A configuration file having options for validating backups is received. A request is issued to a copy service to take a snapshot of a volume to be backed up. A determination is made from the configuration file that a backup of the volume is to be validated. A script including code for generating first checksums of data captured by the snapshot is invoked. A backup copy of the volume is created using the snapshot. The backup copy is mounted. The mounted backup copy is read and second checksums of data that has been backed up are generated. The script is allowed to compare the first and second checksums. If any of the first and second checksums do not match, the backup copy is failed.

Abstract: A synthetic full backup of a source volume is retrieved, the synthetic full having been created from merging a backup chain including an incremental backup into a full backup. The full backup corresponds to a state of the source volume at a first time. The synthetic full corresponds to a state of the source volume at a second time, after the first time. A bitmap embedded into a snapshot of the source volume taken at the second time is retrieved. The bitmap identifies data from the source volume copied to secondary storage for the incremental backup. The backup chain is regenerated by copying from the snapshot the data identified by the bitmap to a regenerated incremental backup.

Abstract: A configuration file specifies a percentage value of data to validate. A synthetic full backup image of a source volume on cloud storage is accessed. The synthetic full backup is created by merging changed blocks of an incremental backup with another previous backup. A bitmap specifying locations of the changed blocks is examined. A region on the synthetic full backup beginning at a location corresponding to an initial changed block and ending at a location corresponding to a last changed block according to the bitmap is identified. The region is partitioned into a set of portions. Each portion is validated by randomly selecting blocks in a respective portion to validate. The validating of the respective portion continues until an amount of data validated in the respective portion reaches a size equal to the percentage value of a size of the incremental backup divided by a number of portions.

Abstract: A backup manager for providing backup services includes persistent storage and a backup orchestrator. The persistent storage includes protection policies. The backup orchestrator generates a backup for a client based on the protection policies; obtains system metadata from the client; generates a backup map for the backup based on the system metadata; generates a backup hierarchy for the backup based on the backup map; and stores the backup and at least one selected from a group consisting of the backup hierarchy and the backup map.

Abstract: A method for managing a client environment includes obtaining, by a client environment watcher of a production host environment, a set of actions performed by the client environment operatively connected to the production host environment, in response to obtaining the set of actions: performing an action filtering on the set of actions to obtain a set of filtered actions, wherein the set of filtered actions is associated with an attempt to resolve an issue with performing an application upgrade on the client environment, determining, using the set of filtered actions, a client-applied action set, and initiating an update to an issue analyzer model to obtain an updated issue analyzer model.

Abstract: A method for managing a client environment includes obtaining, by an issue analyzing engine, a notification for an issue based on an application upgrade on a client device of the client environment, in response to the notification: applying an issue analyzing model to device configuration information associated with a client device to obtain a solution set, providing the solution set to client environment, obtaining a result from the client environment associated with the issue and the solution set, and updating the issue analyzing model based on the result to obtain an updated issue analyzing model.

Abstract: Described is a system (and method) for leveraging data previously transferred to a cloud-based object storage as part of a failed backup when performing a subsequent backup operation. The system may leverage the native configuration of an object storage that may retain certain data even when a backup operation is classified as a failed operation. To provide such capabilities, the system may store specialized metadata that tracks which backups have failed and metadata indicating which backup data has not been committed. Accordingly, upon a subsequent backup operation, the system may expediently refer to the stored metadata to identify retained backup data that may be reused for the subsequent backup. As a result, the system may improve the efficiency of a backup procedure by reducing the amount of data required to be transferred from the backup source.

Abstract: Creating vendor-neutral data protection operations for vendors' application resources is described. Capabilities specified for data protection operations by a vendor of an application are input from a host of the application. Any capabilities specified for the data protection operations are used to create a vendor-neutral version of a data protection operation for a resource of the application. The vendor-neutral version of the data protection operation for the application resource is output to the host. A result of performing the vendor-neutral version of the data protection operation on the application resource is input from the host.

Abstract: Described is a system for intelligent re-tiering of backup data stored on a cloud-based object storage. More specifically, the system may re-tier objects such that the system retains the ability to efficiently perform a full restore of backup data even when incremental backups are performed to a cloud-based object storage. To provide such a capability, the system may maintain a specialized metadata database that stores information indicating the backup time for each backup, and a list of objects required to perform a full restore to each of the backup times. Accordingly, when using a threshold time (e.g. expiry) to select object candidates for re-tiering, the system may leverage the metadata database to ensure that objects that may still need to be referenced are not unnecessarily moved to a lower storage tier.

Abstract: Described is a system for managing the expiration of objects storing incremental backup data by leveraging specialized metadata. The system may provide a layer of intelligence when freeing up storage space on an object storage to ensure that a full recovery of client backup data may be performed when storing incremental backup data. The system may maintain metadata indicating the latest and/or earliest backups that reference particular objects. The system may then leverage this information to mark particular objects for removal (e.g. deletion or re-tiering). For example, the system may access the metadata to identify which objects stored by a previous (e.g. expired) backup are still referenced by a subsequent (e.g. non-expired) backup. As a result, the system may ensure that objects are not removed prematurely and that a full recovery of the client data to a point-in-time of any incremental backup may be performed.

Abstract: Described is a system (and method) for efficient access-based reallocation of backup data stored within an object storage. The system may implement various specialized procedures to efficiently store and manage backup data within the object storage. These procedures may include packing backup data into objects to improve data operation efficiency. The system may also conserve storage space on the object storage by performing an analysis to reallocate backup data as necessary. For example, data may be stored in objects in an immutable manner, and thus, the system may efficiently reallocate data to new objects based on data access patterns. For example, the system may determine an access pattern associated with live data remaining within the first object satisfies a condition, and in response, reallocated the live data to a new object.