Excluding files in a block based backup

[0001] When backing up data it may be desirable to exclude certain files from being backed up. For example, if the backup is being performed to protect user data, such as files or other objects created by the user using one or more applications, it may be desirable to exclude operating system files from being backed up, to avoid using associated storage space for example. Or, in backing up virtual machine data it may be desirable to back up operating system and/or virtual machine state-related files but not application data, such as Exchange Server objects, which may already be backed up by another system and/or process.

[0002] In a file-based backup, typically a list of files to be excluded from the backup is created and used to skip the files on the exclude list as the backup application walks the file system to create the backup. In a block-based backup, by contrast, the backup is performed at the volume level and it is not as simple a matter to skip files on the exclude list. Instead, it is necessary to determine which blocks store file data and/or metadata associated with files to be excluded, and to omit those from the backup data. On incremental backup, moreover, it is necessary to determine which blocks modified on the source volume are associate with files (data and/or metadata) that have been excluded from the prior backup(s) and for consistency are desired to continue to be excluded from the current incremental backup.

[0008] The invention can be implemented in numerous ways, including as a process; an apparatus; a system; a composition of matter; a computer program product embodied on a computer readable storage medium; and/or a processor, such as a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention. Unless stated otherwise, a component such as a processor or a memory described as being configured to perform a task may be implemented as a general component that is temporarily configured to perform the task at a given time or a specific component that is manufactured to perform the task. As used herein, the term ‘processor’ refers to one or more devices, circuits, and/or processing cores configured to process data, such as computer program instructions.

[0009] A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example and the invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.

[0010] Techniques to exclude files from a block-based backup are disclosed. In various embodiments, a shadow copy of a source volume is created. Files to be excluded from the backup are deleted, using a file delete functionality of the operating system. The file system updates associated metadata in the shadow copy, to reflect the deletion. Writes to the shadow volume are tracked, using a write tracker filter driver interposed in the shadow volume driver stack. The tracking data is used to identify blocks to be excluded from a subsequent incremental backup.

[0011] FIG. 1 is a block diagram illustrating an embodiment of a computer system. In the example shown, the computer 102, such as a file or other server, includes one or more processors, memory, and persistent storage such as one or more disk drives (not shown). One or more applications 104 run on an operating system (not shown) and provide the ability to end users to create and modify application content objects, such as documents or other files. Applications 104 interact with a file system 106, e.g., the NTFS file system, to store files or other objects in a source volume 108 on a storage device, such as a disk drive. To read from and write to source volume 108, file system 106 interacts with a disk driver 110, which performs the low level commands and interactions with the storage device on which source volume 108 is stored to read and write data to storage blocks comprising source volume 108, as needed. In the example shown, a writer tracker, e.g., a filter driver, 112 associated with a backup application (e.g., a backup client or other software) 114 intercepts and/or observers writes from file system 106 to source volume 108, using disk driver 110. In various embodiments, write tracker 112 may track which blocks have been modified, for example since a last full or incremental backup, enabling blocks that have been modified to be identified for inclusion in a subsequent incremental backup.

[0012] Referring further to FIG. 1, backup application 114 in the example shown interacts with a virtual shadow copy service (VSS) architecture 116 of the operating system of computer 102, e.g, Microsoft Windows®, to generate and store a shadow copy 118 of source volume 108. For example, a full backup of source volume 108 may be performed by copying all blocks in source volume 108 that have user data and/or file system metadata stored in them. Or, in some embodiments, a shadow copy of the entire volume, including unused blocks, may be created. In various embodiments, the shadow copy volume 118 is created in a manner that enables the shadow copy to be accessed and modified later. In some embodiments, a shadow copy service “context” that enables modifications to be made later is specified.

[0013] In various embodiments, once the shadow copy volume 118 has been created, a VSS writer 120 associated with the backup application 114 accesses the shadow copy volume 118 via file system 122 (in some embodiments the same, e.g., NTFS, file system as file system 106), to delete files desired to be excluded from the backup. The backup application 114 and/or another module provides to VSS writer 120 a list of files to be excluded, for example by specifying a path to and within the shadow copy volume 118 at which each file to be deleted is located. In various embodiments, the VSS writer 120 invokes a standard file delete API of file system 122, which results in the file data being deleted and associated metadata being updated in shadow copy volume 118. The interaction specifies for each file to be deleted a location within shadow copy volume 118 at which the file to be deleted is located. The corresponding source file in source volume 108 is not deleted.

[0014] In the example shown, file system 122 deletes the specified files via a write tracker 124 and a VSS driver 126. The write tracker 124 keeps track of which blocks in shadow copy volume 118 are modified in connection with the deletion of excluded files.

[0015] FIG. 2 is a flow chart illustrating an embodiment of a process to back up data. In the example shown, a VSS shadow copy volume (or other snapshot) is created (202). The operating system (i.e., file system) file delete API is used to delete from the shadow copy volume those files desired to be excluded from the backup (204). A writer tracker, e.g., a writer tracker filter driver, interposed between the file system and a VSS driver used to delete files from the shadow copy tracks changes to the shadow copy, e.g., which blocks were modified in connection with deletion of the excluded files (206).

