Abstract: An illustrative file indexing approach enhances what was previously possible with hypervisor-free live browsing of virtual machine (VM) block-level backup copies. Capabilities are described for indexing files discovered in VM block-level backup copies, including indexing of directory structures and file content. The illustrative file indexing functionality activates a live-browse session to discover files present within VM block-level backup copies and indexes file names and directory structures as created by an original source VM, resulting in an illustrative file index. The illustrative file indexing functionality optionally indexes file contents within VM block-level backup copies, resulting in an illustrative content index. The file index and content index are retained in persistent data structure(s) stored apart from the VM block-level backup copies. The indexes are searchable without mounting or live-browsing the VM block-level backup copies.

Abstract: Certain embodiments described herein relate to an improved information management system that can perform provider-specific data protection methods for cloud-stored data. In one embodiment, the information management system accesses a pod specification that indicates information usable to execute a containerized application on behalf of a user, and determines the cloud provider system configured to provide one or more computing resources for execution the containerized application. Using a provider-specific interface that is specific to the determined cloud provider system, the information management system creates a snapshot of a cloud storage volume associated with the containerized application and accesses the data inside the snapshot. The accessed data is stored onto a secondary storage device, and the snapshot is removed from the cloud provider system, thereby providing an efficient backup solution for the data used for executing the containerized application on the container orchestrator system.

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 data storage management system incorporates image recognition and classification features. The illustrative system generates thumbnail images to represent images detected in secondary copies. Subsequent image recognition and classification operations are based on the thumbnail images without need to access the secondary copies from which the thumbnails were derived. The system indexes thumbnail images and respective relationships to each other and to the source secondary copies. Metadata from the source secondary copies is extracted and preserved with the thumbnails. Thumbnail images, metadata, and related index data (collectively “thumbnail data”) are stored locally in an illustrative content index server, or in an enhanced storage manager, thus improving performance without interfering with ongoing storage management operations. Features are disclosed for searching within the system and performing storage management operations based on image criteria. Access to/from other systems is also possible, e.g.

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: A method and system for communicating with IoT devices to gather information related to device failure or error(s) is disclosed. The system makes a copy of at least a portion of the device's non-volatile memory and/or receives IoT device data (e.g., sensor data and/or log files etc.) from an IoT device that recently failed. The system determines which log files and/or sensor data, for example, 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, for further analysis and diagnostics to troubleshoot the failure and send a fix or software update to the IoT device.

Abstract: Certain embodiments described herein relate to an improved block-level replication system. One or more components in an information management system may receive a request to perform a block-level replication between a source storage device and a destination storage device, and depending on the specific replication mode requested, (i) store block-level changes directly to the destination storage device or (ii) first to a recovery point store and then later to the destination storage device.

Abstract: A method and system for communicating with IoT devices connected to a vehicle to gather information related to device operation or performance is disclosed. The system makes a copy of at least a portion of the device's non-volatile memory and/or receives IoT device data (e.g., sensor data and/or log files etc.) from an IoT device that recently failed. The system determines which log files and/or sensor data, for example, the IoT device created before and/or after a failure. After gathering this information, the system stores the information, sends it to a storage destination for further analysis and diagnostics to troubleshoot the failure and send a fix or software update to the IoT device. The information can also be placed into secondary storage to comply with regulatory, insurance, or legal purposes.

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: 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 Fibre 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: A system according to certain aspects improves the process of performing snapshot replication operations (e.g., maintaining a mirror copy of primary data at a secondary location by generating snapshots of the primary data). The system can collect and maintain cumulative block-level changes to the primary data after each sub-interval of a plurality of sub-intervals between the snapshots. When a snapshot is generated, any changes to the primary data not reflected in the cumulative block-level changes are identified based on the snapshot and transmitted to the secondary location along with the cumulative block-level changes. By the time the snapshot is generated, some or all of the changes to the primary data associated with the given snapshot have already been included in the cumulative block-level changes, thereby reducing the time and computing resources spent to identify and collect the changes for transmission to the secondary location.

Abstract: A method and system for communicating with IoT devices connected to a vehicle to gather information related to device operation or performance is disclosed. The system makes a copy of at least a portion of the device's non-volatile memory and/or receives IoT device data (e.g., sensor data and/or log files etc.) from an IoT device that recently failed. The system determines which log files and/or sensor data, for example, the IoT device created before and/or after a failure. After gathering this information, the system stores the information, sends it to a storage destination for further analysis and diagnostics to troubleshoot the failure and send a fix or software update to the IoT device. The information can also be placed into secondary storage to comply with regulatory, insurance, or legal purposes.

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 Fibre 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 as-needed, 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: 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: 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: 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: Certain embodiments described herein relate to an improved information management system that can perform platform-agnostic containerized application data protection. In one embodiment, the information management system receives a user's credentials to a container orchestrator along with an indication of whether or not to deploy a backup pod. Using the user credentials, the information management system accesses the container orchestrator, and if the user has requested deployment of a backup pod on the user's cluster, the information management system may do so using a backup pod specification and allow the backup pod to perform data protection operations, using a platform-agnostic interface (e.g., container storage interface), for application data accessible by the user applications on the user's pod on the user's cluster. Alternatively, if the user has not requested deployment of a backup pod, the information management system may perform data protection operations using provider-specific interface.

Abstract: Certain embodiments described herein relate to an improved information management system that can perform provider-specific data protection methods for cloud-stored data. In one embodiment, the information management system accesses a pod specification that indicates information usable to execute a containerized application on behalf of a user, and determines the cloud provider system configured to provide one or more computing resources for execution the containerized application. Using a provider-specific interface that is specific to the determined cloud provider system, the information management system creates a snapshot of a cloud storage volume associated with the containerized application and accesses the data inside the snapshot. The accessed data is stored onto a secondary storage device, and the snapshot is removed from the cloud provider system, thereby providing an efficient backup solution for the data used for executing the containerized application on the container orchestrator system.

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