Abstract: A system according to certain aspects improves the process of restoring database objects and converting those objects into another database file format. According to certain aspects, a database file is backed up in a block-level fashion. Instead of restoring the entire backup file, which can consume a large amount of time and computing resources, the information management system may restore a particular database object from a backup database file that is stored as multiple blocks or other granular units. Then, the information management system can extract the desired data from the restored block(s). By using block-level mapping and storage techniques described herein, the system can restore a database object in a backup database file without restoring the entire backup database file, thereby speeding up restore operations and reducing consumption of storage and processing resources.

Abstract: This application discloses a system for presenting data to a user based on requests to move data from primary storage to secondary storage. The system receives a request to move data that satisfies at least one criterion, from primary to secondary data storage. The system then identifies an initial database query from the request, and further builds a nested database query from the initial database query according to a database schema. Next, the system estimates a size of a result of executing the nested database query. Finally, the system provides for display to the user the estimated size.

Abstract: An illustrative pseudo-file-system driver uses deduplication functionality and resources in a storage management system to provide an application and/or a virtual machine with access to a locally-stored file system. From the perspective of the application/virtual machine, the file system appears to be of virtually unlimited capacity. The pseudo-file-system driver instantiates the file system in primary storage, e.g., configured on a local disk. The application/virtual machine requires no configured settings or limits for the file system's storage capacity, and may thus treat the file system as “infinite.” The pseudo-file-system driver intercepts write requests and may use the deduplication infrastructure in the storage management system to offload excess data from local primary storage to deduplicated secondary storage, based on a deduplication database.

Abstract: An illustrative “Live Synchronization” feature creates and maintains a ready standby “synchronized application” that is available to take over as a failover solution for a “primary” application that operates in a production environment, but will do so on a different computing platform (e.g., physical server, virtual machine, container, etc.), and possibly on a differed kind of computing platform than, the primary. The illustrative system has specialized features and components for discovering and singling out each primary application and identifying and locating its disk image, e.g., VMDK file. The application is Live Synched to the standby/failover application without reference to whether and how other co-resident applications might be treated. The standby/failover destination supporting the synchronized application may be located anywhere, whether in the same data center as the primary or geographically remote or in a private or public cloud setting.

Abstract: Systems and methods are disclosed for speedily upgrading (e.g., via service packs) components of a storage management system, such as media agents and data agents, which may number in the thousands. The disclosed methods and systems provide a lightweight and flexible approach. Executable files such as service packs are deployed to a network-shared file system and are served on demand to each targeted host computing device to launch a data agent and/or media agent component. New service packs (e.g., upgrades) are installed on another shared drive and the connection thereto is refreshed by each targeted storage management component to begin executing the new version on demand. The resultant overall upgrade process across the storage management system may be substantially shortened, and the network burden greatly reduced.

Abstract: The illustrative systems and methods use a special-purpose volume-replicating server(s) to offload client computing devices operating in a production environment. The production environment may remain relatively undisturbed while production data is replicated to a geographically distinct destination. Replication is based in part on hardware-based snapshots generated by a storage array that houses production data. The illustrative volume-replicating server efficiently moves data from snapshots on a source storage array to a destination storage array by transferring only changed blocks for each successive snapshot, i.e., transferring incremental block-level changes. Periodic restore jobs may be executed by destination clients to keep current with their corresponding source production clients. Accordingly, after the source data center goes offline, production data may be speedily restored at the destination data center after experiencing only minimal downtime of production resources.

Abstract: Software, firmware, and systems are described herein that migrate functionality of a source physical computing device to a destination virtual machine. A non-production copy of data associated with a source physical computing device is created. A configuration of the source physical computing device is determined. A configuration for a destination virtual machine is determined based at least in part on the configuration of the source physical computing device. The destination virtual machine is provided access to data and metadata associated with the source physical computing device using the non-production copy of data associated with the source physical computing device.

Abstract: The data storage system according to certain aspects can implement table level database restore. Table level database restore may refer to restoring a database table and its related data without restoring the entire database. The data storage system may use table metadata index to implement table level restore. A table metadata index may be created for each table, e.g., during a backup of the database. The table metadata index for a table can include any type of information for restoring the table and its related data. Some examples of the type of information included in the table metadata index include the following: container for the table, table backup location, system data, table index, table relationships, etc. Table metadata index can make the restoring of tables fast and efficient by packaging information that can be used to restore a table and its related data in an easily accessible manner.

Abstract: A data storage system can scan one or more information stores and analyze the metadata of files stored in the one or more information stores to identify secondary copy operations (e.g., archiving) that can be performed on the files. The storage system can also identify storage usage information of each file during the scan and use that information to generate reports regarding the usage of the storage.

