Abstract: An information management system according to certain aspects can implement application archiving. The system may archive one or more applications on computing devices to make more storage space available on these devices. The system can determine which applications on client computing device to archive based on various factors. Some examples of factors can include frequency of use, application type, amount of application data and/or storage, user and/or device location, etc. The data to be archived can include one or more executable file(s), metadata, actual data, etc. After an application is archived, the system can generate a placeholder for the application; a placeholder can include information for restoring the archived application.

Abstract: A storage manager for an information management system determines whether one or more predetermined conditions have been met for transferring metadata of previously performed backup jobs stored in a first management database. A backup job may correspond to a backup operation of a primary storage device of a first client computing device. In response to a determination that one or more of the predetermined conditions have been met, the storage manager may transfer metadata for a second plurality of backup jobs to a second management database of a recovery manager. The recovery manager may receive a request to restore data to the primary storage device of the first client computing device based on the metadata of the second plurality of backup jobs. A media agent managed by the recovery manager may then restore the requested data to the primary storage device of the first client computing device.

Abstract: According to certain aspects, a secondary computing system can be configured to perform a full backup on database data, generate incremental backups comprising log files associated with modifications to the database data, and create a differential full backup copy of the database data using the full backup copy and changed blocks identified using the log files from the incremental backups.

Abstract: An illustrative data storage management system comprises “awareness logic” that executes on computing devices hosting storage management components such as storage manager, data agent, media agent, and/or other storage management applications. The illustrative awareness logic operates within each of these illustrative components, e.g., as a thread within processes of the storage management component, such as storage management core process, file identifier process, log monitoring process, etc. The awareness logic monitors the targeted process over time and triggers remedial action when criteria are met. Certain vital statistics of each process are collected periodically and analyzed by the illustrative awareness logic, such as CPU usage, memory usage, and handle counts. Criteria for corrective action include rising trends based on local minima data points for one or more vital statistics of the process. Other criteria include exceeding a threshold based on a logarithm function of the collected data points.

Abstract: Aspects of the present disclosure enable data protection operations including differential and incremental backups by performing changed-block tracking in network or cloud computing systems with architectures that do not natively support changed-block tracking or do not expose changed-block tracking functionality to an information management system. In certain aspects, an identity of changed blocks may be obtained by using a hypervisor configured to interface with the cloud computing architecture. The identified changed blocks may be used to generate a map of the changed blocks. The maps of the changed blocks can be used by a virtual server agent to extract the changed blocks from a copy of a virtual machine disk and backed up to perform a differential or incremental backup.

Abstract: An illustrative data storage management system comprises a management database that stores administrative preferences and system configurations, as well as results and/or statistics of completed secondary storage operations, i.e., information needed by the system to protect customers' data and to track and recover the protected data, including secondary copies such as backup copies, archive copies, etc. The disclosed data storage management system is configured to protect its own system data subject to a very aggressive (short) Recovery Point Objective (RPO), by using an innovative infrastructure that enables the system's storage manager to fail over to any number of other failover destination storage managers, each one comprising a destination management database. An illustrative database granularly tracks whether each and every transaction log file has been successfully applied to each and every destination management database to synchronize with the source management database.

Abstract: An illustrative “Live Synchronization” feature in a data storage management system can reduce the downtime that arises in failover situations. The illustrative Live Sync embodiment uses backup data to create and maintain a ready (or “warm”) virtualized computing platform comprising one or more virtual machines (“VMs”) that are configured and ready to be activated and take over data processing from another data processing platform operating in the production environment. The “warm” computing platform awaits activation as a failover solution for the production system(s) and can be co-located at the production data center, or configured at a remote or disaster recovery site, which in some embodiments is configured “in the cloud.” Both local and remote illustrative embodiments are discussed herein. An “incremental forever” approach can be combined with deduplication and synthetic full backups to speed up data transfer and update the disaster recovery sites.

