Abstract: Systems and methods disclosed herein improve on current technology for block-level data replication to cloud computing environments. A new system architecture deploys one or more replication tail proxies in a cloud computing environment, locally (at the cloud) tracks replicated data and determines which replicated data meet criteria for reconstructing a desired point-in-time in the cloud, and persists data blocks received at the replication tail proxy until they are processed as recovery points. The disclosed approach presents resiliency and performance advantages. First, the resiliency of block-level data replication to cloud is improved by deploying the replication tail proxy in the destination cloud. Second, a Recovery Time Objective (RTO) is reduced by enabling faster cloud deployment of virtual machines for disaster recovery, failover, and/or test purposes based on the replicated data.

Abstract: Systems and methods disclosed herein improve on current technology for block-level data replication to cloud computing environments. A new system architecture deploys one or more replication tail proxies in a cloud computing environment, locally (at the cloud) tracks replicated data and determines which replicated data meet criteria for reconstructing a desired point-in-time in the cloud, and persists data blocks received at the replication tail proxy until they are processed as recovery points. The disclosed approach presents resiliency and performance advantages. First, the resiliency of block-level data replication to cloud is improved by deploying the replication tail proxy in the destination cloud. Second, a Recovery Time Objective (RTO) is reduced by enabling faster cloud deployment of virtual machines for disaster recovery, failover, and/or test purposes based on the replicated data.

Abstract: Systems and methods disclosed herein improve on current technology for block-level data replication to cloud computing environments. A new system architecture deploys one or more replication tail proxies in a cloud computing environment, locally (at the cloud) tracks replicated data and determines which replicated data meet criteria for reconstructing a desired point-in-time in the cloud, and persists data blocks received at the replication tail proxy until they are processed as recovery points. The disclosed approach presents resiliency and performance advantages. First, the resiliency of block-level data replication to cloud is improved by deploying the replication tail proxy in the destination cloud. Second, a Recovery Time Objective (RTO) is reduced by enabling faster cloud deployment of virtual machines for disaster recovery, failover, and/or test purposes based on the replicated data.

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

Abstract: An information management system is described herein that performs either a pre-processing or a post-processing operation to increase browse and restore speeds when a user attempts to browse for and restore files from a secondary copy of a data volume. For example, the information management system can implement the pre-processing operation by parsing a master file table (MFT) when a secondary copy operation is initiated on the data volume. The information management system can implement the post-processing operation by parsing the MFT after a secondary copy operation is complete. The parsing can occur to identify records of the MFT that include information useful for enabling a user to browse a secondary copy of the data volume. The information management system can then store the secondary copy of these records for use later in constructing an interface for browsing a secondary copy of the data volume.

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: An illustrative ISCSI server computing device provides user computing devices with “private writable snapshots” of a desired volume of data and/or further provides “private writable backup copies.” The ISCSI service is provided without invoking snapshot limits imposed by storage arrays and further without specialized backup software and pseudo-disk drivers installed on the user computing devices. A user can browse as well as edit personal versions of any number and/or versions of block-level backup copies—the “private writable backup copies.” Likewise, a user can browse and edit personal versions of any number of snapshots of one or more versions of one or more desired data volumes—the “private writable snapshots.” A user can have any number of co-existing private writable snapshots and private writable backup copies. Sparse files, extent-files, software snapshots, and/or media agents co-residing on the ISCSI server are used in the illustrative embodiments.

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.

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

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: To overcome problems encountered with instability and/or risk of data corruption arising from using software snapshots, the present approach relies instead on data replication and sparse files to provide personal or private versions of a data storage volume (“private writable snapshots”). The disclosed technological solution avoids the use of software snapshot technologies altogether. Instead, a family of inter-related and cascading sparse files are maintained as data sources of replicated data volumes. In the event that the server which controls these sparse files crashes, the sparse files themselves are persistent and remain uncorrupted in a data storage platform, such as a storage array. An illustrative Internet Small Computer Systems Interface server (“ISCSI server”) provides user computing devices with private writable snapshots of a desired volume of data using the illustrative sparse files.

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.

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

Abstract: An information management system is described herein that performs either a pre-processing or a post-processing operation to increase browse and restore speeds when a user attempts to browse for and restore files from a secondary copy of a data volume. For example, the information management system can implement the pre-processing operation by parsing a master file table (MFT) when a secondary copy operation is initiated on the data volume. The information management system can implement the post-processing operation by parsing the MFT after a secondary copy operation is complete. The parsing can occur to identify records of the MFT that include information useful for enabling a user to browse a secondary copy of the data volume. The information management system can then store the secondary copy of these records for use later in constructing an interface for browsing a secondary copy of the data volume.

Abstract: An illustrative ISCSI server computing device provides user computing devices with “private writable snapshots” of a desired volume of data and/or further provides “private writable backup copies.” The ISCSI service is provided without invoking snapshot limits imposed by storage arrays and further without specialized backup software and pseudo-disk drivers installed on the user computing devices. A user can browse as well as edit personal versions of any number and/or versions of block-level backup copies—the “private writable backup copies.” Likewise, a user can browse and edit personal versions of any number of snapshots of one or more versions of one or more desired data volumes—the “private writable snapshots.” A user can have any number of co-existing private writable snapshots and private writable backup copies. Sparse files, extent-files, software snapshots, and/or media agents co-residing on the ISCSI server are used in the illustrative embodiments.

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.