Backup and restoration of data in an electronic database

• US 6,651,077 B1
• Filed: 09/27/2000
• Issued: 11/18/2003
• Est. Priority Date: 09/27/2000
• Status: Active Grant

• Current Assignee: Microsoft Technology Licensing LLC (Microsoft Corporation)
• Original Assignee: Microsoft Corporation
• Inventors: East, Jeffrey A., Smith, Gregory A., Schmidt, Steven R.
• Primary Examiner(s): Metjahic, Safet
• Assistant Examiner(s): Nguyen, Cam-Linh
• Application Number:
  US09/671,496
• Time in Patent Office: 1,147 Days
• Field of Search: 707/202, 707/203, 707/204, 707/200
• US Class Current: 1/1
• CPC Class Codes: G06F 11/1458 Management of the backup or restore process
• CPC Class Codes: G06F 11/1469 Backup restoration techniques
• CPC Class Codes: G06F 2201/80 Database-specific techniques
• CPC Class Codes: G06F 2201/82 Solving problems relating to consistency ensuring consistency in mirrored systems G06F11/2064
• CPC Class Codes: Y10S 707/99953 Recoverability
• CPC Class Codes: Y10S 707/99955 Archiving or backup

Abstract

To avoid possible data corruption resulting from restoring data to a database from a backup set that is not valid for the database, attempted restore operations are intercepted before they are performed. The backup set is examined to determine whether it was created from the same recovery fork on which the database resides or an descendant of that recovery fork. The backup set is only allowed to be applied to the database if the backup set was created from one of these recovery forks. If not, the backup set is not allowed to be applied to the database.

Claims

1. A computer-implemented method for restoring information to an electronic database from a sequence of at least one backup set, the method comprising:

maintaining a history of one or more backup operations performed on the electronic database, the history associated with a recovery fork;

intercepting an attempted restore operation that uses the backup set;

determining whether the backup set is associated with the recovery fork or a descendant of the recovery fork;

permitting the backup set to be applied to the electronic database only if the backup set is associated with the recovery fork or a descendant of the recovery fork; and

maintaining a history both on the electronic database and the backup set, wherein each history comprises a push-down stack of a plurality of recovery fork names.

2. The method of claim 1, wherein each push-down stack comprises two recovery fork names.

3. The method of claim 1, further comprising:

comparing a recovery fork name associated with the electronic database with the recovery fork names in the push-down stack associated with the backup set; and

permitting the backup set to be applied to the electronic database only if the recovery fork name associated with the backup set is compatible with one of the recovery fork names in the pushdown stack associated with the electronic database.

4. The method of claim 1, wherein each of the recovery fork names in each push-down stack comprises a globally unique identifier (GUID) and a log sequence number (LSN).

5. The method of claim 4, further comprising:

determining whether a recovery fork name associated with the backup set has a GUID that matches a GUID of a recovery fork name associated with the electronic database;

permitting the backup set to be applied to the electronic database if the GUID of a topmost entry of the push-down stack associated with the backup set matches the GUID of the recovery fork name associated with the electronic database;

in response to identifying a first recovery fork name, other than the topmost entry of the push-down stack associated with the backup set, associated with the backup set and a second recovery fork name associated with the electronic database that have matching GUIDs, comparing the the LSN of the first recovery fork name with the LSN of the second recovery fork name;

rejecting the attempted restore operation if the LSN of the second recovery fork name is greater than the LSN of the first recovery fork name; and

permitting the backup set to be applied to the electronic database if a recovery fork name associated with the backup set has a GUID that matches a GUID of a recovery fork name is no greater than the LSN of the first recovery fork name.

6. The method of claim 1, further comprising:

determining whether the attempted restore operation is to be performed with or without an option for recovery;

if the attempted restore operation is to be performed with the option for recovery,

replacing the recovery fork names associated with the electronic database with the recovery fork names associated with the backup set,

generating a new recovery fork name;

pushing the new recovery fork name onto the push-down stack associated with the electronic database, the new recovery fork name comprising a GUID and the LSN of the backup set; and

if the attempted restore operation is to be performed without the operation for recovery,

clearing the push-down stack associated with the electronic database, and

pushing a topmost recovery fork name of the push-down stack associated with the backup set onto the push-down stack associated with the electronic database.

7. The method of claim 1, wherein the electronic database comprises a plurality of files each associated with a current recovery fork identifier, wherein the attempted restore operation is a log restore operation occurring subsequent to at least one file restore operation for using a plurality of backup files, and further comprising:

