Title of Invention

"CREATING FREQUENT APPLICATION-CONSISTENT BACKUPS EFFICIENTLY"

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.

Full Text

I/we claim: 1. A method for protecting one or more production servers backup data in a computerized environment (100) at production server (105) on one or more volumes (175) at one or more backup servers (110), said method comprising: replicating production server data in a virtually continuous, consistent fashion, such that recent data can be easily recovered from the backup server, said replicating production server data comprising, 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 (200) the copy of the data for the one or more volumes from the production server (105) to a backup server (110), wherein the data is consistent for the first instance of time (145); 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 include 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 (220) 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 (150): and 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 path 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 (230) 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 (145) and a second instance of time (150). 2. The method as claimed in claim 1, wherein said method comprises saving file-level data changes for the volume in one of a change filter, a change journal, or a USN journal (140). 3. The method as claimed in claim 2. wherein said method comprises correlating the one or more volume log files (135) with one of the change filter, change journal, or USN journal (140) to identify one or more changed flies (120) that correspond to the one or more data changes in each changed file. 4. The method as claimed in claim 1. said method comprising: marking the one or more data changes (121. 122. 123) on any one of a byte level or a byte block level in the one or more volume log files. 5. The method as claimed in claim 1. said method comprising: 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 (193, 195) corresponding to new writes to one or more changed files for a third instance in time (155). 6. The method as claimed in claim 1. wherein a volume filter driver (115) receives the one or more data changes and applies the one or more data changes to the one or more volume log files (135). 7. The method as claimed in claim 1, wherein the one or more data changes that are consistent for the first and second instances of lime are at least one of application-consistent or file system-consistent. 8. The method as claimed in claim 1, said method comprising 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 (155), and wherein the time elapsed between the second (150) and third (155) instances of time is configurable for any time period of less than an hour. 9. The method as claimed in claim 8, said method comprising an act of sending a request to the backup server (I 10) 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 (150) or third (155) instances in time. 10. The method as claimed in claim 9. wherein said method comprising receiving a recovery response (160) from the backup server (110). 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 claimed in claim 1. said method comprising: receiving (240) 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 lime: receiving (250) 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 (260) a recovery request for data that is valid in accordance with the second instance of time; identifying (270) 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 (280) the requested data (160) that is valid for the second instance of time to the production server. 12. The method as claimed in claim 11, said method comprising: 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 (150, 155) to the requested data that were received between receipt of the baseline full 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 claimed 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.

Documents:

1283-DEL-2006-Claims-(26-07-2010).pdf

1283-DEL-2006-Correspondence-Others-(26-07-2010)-.pdf

1283-DEL-2006-Correspondence-Others-(30-03-2010).pdf

1283-DEL-2010-Correspondence-Others-(26-07-2010).pdf

1283-DEL-2010-Form-3-(26-07-2010).pdf