Abstract: Illustrative systems and methods enable a virtual machine (“VM”) to be powered up at any hypervisor regardless of hypervisor type, based on live-mounting VM data that was originally backed up into a hypervisor-independent format by a block-level backup operation. Afterwards, the backed up VM executes anywhere anytime without needing to find a hypervisor that is the same as or compatible with the original source VM's hypervisor. The backed up VM payload data is rendered portable to any virtualized platform. Thus, a VM can be powered up at one or more test stations, data center or cloud recovery environments, and/or backup appliances, without the prior-art limitations of finding a same/compatible hypervisor for accessing and using backed up VM data. An illustrative media agent maintains cache storage that acts as a way station for data blocks retrieved from an original backup copy, and stores data blocks written by the live-mounted VM.

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: Software, firmware, and systems are described herein that migrate functionality of a source physical computing device to a destination physical computing device. 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 physical computing device is determined based at least in part on the configuration of the source physical computing device. The destination physical computing device 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: A method and system for communicating with IoT devices 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. The system determines which log files and/or sensor data, for example, the IoT device created. After gathering this information, the system stores the information, or may send it to a storage destination for further analysis. The information may also be placed into secondary storage to comply with regulatory, insurance, or legal purposes.

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: 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: 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: Illustrative embodiments represent a dynamic on-demand approach to configuring destination storage for bare metal restore (BMR) operations without operator intervention, including destination storage that is smaller than source storage devices. The illustrative operations rely on system state information collected concurrently with or shortly after source data is backed up, thereby capturing current actual storage metrics for the source data. The illustrative embodiments further rely on enhanced data agent components to collect and restore system state information as well as to restore backup data, thereby streamlining the configurations needed for the BMR operation to proceed. Additional business logic matches source mount points with suitable smaller destination storage resources and ensures that the BMR operation successfully completes with diverse and/or smaller storage destinations.

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: 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: Illustrative embodiments represent a dynamic on-demand approach to configuring destination storage for bare metal restore (BMR) operations without operator intervention, including destination storage that is smaller than source storage devices. The illustrative operations rely on system state information collected concurrently with or shortly after source data is backed up, thereby capturing current actual storage metrics for the source data. The illustrative embodiments further rely on enhanced data agent components to collect and restore system state information as well as to restore backup data, thereby streamlining the configurations needed for the BMR operation to proceed. Additional business logic matches source mount points with suitable smaller destination storage resources and ensures that the BMR operation successfully completes with diverse and/or smaller storage destinations.

Abstract: A “backup services container” comprises “backup toolkits,” which include scripts for accessing containerized applications plus enabling utilities/environments for executing the scripts. The backup services container is added to Kubernetes pods comprising containerized applications without changing other pod containers. For maximum value and advantage, the backup services container is “over-equipped” with toolkits. The backup services container selects and applies a suitable backup toolkit to a containerized application to ready it for a pending backup. Interoperability with a proprietary data storage management system provides features that are not possible with third-party backup systems. Some embodiments include one or more components of the proprietary data storage management within the illustrative backup services container. Some embodiments include one or more components of the proprietary data storage management system in a backup services pod configured in a Kubernetes node.

Abstract: Data protection resources are automatically scaled to the needs of data source(s) in an application orchestrator computing environment, such as a cluster in a Kubernetes deployment. The approach is adaptable to data sources in production clusters or application suites that are not application orchestrator deployments, such as a cloud-based database-as-a-service (DBaaS). A data storage management system protects cluster-based data with an elastic number of data protection resources (e.g., data agents, media agents), which are deployed on demand. The number of data protection resources deployed for a particular job are appropriate to the workload(s) at present and depend on a variety of scaling factors. In some embodiments, data protection resources are deployed within the same cluster as the data sources.

Abstract: A “backup services container” comprises “backup toolkits,” which include scripts for accessing containerized applications plus enabling utilities/environments for executing the scripts. The backup services container is added to Kubernetes pods comprising containerized applications without changing other pod containers. For maximum value and advantage, the backup services container is “over-equipped” with toolkits. The backup services container selects and applies a suitable backup toolkit to a containerized application to ready it for a pending backup. Interoperability with a proprietary data storage management system provides features that are not possible with third-party backup systems. Some embodiments include one or more components of the proprietary data storage management within the illustrative backup services container. Some embodiments include one or more components of the proprietary data storage management system in a backup services pod configured in a Kubernetes node.

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: Live recovery generates a new “recovery VM” that operates as an ongoing “live” production platform. A previously created non-cloud-native backup copy is the data source for the recovery VM. Live recovery restores data blocks from the backup copy on backup media directly to cloud-based virtual disk(s) assigned to the recovery VM. As a result, the cloud-based recovery VM can become fully operational in the cloud computing environment on a going-forward basis. The advantage of live recovery over a traditional restore is that live recovery provides a cloud-based VM that begins operating well before the backup copy is fully restored. This is accomplished by temporarily mounting a “temp-mounted VM” in the cloud while the backup copy is methodically restored in the background. VM reads and writes begin issuing from the temp-mounted VM and writes are retained on completion. Downtime is minimized when switching from the temp-mounted VM to the recovery VM.

Abstract: Illustrative systems and methods enable a virtual machine (“VM”) to be powered up at any hypervisor regardless of hypervisor type, based on live-mounting VM data that was originally backed up into a hypervisor-independent format by a block-level backup operation. Afterwards, the backed up VM executes anywhere anytime without needing to find a hypervisor that is the same as or compatible with the original source VM's hypervisor. The backed up VM payload data is rendered portable to any virtualized platform. Thus, a VM can be powered up at one or more test stations, data center or cloud recovery environments, and/or backup appliances, without the prior-art limitations of finding a same/compatible hypervisor for accessing and using backed up VM data. An illustrative media agent maintains cache storage that acts as a way station for data blocks retrieved from an original backup copy, and stores data blocks written by the live-mounted VM.

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