for each of the plurality of backup files,

comparing a current recovery fork identifier associated with a file of the electronic database with a plurality of recovery fork identifiers associated with the backup file,

marking the file of the electronic database as eligible to be applied to the electronic database if a most recent one of the recovery fork identifiers associated with the backup file has the same globally unique identifier (GUID) as the current recovery fork identifier associated with the file of the electronic database, or if another one of the recovery fork identifiers associated with the backup file has a same GUID as the current recovery fork identifier associated with the file of the electronic database and has a log sequence number (LSN) greater than or equal to an LSN of the current recovery fork identifier associated with the file of the electronic database;

applying to the electronic database only the backup files marked as eligible;

coping the most recent one of the recovery fork identifiers associated with the backup file to a file header associated with the file of the electronic database; and

setting a database-wide fork stack to a null value.

8. A computer-implemented method for restoring information to an electronic database from a backup set, the method comprising:

maintaining in the electronic database and in the backup set a history of one or more backup operations performed on the electronic database, the electronic database associated with a recovery fork, each history comprising a push-down stack of two recovery fork names each having a globally unique identifier (GUID) and a log sequence number (LSN);

intercepting an attempted restore operation that uses the backup set;

determining whether a recovery fork name associated with the backup set has a GUID that matches a GUID of a recovery fork name associated with the electronic database;

in response to identifying a first recovery fork name associated with the backup set and a second recovery fork name associated with the electronic database that have matching GUIDs, comparing the LSN of the first recovery fork name with the LSN of the second recovery fork name;

rejecting the attempted restore operation if the LSN of the second recovery fork name is greater than the LSN of the first recovery fork name; and

permitting the attempted restore operation if a recovery fork name associated with the backup set has a GUID that matches a GUID of a recovery fork name associated with the electronic database and the LSN of the second recovery fork name is no greater than the LSN of the first recovery fork name.

9. A computer-implemented method for creating a backup set based on information from an electronic database, the method comprising:

maintaining a history of one or more backup operations performed on the electronic database, wherein said history comprises a push-down stack of a plurality of recovery fork names;

copying the history to the backup set;

if the backup set is to be the result of a database backup operation, updating the history to reflect a binding identifier of the backup set;

if the backup set is to be the result of a backup operation other than a file backup operation, updating the history; and

performing a backup operation.

10. The method of claim 9, wherein each of said recovery fork name has a globally unique identifier (GUID) and a log sequence number (LSN), further comprising:

if the backup set is to be the result of a database backup operation,

updating the LSN of a topmost recovery fork name of the push-down stack to reflect a synchronization point of the backup set, and

copying the updated push-down stack to the backup set; and

if the backup set is to be the result of a backup operation other than a file backup operation, setting the LSN of the topmost recovery fork name of the push-down stack to a current end-of-log LSN.

11. A computer-readable medium having computer-executable modules comprising:

a maintenance module configured to maintain a history of one or more backup operations performed on the electronic database, the electronic database associated with a recovery fork, wherein said history comprises a push-down stack of a plurality of recovery fork names;

an interceptor module configured to intercept an attempted restore operation that uses the backup set; and

a control module configured to determine whether the backup set is associated with the recovery fork or an descendant of the recovery fork, and to permit the backup set to be applied to the electronic database only if the backup set is associated with the recovery fork or an descendant of the recovery fork.

12. The computer-readable medium of claim 11, wherein the maintenance module is further configured to maintain a history both on the electronic database and on the backup set, each history being maintained as a push-down stack of a plurality of recovery fork names.

13. The computer-readable medium of claim 12, wherein each of the recovery fork names in each push-down stack comprises a globally unique identifier (GUID) and a log sequence number (LSN).

14. The computer-readable medium of claim 13, wherein the control module is further configured to:

determine whether a recovery fork name associated with the backup set has a GUID that matches a GUID of a recovery fork name associated with the electronic database;

permit the backup set to be applied to the electronic database if the GUID of a topmost entry of the push-down stack associated with the backup set matches the GUID of the recovery fork name associated with the electronic database;

in response to identifying a first recovery fork name, other than the topmost entry of the push-down stack associated with the backup set, associated with the backup set and a second recovery fork name associated with the electronic database that have matching GUIDs, compare the LSN of the first recovery fork name with the LSN of the second recovery fork name;

