Abstract: Systems and methods can implement one or more intelligent caching algorithms that reduce wear on the SSD and/or to improve caching performance. Such algorithms can improve storage utilization and I/O efficiency by taking into account the write-wearing limitations of the SSD. Accordingly, the systems and methods can cache to the SSD while avoiding writing too frequently to the SSD to increase or attempt to increase the lifespan of the SSD. The systems and methods may, for instance, write data to the SSD once that data has been read from the hard disk or memory multiple times to avoid or attempt to avoid writing data that has been read only once. The systems and methods may also write large chunks of data to the SSD at once instead of a single unit of data at a time. Further, the systems and methods can write to the SSD in a circular fashion.

Abstract: Hypervisor-independent block-level live browse is used for directly accessing backed up virtual machine (VM) data. Hypervisor-free file-level recovery (block-level pseudo-mount) from backed up VMs also is disclosed. Backed up virtual machine (“VM”) data can be browsed without needing or using a hypervisor. Individual backed up VM files can be requested and restored to anywhere without a hypervisor and without the need to restore the rest of the backed up virtual disk. Hypervisor-agnostic VM backups can be browsed and recovered without a hypervisor and from anywhere, and individual backed up VM files can be restored to anywhere, e.g., to a different VM platform, to a non-VM environment, without restoring an entire virtual disk, and without a recovery data agent at the destination.

Abstract: The present enhancement leaves production systems undisturbed while a remote application (“testbed application”) executes elsewhere (“testbed host”). An intermediary computing device hosts an enhanced pseudo-disk driver, pseudo-disks, and an enhanced media agent. The enhanced pseudo-disk driver creates the pseudo-disks, each one representing an associated point-in-time backup image residing in secondary storage. A network, e.g., an Internet Protocol (IP) network or a Fiber Channel (FC) Storage Area Network (SAN), connects the intermediary device with the testbed host, and the enhanced media agent exposes pseudo-disks over the network using iSCSI or FC protocol, respectively. The testbed application uses an exposed pseudo-disk as its recovery data source, such that pseudo-disk resources provide data on an as-needed basis sufficient for the testbed application to operate, yet (a) without restoring the entire associated backup image from secondary storage and (b) without impacting the production environment.

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: 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: Hypervisor-independent block-level live browse is used for directly accessing backed up virtual machine (VM) data. Hypervisor-free file-level recovery (block-level pseudo-mount) from backed up VMs also is disclosed. Backed up virtual machine (“VM”) data can be browsed without needing or using a hypervisor. Individual backed up VM files can be requested and restored to anywhere without a hypervisor and without the need to restore the rest of the backed up virtual disk. Hypervisor-agnostic VM backups can be browsed and recovered without a hypervisor and from anywhere, and individual backed up VM files can be restored to anywhere, e.g., to a different VM platform, to a non-VM environment, without restoring an entire virtual disk, and without a recovery data agent at the destination.

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: A data storage system receives a user instruction through a user interface to restore a specific virtual machine file from a block-level backup. The system accesses a file index which is created during the block-level backup by accessing the file allocation table of the underlying host system and associating the blocks with the file location information of the virtual machine files stored in the file allocation table. The system further creates a file level table based at least in part on the virtual machine file information stored in the file index, displays a listing of the virtual machine files from the file level table, and receives a user selected virtual machine file to restore.

Abstract: Systems and methods can implement one or more intelligent caching algorithms that reduce wear on the SSD and/or to improve caching performance. Such algorithms can improve storage utilization and I/O efficiency by taking into account the write-wearing limitations of the SSD. Accordingly, the systems and methods can cache to the SSD while avoiding writing too frequently to the SSD to increase or attempt to increase the lifespan of the SSD. The systems and methods may, for instance, write data to the SSD once that data has been read from the hard disk or memory multiple times to avoid or attempt to avoid writing data that has been read only once. The systems and methods may also write large chunks of data to the SSD at once instead of a single unit of data at a time. Further, the systems and methods can write to the SSD in a circular fashion.

Abstract: A data storage system protects virtual machines using block-level backup operations and restores the data at a file level. The system accesses the virtual machine file information from the file allocation table of the host system underlying the virtualization layer. A file index associates this virtual machine file information with the related protected blocks in a secondary storage device during the block-level backup. Using the file index, the system can identify the specific blocks in the secondary storage device associated with a selected restore file. As a result, file level granularity for restore operations is possible for virtual machine data protected by block-level backup operations without restoring more than the selected file blocks from the block-level backup data.

