Creating frequent application-consistent backups efficiently

• US 7,613,750 B2
• Filed: 08/02/2006
• Issued: 11/03/2009
• Est. Priority Date: 05/29/2006
• Status: Active Grant

• Current Assignee: Microsoft Technology Licensing LLC (Microsoft Corporation)
• Original Assignee: Microsoft Corporation
• Inventors: Anand, Karandeep Singh, Fries, Robert M., Singla, Amit, Valiyaparambil, Manoj K., Ali, Abid, Badami, Vinay S., Sahasranaman, Vivek
• Primary Examiner(s): Cottingham; John R
• Assistant Examiner(s): Richardson; James E
• Application Number:
  US11/461,846
• Publication Number:
  US 20070276885A1
• Time in Patent Office: 1,189 Days
• Field of Search: 707/10, 707/100, 707/200, 707202-204, 711/161, 711/162
• US Class Current: 1/1
• CPC Class Codes: G06F 11/1451 by selection of backup contents
• CPC Class Codes: G06F 11/1458 Management of the backup or restore process
• CPC Class Codes: G06F 11/1464 for networked environments
• CPC Class Codes: G06F 11/1469 Backup restoration techniques
• CPC Class Codes: G06F 11/1471 involving logging of persistent data for recovery
• CPC Class Codes: G06F 2201/84 Using snapshots, i.e. a logical point-in-time copy of the data
• CPC Class Codes: Y10S 707/99955 Archiving or backup

Abstract

Data can be protected at a production server in a virtually continuous fashion, without necessarily imposing severe constraints on the source application(s). For example, a production server can create an application-consistent backup of one or more volumes, the backups corresponding to a first instance in time. A volume filter driver can monitor data changes in each volume using an in-memory bitmap, while a log file and/or update sequence number journal can keep track of which files have been added to or updated. The volume updates are also consistent for an instance (later) in time. At the next replication cycle, such as every few minutes (however configured), the volume filter driver passes each in-memory bitmap to the physical disk on the production server. The production server then sends the updates to the backup server, which thus stores application-consistent backups for the volume for multiple instances of time.

Claims

1. At a production server in a computerized environment in which one or more production servers backup data to be protected on one or more volumes at one or more backup servers, a method of replicating production server data in a virtually continuous, consistent fashion, such that recent data can be easily recovered from the backup server, comprising the acts of:

at a first instance of time, creating a copy of data for one or more volumes from a production server, the copy corresponding to a full baseline of the data for the one or more volumes;

sending the copy of the data for the one or more volumes from the production server to a backup server, wherein the data is consistent for the first instance of time;

subsequent to the first instance of time, storing an indication for each of one or more changes to the data on the one or more volumes, the indications being stored in one or more bitmaps that are stored in volatile memory on the production server, wherein at least one of the one or more changes includes a change to a file path of a file corresponding to any of the one or more data changes at the production server, such that the file path at the production server is different from a path to the file at the backup server;

upon identifying a replication cycle event, saving the one or more bitmaps to one or more log files that are stored in persistent storage of the production server, wherein the one or more data changes are consistent for a second instance of time;

deleting the one or more bitmaps from the volatile memory;

using the indications from the one or more bitmaps to identify the one or more data changes for the one or more volumes;

correlating the paths for the file at the production server and at the backup server, such that new changes to the file can be sent to the backup server with a change in the path for the file, wherein correlating the paths comprises;

scanning a USN journal at least a first time to cache the change in file path at the production server;

scanning the USN journal at least a second time to identify the initial file path at the production server; and

computing an adjusted path to the file at the backup server based on the first and second scans; and

sending to the backup server a copy of the one or more data changes for the one or more volumes, such that the backup server has a copy of data for the one or more volumes that are valid for a first instance of time and a second instance of time.

2. The method as recited in claim 1, further comprising saving file-level data changes for the volume in one of a change filter, a change journal, or a USN journal.

3. The method as recited in claim 2, further comprising an act of correlating the one or more volume log files with one of the change filter, change journal, or USN journal to identify one or more changed files that correspond to the one or more data changes in each changed file.