Abstract: An illustrative live synchronization feature uses file system block-level backup copies, snapshot techniques, change tracking, and volume-level granularity to ensure the integrity of destination volumes. Two protection mechanisms guard the destination data and ensure consistency from one live sync restore to the next. First, an inter-job software snapshot captures the destination volume image after each restore. The snapshot is created at the very end of each live sync restore and is reverted at the beginning of the next live sync restore. A second and more granular protection mechanism uses intra-job block monitoring to detect, and later to reverse, changes that the snapshots cannot capture. This second mechanism acts as a mini-block-level restore nested inside another block-level restore. This dual approach ensures that each incremental live sync restore finds the destination volume with a guaranteed pristine image identical to where the preceding live sync restore left it.

Abstract: Certain embodiments disclosed herein reduce or eliminate a communication bottleneck at the storage manager by reducing communication with the storage manager while maintaining functionality of an information management system. In some implementations, a client obtains information for enabling a secondary storage job (e.g., a backup or restore) from a storage manager and stores the information (which may be referred to as job metadata) in a local cache. The client may then reuse the job metadata for multiple storage jobs reducing the frequency of communication with the storage manager. When a configuration of the information management system changes, or the availability of resources changes, the storage manager can push updates to the job metadata to the clients. Further, a client can periodically request updated job metadata from the storage manager ensuring that the client does not rely on out-of-date job metadata.

Abstract: A strongly consistent distributed data storage system comprises an enhanced metadata service that is capable of fully recovering all metadata that goes missing when a metadata-carrying disk, disks, and/or partition fail. An illustrative recovery service runs automatically or on demand to bring the metadata node back into full service. Advantages of the recovery service include guaranteed full recovery of all missing metadata, including metadata still residing in commit logs, without impacting strong consistency guarantees of the metadata. The recovery service is network-traffic efficient. In preferred embodiments, the recovery service avoids metadata service downtime at the metadata node, thereby reducing the impact of metadata disk failure on the availability of the system. The disclosed metadata recovery techniques are said to be “self-healing” as they do not need manual intervention and instead automatically detect failures and automatically recover from the failures in a non-disruptive manner.

Abstract: Systems described herein may dynamically add one or more proxy data protection agents to a cloud data storage system to process a data protection job. Upon completion of the job or at some other appropriate interval, the system can power down and decommission the proxy data protection agents and/or the virtual machines on which the data protection proxies reside according to a cleanup schedule (e.g., at hourly or minute intervals). In order to improve the allocation of computing resources, the system takes into account currently existing proxies or virtual machines when processing a backup request to determine the need for new proxies to service the backup request. In this manner the system can save costs and computing resources through efficient virtual machine deployment and retirement.

Abstract: Systems and processes disclosed herein perform an automatic remediation process. The automatic remediation process may be a log-based remediation process. Systems disclosed herein may obtain log files from an information management system and determine the occurrence of errors at the information management system based on error codes included in the logs. Further, the systems may access a knowledgebase to determine whether solutions for the errors have been previously generated. The solutions may include patches or hotfixes that can be applied to the information management system without removing user-access or stopping execution of the information management system. The systems may automatically update the information management system to address the errors. Alternatively, or in addition, the systems may alert a user, such as an administrator, of the existence of a solution to the error, and whether the solution may be applied without interrupting service or access to the information management system.

Abstract: Certain embodiments described herein relate to an improved virtual machine restoration system. In one embodiment, an information management system receives a request to perform a restore of a virtual machine using virtual machine data stored on a secondary storage device. In response, the information management system boots up the virtual machine after restoring only a portion of the virtual machine data that is needed to boot up the virtual machine, thereby reducing latencies associated with virtual machine boot-up. The information management system continues to retrieve additional portions of the virtual machine data from the secondary storage device as such portions are requested by the virtual machine, thereby reducing or minimizing unnecessary data transfer from the secondary storage device.