Abstract: Container images may be generated from a backup system that includes a backup of one or more applications from a computing system of an entity. During a backup process, an application can be identified and its storage location in a secondary storage can be tracked or saved in a backup index. Configuration information and data or files created by user interaction with the application can be backed up and the location of the backed up data or files may be stored in the backup index along with the location of the configuration information. Using the backup index, a container image can be created that includes a selected application, its configuration information, and data, if any, created by the application. The container image can be generated from the backup stored in the secondary storage.

Abstract: Container images may be generated from a backup system that includes a backup of one or more applications from a computing system of an entity. During a backup process, an application can be identified and its storage location in a secondary storage can be tracked or saved in a backup index. Configuration information and data or files created by user interaction with the application can be backed up and the location of the backed up data or files may be stored in the backup index along with the location of the configuration information. Using the backup index, a container image can be created that includes a selected application, its configuration information, and data, if any, created by the application. The container image can be generated from the backup stored in the secondary storage.

Abstract: A method and system for communicating with IoT devices to gather information related to device failure or error(s) is disclosed. The system receives log files from an IoT device (e.g., a smart refrigerator) that recently failed. The system determines which log files the IoT device created before and/or after a failure. After gathering this information, the system stores the information in a database, sends it to the IoT device manufacturer, or sends it to a cloud provider. The system can also send the failure-related information to the IoT device-related entities (e.g., IoT device manufacturers), and the entity uses this information to troubleshoot the failure and send a fix or software update to the IoT device.

Abstract: Systems and methods are provided which perform a file level restore by utilizing existing operating system components (e.g., file system drivers) that are natively installed on the target computing device. These components can be used to mount and/or interpret a secondary copy of the file system. For instance, the system can instantiate an interface object (e.g., a device node such as a pseudo device, device file or special file) on the target client which includes file system metadata corresponding to the backed up version of the file system. The interface provides a mechanism for the operating system to mount the secondary copy and perform file level access on the secondary copy, e.g., to restore one or more selected files.

Abstract: A data storage system includes a generic snapshot interface, allowing for integration with a wide variety of snapshot-capable storage devices. The generic interface can be a programming interface (e.g., an application programming interface [API]). Using the snapshot interface, storage device vendors can integrate their particular snapshot technology with the data storage system. For instance, the data storage system can access a shared library of functions (e.g., a dynamically linked library [DLL]) provided by the vendor (or another by appropriate entity) and that complies with the specifications of the common programming interface. And by invoking the appropriate functions in the library, the data storage system implements the snapshot operation on the storage device.

Abstract: Recovery points can be used for replicating a virtual machine and reverting the virtual machine to a different state. A filter driver can monitor and capture input/output commands between a virtual machine and a virtual machine disk. The captured input/output commands can be used to create a recovery point. The recovery point can be associated with a bitmap that may be used to identify data blocks that have been modified between two versions of the virtual machine. Using this bitmap, a virtual machine may be reverted or restored to a different state by replacing modified data blocks and without replacing the entire virtual machine disk.

Abstract: Recovery points can be used for replicating a virtual machine and reverting the virtual machine to a different state. A filter driver can monitor and capture input/output commands between a virtual machine and a virtual machine disk. The captured input/output commands can be used to create a recovery point. The recovery point can be associated with a bitmap that may be used to identify data blocks that have been modified between two versions of the virtual machine. Using this bitmap, a virtual machine may be reverted or restored to a different state by replacing modified data blocks and without replacing the entire virtual machine disk.

Abstract: Recovery points can be used for replicating a virtual machine and reverting the virtual machine to a different state. A filter driver can monitor and capture input/output commands between a virtual machine and a virtual machine disk. The captured input/output commands can be used to create a recovery point. The recovery point can be associated with a bitmap that may be used to identify data blocks that have been modified between two versions of the virtual machine. Using this bitmap, a virtual machine may be reverted or restored to a different state by replacing modified data blocks and without replacing the entire virtual machine disk.

Abstract: Recovery points can be used for replicating a virtual machine and reverting the virtual machine to a different state. A filter driver can monitor and capture input/output commands between a virtual machine and a virtual machine disk. The captured input/output commands can be used to create a recovery point. The recovery point can be associated with a bitmap that may be used to identify data blocks that have been modified between two versions of the virtual machine. Using this bitmap, a virtual machine may be reverted or restored to a different state by replacing modified data blocks and without replacing the entire virtual machine disk.

Abstract: Recovery points can be used for replicating a virtual machine and reverting the virtual machine to a different state. A filter driver can monitor and capture input/output commands between a virtual machine and a virtual machine disk. The captured input/output commands can be used to create a recovery point. The recovery point can be associated with a bitmap that may be used to identify data blocks that have been modified between two versions of the virtual machine. Using this bitmap, a virtual machine may be reverted or restored to a different state by replacing modified data blocks and without replacing the entire virtual machine disk.