[0016] FIG. 3 is a flow chart illustrating an embodiment of a process to exclude files from a block-based backup via a VSS shadow copy volume. In various embodiments, step 204 of FIG. 2 includes the process of FIG. 3. In the example shown, for each file on the list of files to be excluded, the shadow copy device path is obtained (302), e.g., \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy8. For each file, the file path of the file to be deleted is obtained (304) and appended with the shadow copy device name (306), e.g., \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy8\docs\ABC.doc. The file deletion API of the file system, e.g, the DeleteFile API of Windows Operating system, is used to delete each file from the shadow copy volume (308). The process is repeated for each file on the exclude list until all files to be excluded have been deleted from the shadow copy volume (310, 312). In a various embodiments, the file deletions from the shadow volume are tracked, e.g., by a write tracker such as write tracker 124 of FIG. 1.

[0017] FIG. 4 is a flow chart illustrating an embodiment of a process to perform a block-based incremental backup. In various embodiments, a VSS or other shadow copy volume created as described herein, i.e., to exclude files by deleting them from a shadow copy volume after a snapshot has been taken, is used as a starting point for an incremental backup using the process of FIG. 4. In the example shown, a bitmap indicating blocks which were modified in the source volume since the last backup is obtained, for example from a write tracker such as writer tracker 112 of FIG. 1 (402). A bitmap indicating blocks which were modified in the shadow copy volume after the snapshot was created, e.g., to delete files desired to be excluded from the backup, is obtained, for example from a write tracker such as writer tracker 124 of FIG. 1 (404). The bitmaps indicating blocks modified in the source volume (402) and the shadow copy volume (404) are merged (406) to generate a merged bitmap. For example, blocks modified in both the source volume and the shadow copy volume may be associated with a file desired to be excluded from backup, and may be included in the modified bitmap from the shadow copy volume, for example, as a result of being associated with (metadata and/or data) a file that was deleted from the shadow copy volume to exclude it from the backup. As a result, to exclude the file and associated metadata from the incremental backup as well, e.g., to ensure consistency and avoid backing up unwanted data, the blocks modified both in the source volume and in the shadow copy may be omitted from the merged bitmap. This would capture consolidated changes that were done both to the source volume as well as our VSS writer doing exclude operations on the shadow copy by deleting the said files to be excluded from the backup. Merge of two bitmaps is a bitwise AND operation on the two bitmaps. BIT denoting 0 as used and 1 as unused, we do a bitwise AND operation to consolidate changes.

[0018] Referring further to FIG. 4, the merged bitmap is converted to an extent list (408). A list of used extents is obtained from the shadow copy volume (410). The extents generated from the merged bitmap (408) and the “used” extents from the shadow copy volume (410) are used to determine an intersection of the two to generate a final modified extent list (412). Find the valid changes that were done by the APP on the source volume as well as delete transactions done on the shadow copy. For example, a file named “ABC.doc” could be created of size 100 MB. This transaction makes the write tracker driver record 100 MB of range as marked in the bitmap to indicate that it needs to be backed up during the next incremental backup.

[0019] Case 1: The same file (ABC.doc) is deleted on the source volume before the incremental backup is triggered. In that case, the file system updates the metadata block of that file saying that the file is deleted and frees up the used blocks space occupied by that file. But the write tracker driver still accounts for 100 MB of range that it reports as changed to be backed up. To solve this kind of problem, we find the common extents from the driver reported merged extent list and the file system reported used blocks list during the time of backup. Since the file system freed that particular zone of range 100 MB as unused. It would not be present in the intersected extent list. Case 2: The same file ABC.doc is specified by the user as a file to be excluded and the VSS writer deletes the file on the shadow copy. This would again result in the file system making similar transactions on the shadow copy and freeing up the used blocks space occupied by that file. Again the intersection of driver reported merged extent list and the file system reported used blocks list would not contain the blocks that were occupied by the file ABC.doc. Case 3: The file ABC.doc is not deleted on the source volume nor it is specified to be excluded from the backup. Then the intersection of driver reported merged extent list and the file system reported used blocks list would now account for the range that was occupied by file ABC.doc and be present in the backup media, since no delete operation was made neither on the source volume by the APP or nor on the shadow copy by the VSS writer. Case 4: Two incremental backups are taken and ABC.doc is not part of exclude list and is present in the source volume. Further appends/updates to the file ABC.doc of 2 MB are made and the same 2 MB range is then captured by the write tracker driver as changed blocks and reported via the bitmap during subsequent incremental workflows. This time though during the third incremental backup the file ABC.doc is now part of the exclude list item and our VSS writer deletes the file on the snapshot volume. The file system updates the metadata block of ABC.doc file to indicate that it has been removed, which involves writes to be made to the snapshot volume which is now captured by the write tracker driver which is attached to the shadow copy device stack also. Then the file system frees up the used blocks space occupied by that file. Further when the source volume driver bitmap and the shadow copy volume driver bitmap is merged, it now contains the consolidated changes, which reflect the file ABC.doc removal transaction. Finally when the intersection of driver reported merged extent list and the file system reported used blocks list is done it would not contain the blocks that were occupied by the file ABC.doc. The final modified extent list is used to perform the incremental backup, e.g., by copying those extents to backup media (414). Final changed blocks is then backed up into a differencing disk VHD format backup media which is further chained to its parent VHD.

[0020] Using techniques disclosed herein, a block-based backup can be performed using the virtual shadow copy service (VSS) or similar architecture, and files desired to be excluded from the backup can be excluded in a manner that facilitates subsequent incremental backups that also exclude the same files and associated metadata.

[0021] Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and not restrictive.