Abstract: Techniques for enabling user search of content stored in a file archive include providing a search interface comprising a search rules portion and an action rules portion, receiving a file archive search criterion comprising at least one search rule, and searching the file archive using the search criterion. The techniques also include generating a set of files filtered using the search criterion and performing an action specified in the action rules portion on a file included in the set of files.

Abstract: An illustrative “Live Synchronization” feature creates and maintains a ready standby “synchronized application” that is available to take over as a failover solution for a “primary” application that operates in a production environment, but will do so on a different computing platform (e.g., physical server, virtual machine, container, etc.), and possibly on a differed kind of computing platform than, the primary. The illustrative system has specialized features and components for discovering and singling out each primary application and identifying and locating its disk image, e.g., VMDK file. The application is Live Synched to the standby/failover application without reference to whether and how other co-resident applications might be treated. The standby/failover destination supporting the synchronized application may be located anywhere, whether in the same data center as the primary or geographically remote or in a private or public cloud setting.

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: Software, firmware, and systems are described herein that migrate functionality of a source physical computing device to a destination virtual machine. A non-production copy of data associated with a source physical computing device is created. A configuration of the source physical computing device is determined. A configuration for a destination virtual machine is determined based at least in part on the configuration of the source physical computing device. The destination virtual machine is provided access to data and metadata associated with the source physical computing device using the non-production copy of data associated with the source physical computing device.

Abstract: According to certain aspects, a system may include a computing device configured to: intercept a request from a database application to read a portion of a database file, where a secondary copy of the database file resides on a secondary storage device(s) and is organized as a plurality of first blocks, wherein the request includes a database file offset(s) corresponding to the requested portion; and map the database file offset(s) to a subset of the first blocks that correspond to requested database object(s). The system may include a secondary storage controller computer(s) configured to: access a table that maps the plurality of first blocks to storage locations on the secondary storage device(s); using the table, locate and retrieve the subset of the first blocks on the secondary storage device(s); and forward the retrieved first blocks for storage in a primary storage device(s).

Abstract: The data storage system according to certain aspects can implement table level database restore. Table level database restore may refer to restoring a database table and its related data without restoring the entire database. The data storage system may use table metadata index to implement table level restore. A table metadata index may be created for each table, e.g., during a backup of the database. The table metadata index for a table can include any type of information for restoring the table and its related data. Some examples of the type of information included in the table metadata index include the following: container for the table, table backup location, system data, table index, table relationships, etc. Table metadata index can make the restoring of tables fast and efficient by packaging information that can be used to restore a table and its related data in an easily accessible manner.

Abstract: According to certain aspects, a method of creating customized bootable images for client computing devices in an information management system can include: creating a backup copy of each of a plurality of client computing devices, including a first client computing device; subsequent to receiving a request to restore the first client computing device to the state at a first time, creating a customized bootable image that is configured to directly restore the first client computing device to the state at the first time, wherein the customized bootable image includes system state specific to the first client computing device at the first time and one or more drivers associated with hardware existing at time of restore on a computing device to be rebooted; and rebooting the computing device to the state of the first client computing device at the first time from the customized bootable image.

Abstract: The data storage system according to certain aspects can implement table level database restore. Table level database restore may refer to restoring a database table and its related data without restoring the entire database. The data storage system may use table metadata index to implement table level restore. A table metadata index may be created for each table, e.g., during a backup of the database. The table metadata index for a table can include any type of information for restoring the table and its related data. Some examples of the type of information included in the table metadata index include the following: container for the table, table backup location, system data, table index, table relationships, etc. Table metadata index can make the restoring of tables fast and efficient by packaging information that can be used to restore a table and its related data in an easily accessible manner.

Abstract: Systems and methods are disclosed for speedily upgrading (e.g., via service packs) components of a storage management system, such as media agents and data agents, which may number in the thousands. The disclosed methods and systems provide a lightweight and flexible approach. Executable files such as service packs are deployed to a network-shared file system and are served on demand to each targeted host computing device to launch a data agent and/or media agent component. New service packs (e.g., upgrades) are installed on another shared drive and the connection thereto is refreshed by each targeted storage management component to begin executing the new version on demand. The resultant overall upgrade process across the storage management system may be substantially shortened, and the network burden greatly reduced.

Abstract: This application discloses a system for presenting data to a user based on requests to move data from primary storage to secondary storage. The system receives a request to move data that satisfies at least one criterion, from primary to secondary data storage. The system then identifies an initial database query from the request, and further builds a nested database query from the initial database query according to a database schema. Next, the system estimates a size of a result of executing the nested database query. Finally, the system provides for display to the user the estimated size.

Abstract: Techniques for enabling user search of content stored in a file archive include providing a search interface comprising a search rules portion and an action rules portion, receiving a file archive search criterion comprising at least one search rule, and searching the file archive using the search criterion. The techniques also include generating a set of files filtered using the search criterion and performing an action specified in the action rules portion on a file included in the set of files.