4. The method as recited in claim 1, further comprising an act of marking the one or more data changes on any one of a byte level or a byte block level in the one or more volume log files.

5. The method as recited in claim 1, further comprising the acts of:

freezing the one or more in-memory bitmaps corresponding to the second instance in time; and

creating a new set of one or more in-memory bitmaps corresponding to new writes to the one or more changed files for the third instance in time.

6. The method as recited in claim 1, wherein a volume filter driver receives the one or more data changes and applies the one or more data changes to the one or more volume log files.

7. The method as recited in claim 1, wherein the one or more data changes that are consistent for the first and second instances of time are at least one of application-consistent or file system-consistent.

8. The method as recited in claim 1, further comprising an act of sending a new update of volume data at the production server to the backup server, wherein the new update is consistent for a third instance of time, and wherein the time elapsed between the second and third instances of time is configurable for any time period of less than hour.

9. The method as recited in claim 8, further comprising an act of sending a request to the backup server for a copy of one or more files, wherein the request to the backup server for a copy of one or more files includes an indication that the one or more files are valid for one of the second or third instances in time.

10. The method as recited in claim 9, further comprising an act of receiving a recovery response from the backup server, wherein the recovery response includes a full copy of data for the requested one or more files as of the second or third instance of time.

11. The method as recited in claim 1, further comprising:

receiving the copy of data corresponding to the full baseline of the data for the one or more volumes, the copy of the data being consistent for the first instance of time;

receiving the copy of the one or more data changes for the one or more volumes, the copy of the one or more data changes being consistent for the second instance of time;

receiving a recovery request for data that is valid in accordance with the second instance of time;

identifying the requested data for the second instance of time at one or more backup server volumes, wherein the requested data includes at least a portion of the one or more data changes; and

sending the requested data that is valid for the second instance of time to the production server.

12. The method as recited in claim 11, further comprising the acts of:

receiving a subsequent copy of one or more data changes for the one or more volumes, the subsequent copy of the one or more data changes being consistent for a subsequent instance of time;

upon receiving a subsequent recovery request for data that is valid in accordance with the subsequent instance of time, identifying each of one or more copies of changes to the requested data that were received between receipt of the full baseline copy and receipt of the subsequent copy of one or more data changes; and

combining the full baseline copy of the requested data with the identified one or more copies of changes to the requested data.

13. The method as recited in claim 12, wherein the full baseline copy and the copies of the one or more data changes are at least one of application-consistent or file system-consistent.

14. At a production server in a computerized environment in which one or more production servers backup data to be protected at one or more backup servers, a computer storage media having computer-executable instructions stored thereon that, when executed, cause one or more processors at the production server to perform a method of replicating production server data in a virtually continuous, application-consistent fashion, such that recent data can be easily recovered from the backup server, comprising the acts of:

at a first instance of time, creating a copy of data for one or more volumes from a production server, the copy corresponding to a full baseline of the data for the one or more volumes;

sending the copy of the data for the one or more volumes from the production server to a backup server, wherein the data is consistent for the first instance of time;

subsequent to the first instance of time, storing an indication for each of one or more changes to the data on the one or more volumes, the indications being stored in one or more bitmaps that are stored in volatile memory on the production server, wherein at least one of the one or more changes includes a change to a file path of a file corresponding to any of the one or more data changes at the production server, such that the file path at the production server is different from a path to the file at the backup server;

upon identifying a replication cycle event, saving the one or more bitmaps to one or more log files that are stored in persistent storage of the production server, wherein the one or more data changes are consistent for a second instance of time;

deleting the one or more bitmaps from the volatile memory;

using the indications from the one or more bitmaps to identify the one or more data changes for the one or more volumes; and

correlating the paths for the file at the production server and at the backup server, such that new changes to the file can be sent to the backup server with a change in the path for the file, wherein correlating the paths comprises;

scanning a USN journal at least a first time to cache the change in file path at the production server;

scanning the USN journal at least a second time to identify the initial file path at the production server; and

computing an adjusted path to the file at the backup server based on the first and second scans; and

sending to the backup server a copy of the one or more data changes for the one or more volumes, such that the backup server has a copy of data for the one or more volumes that are valid for a first instance of time and a second instance of time.