Emc IP Holding Company LLC

Emc Corporation

Neelabh Mam

Kiran Kumar Madiraju Varadaraju

Vladimir Mandic

Ravi Shankar

A system for image recovery comprises an input interface and a processor. The input interface is configured to receive a block backup volume that can be mounted. The processor is configured to determine a merged chain map by consolidating one or more incremental chain maps and to store an image using the merged chain map and a volume map.

Image recovery from volume image files

Techniques to back up data are disclosed. In various embodiments, a shadow copy of a source volume is created. An excluded file is deleted from the shadow copy. One or more blocks modified in the shadow copy in connection with deleting the excluded file from the shadow copy are tracked.

Excluding files in a block based backup

Approaches to expose a remotely located file on top of a virtual volume, at the volume level. The need to backup individual files as opposed to backing up the entire container volume in sparse mode had become apparent. Creating a novel method of exposing individual backed up files at the volume level avoids the associated reboot issues, performance issues and the need to operate at the file system level. The backup storage device can be any arbitrary device, such as a dedupe storage, NAS device, CIFS share, FTP server, or any other type of storage device.

Method to expose files on top of a virtual volume

Techniques to back up data are disclosed. In various embodiments, a shadow copy of a source volume is created. An excluded file is deleted from the shadow copy. One or more blocks modified in the shadow copy in connection with deleting the excluded file from the shadow copy are tracked. An incremental backup is performed, the incremental backup includes determining one or more blocks to be backed up in connection with the incremental backup based at least in part on at least one of the tracked one or more blocks modified in the shadow copy and a merged bitmap corresponding to a merger of a first bitmap associated with the shadow copy and a second bitmap associated with the source volume.

A system for incremental backup comprises a storage device and a processor. The processor is configured to: 1) start Event Tracing for Windows tracking, to track changed block information in one or more maps, where each of the one or more maps tracks writes indicated via a node; 2) receive request for an incremental backup of a volume of one or more volumes, wherein the one or more maps track changed blocks from writes to the volume; 3) halt writes to the volume and queue writes to the volume after halting; 4) freeze the one or more maps of changed blocks; change Event Tracing for Windows tracking, wherein the change block info is tracked to a new set of maps; 5) determine changed blocks using the one or more maps; 6) write changed blocks to a backup volume; and 7) release writes to the volume.

Block based incremental backup from user mode

A system for incremental backup comprises a storage device and a processor. The processor is configured to: 1) start tracking, wherein a file changed block info is tracked in map(s), wherein each of the map(s) tracks writes indicated via a node of a set of nodes; 2) receive request for an incremental backup of a volume of one or more volumes, wherein the map(s) track changed blocks from writes to the volume; 3) halt writes to the volume and queue writes to the volume after halting; 4) freeze the map(s) of changed blocks; 5) change tracking, wherein the change block info is tracked to a new set of maps; 6) determine changed blocks using the map(s); 7) write changed blocks to a backup volume; and 8) release writes to volume.

File based incremental block backup from user mode

A source volume is restored to the time of a selected incremental backup volume without writing over all of the data blocks in the source volume. If the source volume has valid data blocks and there are valid records of the changes to these valid data blocks and the valid records are consistent with the state of the source volume and indicate that certain valid data blocks did not change since the selected incremental backup, then the restoration does not write over the valid data blocks that did not change since the selected incremental backup. Otherwise, data blocks are recovered from the selected incremental backup and one or more backups prior to the selected incremental backup. For example, data blocks are recovered by scanning incremental backups in reverse chronological order to find the most recent version of the block in these backups.

Block-level incremental recovery of a storage volume

A block-level backup of a selected file on a source volume is done in an efficient manner by taking a snapshot copy of the source volume, and creating, mounting, and formatting a dynamically-extended backup volume, creating a sparse backup file on the backup volume, and then consolidating extents of the selected file while copying the extents at the block level from the snapshot copy of the source volume to the backup file on the backup volume. For an incremental block backup, only extents of changed blocks of the selected file are copied, and the changed blocks are identified by a modified block map of a previous snapshot copy of the source volume.

Block-level backup of selected files

Approaches to enable a block level backup image to be mounted by the operating system even in cases where the operating system does not have native support for the interfaces to access the backup image. The mounting of the backup image exposes the file system on the backup image and allows the user to perform granular file level recovery (FLR) when restoring data from the backup image. The mounting of the image and enabling data to be read from the image is performed by loading a kernel mode driver and a user mode data feeder application onto the computing device. These two components interact with one another to enable input/output (I/O) operations to be performed on the backup image.

Mounting block level backup images

Approaches are described for tracking write operations in an operating system environment which can be used to perform incremental backups of data. In particular, the approaches described herein enable a driver to begin tracking write operations being performed on a volume device (or snapshot of a volume) without having to reboot the system and without causing interruption to operations being performed on the volume. The tracking is enabled by applying a patch to a driver provided by the operating system to replace an original write handler of the driver with an alternate write handler. This alternate handler is used to track the sequence of write operations performed on a snapshot of the volume device. An active bitmap is maintained for recording changed blocks resulting from the write operations. Tins active bitmap can subsequently be used to perform an incremental backup of the volume device based on the snapshot.

Tracking write operations for incremental backups of data

A system for incremental backup comprises a storage device and a processor. The processor is configured to: 1) start fileIO ETW tracking, wherein a file changed block info is tracked in map(s), wherein each of the map(s) tracks writes indicated via a node of a set of nodes; 2) receive request for an incremental backup of one or more files of one or more volumes, wherein the map(s) track changed blocks from writes to the one or more files; 3) halt writes to the one or more files and queue writes to the one or more files after halting; 4) freeze the map(s) of changed blocks; 5) change file IO ETW tracking, wherein the change block info is tracked to a new set of maps; 6) determine changed blocks using the map(s); 7) write changed blocks to a backup volume; and 8) release writes to the one or more files.

Growing community of inventors

Bengaluru, India

Neelabh Mam