reject the attempted restore operation if the LSN of the second recovery fork name is greater than the LSN of the first recovery fork name; and

permit the backup set to be applied to the electronic database if a recovery fork name associated with the backup set has a GUID that matches a GUID of a recovery fork name associated with the electronic database and the LSN of the second recovery fork name is no greater than the LSN of the first recovery fork name.

15. The computer-readable medium of claim 12, wherein the control module is further configured to:

comparing a recovery fork name associated with the electronic database with the recovery fork names in the push-down stack associated with the backup set; and

permit the backup set to be applied to the electronic database only if the recovery fork name associated with the backup set is compatible with one of the recovery fork names in the push-down stack associated with the electronic database.

16. The computer readable medium of claim 12, wherein the maintenance module is further configured to:

determine whether the attempted restore operation is to be performed with or without an option for recovery;

if the attempted restore operation is to be performed with the option for recovery,

replace the recovery fork names associated with the electronic database with the recovery fork names associated with the backup set,

generate a new recovery fork name,

push the new recovery fork name onto the push-down stack associated with the electronic database, the new recovery fork name comprising a new GUID and the LSN of the backup set; and

if the attempted restore operation is to be performed without the operation for recovery,

clear the push-down stack associated with the electronic database, and

push a topmost recovery fork name of the push-down stack associated with the backup set onto the push-down stack associated with the electronic database.

17. The computer-readable medium of claim 12, wherein the electronic database comprises a plurality of files each associated with a current recovery fork identifier, wherein the attempted restore operation is a log restore operation occurring subsequent to at least one file restore operation, and wherein:

the control module is further configured to

determine whether the push-down stack associated with the electronic database is empty, and

if the push-down stack associated with the electronic database is empty, permit the attempted restore operation if the current recovery fork identifiers of the plurality of files are compatible; and

the maintenance module is further configured to

if the push-down stack associated with the electronic database is empty, push the current recovery fork identifier from one of the plurality of files onto the push-down stack associated with the electronic database,

if the restore operation is performed with the option of recovery, generate a new recovery fork name comprising a GUID and an LSN, and

push the new recovery fork name onto the push-down stack associated with the electronic database.

18. A computer-readable medium having computer-executable modules comprising:

a maintenance module configured to maintain in the electronic database and in the backup set a history of one or more backup operations performed on the electronic database, the electronic database associated with a recovery fork, each history comprising a push-down stack of two recovery fork names each having a globally unique identifier (GUID) and a log sequence number (LSN);

an interceptor module configured to intercept an attempted restore operation that uses the backup set; and

a control module configured to

determine whether a recovery fork name associated with the backup set has a GUID that matches a GUID of a recovery fork name associated with the electronic database;

permit the backup set to be applied to the electronic database if the GUID of a topmost entry of the push-down stack associated with the backup set matches the GUID of a recovery fork name associated with the electronic database;

in response to identifying a first recovery fork name, other than the topmost entry of the push-down stack associated with the backup set, associated with the backup set and a second recovery fork name associated with the electronic database that have matching GUIDs, compare the LSN of the first recovery fork name with the LSN of the second recovery fork name;

reject the attempted restore operation if the LSN of the second recovery fork name is greater than the LSN of the first recovery fork name; and

permit the backup set to be applied to the electronic database if a recovery fork name associated with the backup set has a GUID that matches a GUID of a recovery fork name associated with the electronic database and the LSN of the second recovery fork name is no greater than the LSN of the first recovery fork name.

19. A computer-readable medium having computer-executable modules comprising:

a maintenance module configured to

maintain a history of one or more backup operations performed on the electronic database, wherein said history comprises a push-down stack of a plurality of recovery fork names;

copy the history to the backup set,

if the backup set is to be the result of a database backup operation, updating the history to reflect a binding identifier of the backup set, and

if the backup set is to be the result of a backup operation other than a file backup operation, update the history; and

a backup module configured to perform a backup operation.

20. The computer-readable medium of claim 19, wherein each of said recovery fork names has a globally unique identifier (GUID) and a log sequence number (LSN), and where the maintenance module is further configured to:

if the backup set is to be the result of a database backup operation, update a differential binding identifier of a database-wide fork stack to reflect a binding identifier of the backup set; and

if the backup set is to be the result of a backup operation other than a file backup operation, set the LSN of the topmost recovery fork name of the push-down stack to a current end-of-log LSN.