Abstract: Exemplary systems and methods for archiving data objects using secondary copies are disclosed. The system creates one or more secondary copies of primary data that contains multiple data objects. The system may maintain a first data structure that tracks the data objects for which the system has created secondary copies and the locations of the secondary copies. To archive data objects in the primary data, the system identifies data objects to be archived, verifies that previously-created secondary copies of the identified data objects exist, and replaces the identified data objects with stubs. The system may maintain a second data structure that both tracks the stubs and refers to the first data structure, thereby creating an association between the stubs and the locations of the secondary copies.

Abstract: According to certain aspects, a system may include a data agent configured to: process a database file residing on a primary storage device(s) to identify a subset of data in the database file for archiving, the database file generated by a database application; and extract the subset of the data from the database file and store the subset of the data in an archive file on the primary storage device(s) as a plurality of blocks having a common size; and at least one secondary storage controller computer configured to, as part of a secondary copy operation in which the archive file is copied to a secondary storage device(s): copy the plurality of blocks to the secondary storage devices to create a secondary copy of the archive file; and create a table that provides a mapping between the copied plurality of blocks and corresponding locations in the secondary storage device(s).

Abstract: Live mounting a virtual machine (VM) causes the VM to run off a backup copy or snapshot previously taken of a “live” production VM. The live-mounted VM is generally intended for temporary use such as to validate the integrity and contents of the backup copy for disaster recovery validation, or to access some contents of the backup copy from the live-mounted VM without restoring all backed up files. These uses contemplate that changes occurring during live mount are not preserved after the live-mounted VM expires or is taken down. Thus, live mounting a VM is not a restore operation and usually does not involve access to every block of data in the backup copy. However, live mounting provides live VM service in the cloud sooner than waiting for all of the backup copy/snapshot to be restored.

Abstract: Storage of data that no longer has a useful life is established by the data objects' user(s) and overcomes predetermined rules required by information management policies. An illustrative data agent may receive instructions from an illustrative storage manager to perform secondary copy operations for certain data objects. The instructions may instruct that expiry-marked data objects are to be treated based on parsing each data object's user-supplied expiry timeframe. The illustrative system (i) will delete expired data objects including expired secondary copies; (ii) will refrain from making secondary copies of expired data objects; and (iii) if an expiry-marked data object is not expired, the illustrative system will make secondary copies according to the instructions, but will track those expiry-marked secondary copies for future deletion after they expire, (iv) and will delete expired secondary copies even if the original expiry-marked data object has been deleted from the system prior to its expiration.

Abstract: An information management cell health monitoring system is provided herein that can monitor one or more information management systems, identify any performance issues that are occurring within an information management system, and automatically, or in response to a user input, transmit an instruction to the information management system to execute a workflow to resolve the performance issue(s). For example, the information management cell health monitoring system receives operational data, secondary copy policies, and/or similar data from an information management cells via a network. The information management cell health monitoring system analyzes the received information to identify any issues. If an issue is detected, the information management cell health monitoring system retrieves workflows and determines whether any of the workflows can be used to resolve the detected issue.

Abstract: Virtual machine (VM) proliferation may be reduced by determining the availability of existing VMs to perform a task. Tasks may be assigned to existing VMs instead of creating a new VM to perform the task. Furthermore, a coordinator may determine a grouping of VMs or VM hosts based on one or more factors associated with the VMs or the VM hosts, such as VM type or geographical location of the VM hosts. The coordinator may also assign one or more Virtual Server Agents (VSAs) to facilitate managing the group of VM hosts. In some embodiments, the coordinators may facilitate load balancing of VSAs during operation, such as during a backup operation, a restore operation, or any other operation between a primary storage system and a secondary storage system.

Abstract: Systems and methods for performing file-level restore operations for block-level data volumes are described. In some embodiments, the systems and methods restore data from a block-level data volume contained in secondary storage by receiving a request to restore one or more files from the block-level data volume, mounting a virtual disk to the block-level data volume, accessing one or more mount paths established by the virtual disk between the data agent and the block-level data volume, and browsing data from one or more files within the block-level data volume via the established one or more mount paths provided by the virtual disk.