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: Embodiments of the invention relate to generating backups of applications. The user or administrator that monitors the backup is notified of those files and/or folders that have not been backed up in the most recent backup. Further, embodiments of the invention enable alerts to be initiated when a particular file or folder has not been backed up over multiple backups or over a predetermined period. As a result, the user or administrator can have a better understanding of the protection and lack of protection that the present backups are providing.

Abstract: A method for performing a backup includes: obtaining a file system backup metadata associated with a target file system of a target production host; processing the file system backup metadata to determine protected data and unprotected data in the target file system; after processing the file system backup metadata, using the file system backup metadata to generate a backup history dataset for the target file system; generating a protection status for each data in the target file system based on the backup history dataset and the determined protected data and unprotected data of the target file system; generating a graphical user interface (GUI) for the target file system showing the data of the target file system along with the protection status of each of the data of the target file system; and displaying, on a display of a computing device and to a user, the GUI.

Abstract: A method for performing a backup includes: obtaining a file system backup metadata associated with a target file system of a target production host; processing the file system backup metadata to determine protected data and unprotected data in the target file system and protection failure details associated with the unprotected data; generating, using the protected data, the unprotected data, and the protection failure details associated with the unprotected data, a graphical user interface (GUI) specifying a protection status of the target file system; and displaying, on a display of a computing device and to a user, the GUI.

Abstract: A method for performing a backup includes: receiving, by a computing device, a native view request for a graphical user interface (GUI) of a local file system; intercepting, by a backup services agent executing on the computing device, the native view request before the GUI is generated; obtaining, by the backup services agent and in response to intercepting the native view request, a file system backup metadata associated with the local file system from a backup storage device and a local file system metadata associated with the local file system from a local storage of the computing device; generating a combined file system content list using the file system backup metadata and the local file system metadata; generating the GUI using the combined file system content list; and displaying, on a display of the computing device and to a user, the GUI.

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: 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: Described is a system (and method) for size-based organization of backup files within an object storage for efficient object re-tiering. The system may perform a specialized process to re-tier objects stored within an object storage by organizing backup files into individual or shared objects based on a backup file size. Accordingly, the system may initiate a re-tiering of objects immediately after performing an incremental backup to improve storage efficiency while at the same time retaining the ability to synthetically perform a full restore.

Abstract: A method and system for enabling incremental backup operations targeting bare-metal recovery and system-state recovery data and metadata. These aforementioned forms of recovery focus on the protection of computing system state, including operating system binaries and configuration, as well as the data, metadata, and/or configuration of software application(s) installed on said computing system(s). Further, the data and/or metadata reflected in said computing system state often remains unchanged unless operating system and/or software application component(s) or feature(s) is/are uninstalled, installed, and/or upgraded. Existing solutions protecting said data and/or metadata tend to only support full backup operations, which are time and storage space inefficient. Ideally, incremental backup operations targeting said data and/or metadata should be provided.

Abstract: A method for generating data backups, that includes receiving, by a local backup manager executing on a local storage server, a command to initiate a backup process for a virtual data pool, and in response to receiving the command, identifying a plurality of locations pointing to a plurality of data, respectively, making a first determination that a first location points to a remote data stored on a remote storage server, in response to the first determination, sending a second command, to the remote storage server, to generate a remote backup data of the remote data, making a second determination that a second location points to a local data stored on the local storage server, and in response to the second determination, generating a local backup data of the local data, where the plurality of data backups includes the remote backup data and the local backup data.

Abstract: A method for performing data backup includes: receiving a backup request specifying a file where the file is stored in a shared storage. Additionally, in response to the backup request: retrieving, by a primary data node, properties of the file; determining, by the primary data node, resource availability for plurality of secondary data nodes where the primary data node and the plurality of secondary data nodes is operatively connected to the shared storage and a backup storage; logically dividing, by the primary data node, the file into a plurality of segments using at least the properties of the file; and coordinating, by the primary data node, the backup of the file using the plurality of segments and the resource availability of the plurality of secondary data nodes.

Abstract: A method for performing a data backup process on a cluster includes: obtaining a backup generation request for virtual machines; in response to obtaining the backup generation request: generating a first set of backup groupings based on the backup generation request where each of the first set of backup groupings includes at least one of the virtual machines; issuing a disable migration command to a plurality of production hosts where each of the plurality of production hosts is associated with at least one of the virtual machines; identifying, after the issuing, a virtual machine of the virtual machines that is migrating; removing, based on the identifying, the virtual machine from the first set of backup groupings to obtain a second set of backup groupings where the virtual machine is placed in an excluded group after the removing; and backing up the second set of backup groupings.

Abstract: Described is a system for rule-based re-tiering of backup data stored on a cloud-based object storage. More specifically, the system may re-tier objects based on one or more storage rules 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 initiating a re-tiering based on one or more storage rules, the system may intelligently select candidate objects for re-tiering by leveraging the metadata database to ensure that objects that may still need to be referenced are not unnecessarily moved to a lower storage tier.

Abstract: A Building Management System (BMS) includes a plurality of building subsystems and communications interface. The building subsystems include device(s) for controlling aspect(s) of the building subsystem. The communications interface receives commands from a cloud-based controller and a local client device. The commands from the cloud-based controller and local client device are structured to modify setting(s) for a device of the building subsystems. A BMS controller receives, via the communications interface from the cloud-based controller, a command for modifying a setting of a device for a first building subsystem. The BMS controller identifies a local setting of the device provided by the local client device. The BMS controller identifies a priority of the command from the cloud-based controller in relation to a priority of the local setting. The BMS controller controls the device based on the respective priorities.

Abstract: Embodiments for an intelligent log analysis and retention for microservices applications. Such log analysis is helpful in troubleshooting failure conditions that may occur intermittently or repeatedly within a microservices environment. Executed operations by microservices, applications, or components generate logs, and these logs are classified based on certain parameters. A default log retention period defines how long the logs are stored in the system, and a log analytical engine determines and assigns weights constituting additional retention time to keep logs for failed operations. These logs can then be analyzed to determine causes of the failure, and build failure models to predict future failure conditions. Logs for successful operations can be timely deleted to save storage space.

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 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: 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 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 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.