US8635187B2 - Method and system of performing incremental SQL server database backups - Google Patents

Method and system of performing incremental SQL server database backups Download PDF

Info

Publication number
US8635187B2
US8635187B2 US12/986,666 US98666611A US8635187B2 US 8635187 B2 US8635187 B2 US 8635187B2 US 98666611 A US98666611 A US 98666611A US 8635187 B2 US8635187 B2 US 8635187B2
Authority
US
United States
Prior art keywords
database
backup
full
file
incremental
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
US12/986,666
Other versions
US20120179655A1 (en
Inventor
Louis J. Beatty
Michael A. Payne
Steven R. DeVos
Deepak Saraf
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Veritas Technologies LLC
Original Assignee
Symantec Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Symantec Corp filed Critical Symantec Corp
Priority to US12/986,666 priority Critical patent/US8635187B2/en
Assigned to SYMANTEC CORPORATION reassignment SYMANTEC CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: DEVOS, STEVEN R., PAYNE, MICHAEL A., Beatty, Louis J., SARAF, DEEPAK
Priority to JP2011289030A priority patent/JP6495568B2/en
Priority to EP20120150113 priority patent/EP2474909A3/en
Priority to CN201210003647.0A priority patent/CN102591982B/en
Publication of US20120179655A1 publication Critical patent/US20120179655A1/en
Priority to US14/159,235 priority patent/US9703640B2/en
Publication of US8635187B2 publication Critical patent/US8635187B2/en
Application granted granted Critical
Assigned to VERITAS US IP HOLDINGS LLC reassignment VERITAS US IP HOLDINGS LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: SYMANTEC CORPORATION
Assigned to BANK OF AMERICA, N.A., AS COLLATERAL AGENT reassignment BANK OF AMERICA, N.A., AS COLLATERAL AGENT SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: VERITAS US IP HOLDINGS LLC
Assigned to WILMINGTON TRUST, NATIONAL ASSOCIATION, AS COLLATERAL AGENT reassignment WILMINGTON TRUST, NATIONAL ASSOCIATION, AS COLLATERAL AGENT SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: VERITAS US IP HOLDINGS LLC
Assigned to VERITAS TECHNOLOGIES LLC reassignment VERITAS TECHNOLOGIES LLC MERGER AND CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: VERITAS TECHNOLOGIES LLC, VERITAS US IP HOLDINGS LLC
Assigned to WILMINGTON TRUST, NATIONAL ASSOCIATION, AS NOTES COLLATERAL AGENT reassignment WILMINGTON TRUST, NATIONAL ASSOCIATION, AS NOTES COLLATERAL AGENT SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: VERITAS TECHNOLOGIES LLC
Assigned to VERITAS US IP HOLDINGS, LLC reassignment VERITAS US IP HOLDINGS, LLC TERMINATION AND RELEASE OF SECURITY IN PATENTS AT R/F 037891/0726 Assignors: WILMINGTON TRUST, NATIONAL ASSOCIATION, AS COLLATERAL AGENT
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1446Point-in-time backing up or restoration of persistent data
    • G06F11/1448Management of the data involved in backup or backup restore
    • G06F11/1451Management of the data involved in backup or backup restore by selection of backup contents
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1446Point-in-time backing up or restoration of persistent data
    • G06F11/1458Management of the backup or restore process
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1446Point-in-time backing up or restoration of persistent data
    • G06F11/1458Management of the backup or restore process
    • G06F11/1469Backup restoration techniques
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/11File system administration, e.g. details of archiving or snapshots
    • G06F16/128Details of file system snapshots on the file-level, e.g. snapshot creation, administration, deletion
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/80Database-specific techniques
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/84Using snapshots, i.e. a logical point-in-time copy of the data

Definitions

  • FIG. 1 is a diagram that illustrates a database archival system in accordance with one or more embodiments.
  • FIG. 3 illustrates a snapshot image in accordance with one or more embodiments.
  • FIG. 4 illustrates a media server and a storage device with stored database backup files in accordance with one or more embodiments.
  • FIG. 7 illustrates one embodiment of an unmounted database file reconstructed from a full backup file and an incremental backup file.
  • FIG. 9 is a generalized flow diagram illustrating one embodiment of a restore operation following from an incremental backup.
  • Database 150 may represent both a database program and/or one or more actual databases implemented therein.
  • the database program refers to the executable commands, user interfaces and other program code for operating the database.
  • the included databases may further comprise various tables, indexes, relationships, queries, stored procedures, file systems, security layers, networking interfaces, etc., which are configured to operate on a plurality of data records.
  • the records in database 150 may be arranged in tables (row and column arrangement).
  • the term “record” as used herein shall refer to an entry in a database.
  • a collection of associated records may be collectively described as a “table” in the database.
  • a record may consist of one or more fields, which may serve as indexes (or keys) to other records in other tables.
  • each record in a document table may represent a document stored in the database.
  • the document may be stored in the fields of the record itself.
  • the document may be represented in a record by a reference to the document, such as a memory location.
  • the database may create and modify a mounted database file for storing and accessing any given implementation of a relational database.
  • database 150 may execute on a dedicated computing system, such as database server 110 , that is configured for access by other server and client computers via network 120 .
  • Database 150 may include various kinds of functions associated with a relational database, such as add and query procedures.
  • the query function may retrieve information from the database, such as a change map, allocation maps, objects, tables, records, and other data.
  • the add function may store information in the database.
  • Databases 150 may be a Microsoft SQL Server database and the interface used to provide access to database 150 may use SQL.
  • Data may be stored and retrieved from database 150 at a page level. Each page may have a size of 8 kilobytes (KB) and may consist of a header and data.
  • the page header may contain an object ID to which the data in the page belongs.
  • Server input/output (I/O) operations may be performed at the page level, such that database server 110 reads or writes whole pages.
  • a subsequent incremental backup process may be employed to generate an incremental backup and capture only the extents that have changed since the most recent full backup.
  • the generation of incremental backups may continue indefinitely, wherein a continuous number of subsequent incremental backups may be performed and created, wherein each incremental backup includes extents that have changed after the most recently performed incremental backup.
  • the changed extents from the plurality of incremental backup operations may be stored in backup storage device 140 .
  • the number and type of database servers, databases, media servers, networks, and backup storage devices is not limited to those shown in FIG. 1 . Any number and combination of media servers, database servers, and databases may be interconnected in network architectures via various combinations of modem banks, direct LAN connections, wireless connections, WAN links, etc.
  • snapshot 240 is stored in storage device 230 .
  • Snapshot 240 may be created by database server 210 , and snapshot 240 may represent a backup image of database 220 .
  • Snapshot 240 may be a static, point-in-time representation of database 220 .
  • Snapshot 240 may be a copy of a full image of the entire database, and database server 210 may store snapshot 240 in storage device 230 after performing the snapshot backup.
  • a media server (not shown) may access snapshot 240 to perform an incremental backup.
  • a media server may access snapshot 240 to perform a full backup.
  • Database server 210 may consider a snapshot backup as a full backup, and database server 210 may reset maps and other metadata to indicate that the snapshot backup was the equivalent of a full backup.
  • a media server may retrieve DCM 320 from snapshot 310 . Then, the media server may read the pages of DCM 320 to determine which extents have been modified since a previous full or incremental backup. The media server may execute a query to retrieve the pages that make up the DCM from snapshot 310 .
  • the first DCM page may be located at the 7 th page of snapshot 310 .
  • the second DCM page may be located 512232 pages offset from the first DCM page, at the 512239 th page.
  • the third page DCM page may be offset 1024464 pages from the first DCM page, at the 1022471th page, and so on.
  • the media server may retrieve from snapshot 310 only the changed extents which have been allocated to an object. Then, the media server may store the retrieved extents in a storage device. The media server may also store metadata including one or more maps as part of the incremental backup. Alternatively, the media server could backup snapshot 310 in its entirety as part of a full backup. However, performing a full backup of snapshot 310 may take up a much larger amount of storage space than performing an incremental backup. After the changed extents and one or more maps are retrieved from snapshot 310 and stored in a backup storage device, snapshot 310 may be discarded. The above steps regarding snapshot 310 described as being performed by a media server may also be performed by a database server, other server, or other type of computing device.
  • Media server 410 may store files associated with backups of a database in backup storage device 420 .
  • Full backup file 425 is stored in backup storage device 420 , and full backup file 425 may contain data from a prior full database backup operation.
  • full backup file 425 may be a master data file (MDF).
  • Media server 410 may also be configured to generate and store a schema of table and index information along with the backed up contents in the full backup file 425 .
  • the schema may refer to the data structure of a database file, and the schema may include memory locations that define certain data structures within the database file.
  • the schema may be used to quickly and efficiently locate objects in full backup file 425 , without having to perform extensive searching operations.
  • the schema may be generated by querying a database when a full backup of the database is being created.
  • the schema may be used to access or restore the contents of full backup file 425 without using the live database or the database server.
  • Incremental backup files 430 and 440 are also stored in backup storage device 420 .
  • Incremental backup files 430 and 440 may also be referred to as block level incremental files.
  • Incremental backup files 430 and 440 contain the changed extents that are backed up as part of incremental backup operations of a database.
  • Incremental backup files 430 and 440 are representative of any number of files associated with any number of incremental backup operations that may be performed. For example, if ten incremental backups are performed on a database connected to media server 410 , then there may be ten incremental backup files stored in backup storage device 420 .
  • full backup file 425 and/or incremental backup files 430 and 440 may be binary files that are sequentially accessed, using standard file I/O calls to the file system of backup storage device 420 .
  • the file system may be an information system which references and stores data, hierarchically organized in files and directories, in a volume created on backup storage device 420 .
  • full backup file 425 and/or incremental backup files 430 and 440 may be structured in block units of memory, also referred to as pages or allocation units.
  • Metadata 435 and 445 are also stored in backup storage device 420 , and metadata 435 corresponds to incremental backup file 430 and metadata 445 corresponds to incremental backup file 440 .
  • Metadata 435 includes additional data, such as one or more maps, that may be stored in backup storage device 420 as part of the incremental backup operation associated with incremental backup file 430 .
  • the one or more maps may include a DCM, GAM, SGAM, IAM, and other maps. Additional information may also be stored in metadata 435 relating to incremental backup file 430 .
  • Metadata 435 may be used to facilitate restore operations for one or more data items from incremental backup file 430 .
  • metadata 435 may be stored within incremental backup file 430 . The above described features of metadata 435 may also apply to metadata 445 .
  • media server 410 may delete the old full database backup file from backup storage device 420 .
  • Media server 410 may also delete the old metadata and incremental backup files at that time.
  • media server 410 may retain one or more prior full database backup files, incremental backup files, and/or metadata files when a new full database backup operation is performed.
  • Media server 410 may have a retention policy regarding metadata files, incremental backup files, and full database backup files that involves deleting older files to free up storage space in backup storage device 420 .
  • full backup file 425 may be converted into an incremental backup file (or a differential backup file) to reduce the storage utilization associated with full backup file 425 .
  • full backup file 425 corresponds to a snapshot backup
  • one or more maps that identify data which has changed as compared to an earlier backup may be retrieved from full backup file 425 .
  • the maps identifying the changed data (which may be identified as extents) may be stored separately from full backup file 425 , and the maps may be retrieved from this separate file or location. After the maps have been retrieved and the changed data has been identified, the changed data may be retrieved from full backup file 425 and stored as an incremental backup file in backup storage device 420 .
  • full backup file 425 may be converted into an incremental backup file. After full backup file 425 has been converted into an incremental backup file, full backup file 425 may be discarded from backup storage device 420 . An identification of the earlier backup to which the newly created incremental backup corresponds may also be stored.
  • a previous full backup file that was created prior to full backup file 425 may need to be stored in backup storage device 420 .
  • the previous full backup file may be referenced by (or otherwise associated with) the converted incremental backup file to facilitate any potential restore operations.
  • a future restore operation may then utilize both the previous full backup file and the converted incremental backup file.
  • FIG. 5 an illustration of system and method for compressing previously stored full backup files is shown.
  • stored full backup files are converted into partial (e.g., incremental) backup files.
  • Media server 510 is connected to backup storage device 520 , and backup storage device 520 stores full backup files 530 , 540 , 550 , and 560 .
  • Full backup files 530 - 560 are representative of any number of full backup files which may be stored in backup storage device 520 .
  • objects may be restored from unmounted database file 660 to the working copy of database 630 , or to another copy of database 630 .
  • objects may be buffered in memory in database server 610 before being restored to the working copy of database 630 .
  • objects may be restored from unmounted database file 660 to a file system on a storage medium, database server 610 , media server 670 , other server, client, or other computing device.
  • objects may be restored to an internal portal application or other software application.
  • unmounted database file 660 , full backup file 640 , and incremental backup file 650 in FIG. 7 are logical representations of these files. The actual structure and organization of these files may be different from how they appear in FIG. 7 .
  • additional data may be appended to incremental backup file 650 .
  • metadata describing the new objects may be added to the end of incremental backup file 650 .
  • metadata describing the deleted objects may be appended to incremental backup file 650 .
  • the restore application may use the metadata to determine which objects to add and which objects to delete from unmounted database file 660 .
  • one or more maps may be retrieved from the snapshot (block 840 ).
  • the maps may include a DCM, GAM, SGAM, IAM, and/or other maps.
  • the maps may be read to determine which extents have changed subsequent to a prior backup (block 850 ).
  • the maps may also be used to determine if the changed extents are allocated.
  • the prior backup may have been a full backup, snapshot backup, or incremental backup.
  • the changed extents may be retrieved from the snapshot (block 860 ).
  • the one or more maps may be used to locate the changed extents within the snapshot. In one embodiment, only the changed extents that are allocated to objects may be retrieved.
  • the changed extents may be stored as an incremental backup file in a storage device (block 870 ). Also, the one or more maps and any additional metadata may also be stored in a storage device. Then, the snapshot may be discarded in block 880 . After block 880 , method 800 may end in block 890 .
  • the method 900 starts in block 910 , and then a request to perform a restore operation from a backup version of the database may be detected in block 920 .
  • the restore operation may be requested by a user or administrator, and the restore operation may be requested based on a specific point-in-time of the database corresponding to a prior backup operation.
  • the prior backup operation may have been a full, incremental, differential, or log backup of the database.
  • a prior full database backup file may be retrieved in block 930 .
  • the prior full database backup file may correspond to the most recent full backup operation of the database at or prior to the specific point-in-time requested by the user.
  • the prior full database backup file may be stored in a storage device (block 940 ).
  • the database server may be notified that the reconstructed database file is ready to be restored.
  • the database server may restore the entire reconstructed file, or the database server may restore one or more objects from the reconstructed file.
  • method 900 may end in block 980 .
  • a computer readable storage medium may include any storage media accessible by a computer during use to provide instructions and/or data to the computer.
  • a computer readable storage medium may include storage media such as magnetic or optical media, e.g., disk (fixed or removable), tape, CD-ROM, DVD-ROM, CD-R, CD-RW, DVD-R, DVD-RW, or Blu-Ray.
  • Storage media may further include volatile or non-volatile memory media such as RAM (e.g., synchronous dynamic RAM (SDRAM), double data rate (DDR, DDR2, DDR3, etc.) SDRAM, low-power DDR (LPDDR2, etc.) SDRAM, Rambus DRAM (RDRAM), static RAM (SRAM)), ROM, non-volatile memory (e.g. Flash memory) accessible via a peripheral interface such as the USB interface, etc.
  • RAM e.g., synchronous dynamic RAM (SDRAM), double data rate (DDR, DDR2, DDR3, etc.) SDRAM, low-power DDR (LPDDR2, etc.) SDRAM, Rambus DRAM (RDRAM), static RAM (SRAM)
  • ROM non-volatile memory
  • Storage media may include micro-electro-mechanical systems (MEMS), as well as storage media accessible via a communication medium such as a network and/or a wireless link.
  • MEMS micro-electro-mechanical systems

Abstract

A system, method, and medium for performing incremental backups of a Microsoft SQL server database. A snapshot of the database is created, and then a map identifying the changed extents is retrieved from the snapshot. The changed extents are then retrieved from the snapshot and stored in a backup storage device. For a restore operation, a full database backup file is written to a storage device and then the changed extents from a stored incremental backup file may be merged with the full backup file. Next, the database server is notified of the reconstructed file and then the reconstructed file is mounted by the database server as a live instance of the database.

Description

BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates generally to database backups, and in particular to a method and system for performing incremental backups of a SQL server database.
2. Description of the Related Art
Database systems, such as a Microsoft® structured query language (SQL) server database system, contain vast amounts of information generated and used by a variety of software applications. Because of the importance of the information stored in databases, a database system provides mechanisms to back up and restore the databases managed by that system. A backup mechanism may create a complete copy of the database, and the restore mechanism may overwrite the database with the copy. A database system may also be capable of playing back transactions to restore a database. Such a database system may log all transactions and use those transactions to restore a database to a particular state by starting at a known prior state and applying transactions that occurred after that state.
A database system may also provide a snapshot mechanism that allows the state of a database to be preserved in a “snapshot.” Typically, taking a snapshot is a precursor to performing a full backup. Performing a snapshot is a way to minimize the disruption to the SQL server, as compared to performing a streaming backup. Microsoft SQL server supports snapshot backup and restore technologies. A snapshot backup is a specialized backup that is created almost instantaneously. A snapshot may be created by various well-known techniques, including copy-only backup, split-mirror, specialized hardware that creates a copy of a storage device, and other methods. Snapshot backups may minimize or eliminate the use of the resources of the SQL server to accomplish the backup. This may allow the availability of the SQL server to be minimally impacted by performing a backup operation.
Database systems utilize snapshots for a variety of reasons. One typical use of snapshots is to copy a database without disabling access to the database for a long period of time. After performing the snapshot, the database system can then copy the database by leveraging the snapshot of the database. Thus, the database system performs a full backup of the primary database when the primary database is active. In general, a snapshot records the state of the database at a certain point in time. That is, the snapshot may be used to provide a point-in-time image of a live database. Additional operations can then be performed using the snapshot copy without affecting the performance of the live database.
Another goal, besides reducing the downtime of an active SQL server database, is to reduce backup storage utilization. To achieve this goal, differential backups are often performed instead of full backups. Performing differential backups takes advantage of a common characteristic of SQL server databases—typically, only a small percentage of the data in the database changes in between consecutive backups. With only part of the data actually changing between backups, it increases the efficiency of the backups to perform a differential backup instead of a full backup. The time necessary to complete the backup may be reduced, limiting the downtime of the database, and the amount of data stored in the backup may also be reduced, decreasing the amount of storage required to store the backup.
SQL server maintains a bitmap with information on which extents have changed since the last full backup. This bitmap is called the differential change map (DCM), and SQL server uses the DCM to perform differential backups. The DCM tracks the extents that have changed since the last full database backup. Extents are a collection of eight physically contiguous pages and may be used to efficiently manage pages. The DCM is a bitmap where each bit represents a single extent. The bitmap is organized such that if the bit for an extent is 1, then the extent has been modified since the last full backup and if the bit for an extent is 0, then the extent has not been modified.
SQL server also maintains allocation maps to record the allocation of extents to objects in the database. One of the allocation maps is the index allocation map (IAM). The IAM contains information about the extents that a table or index uses. Another of the allocation maps is the global allocation map (GAM). The GAM contains information about which extents have been allocated. Another of the allocation maps is the shared global allocation map (SGAM). The SGAM tracks mixed extents that have at least one unused page. There is also a way to track free space, called the page free space (PFS) pages. The PFS pages record the allocation status of each page, such as whether an individual page has been allocated and the amount of free space on each page.
A common technique used for administering a SQL database is to preallocate extra space to the database to give it room to expand. When a database file is mounted by a SQL server, and when the size of the database file needs to increase beyond the size allocated to it to accommodate new transactions, it is a time-consuming process to increase the size of the database. Therefore, it is customary for the size of the SQL database to be much larger than the amount of data it currently stores. However, when performing a full backup, all of the space allotted to the database, even if it is not being used, will be backed up, thus increasing the size of backups. Also, if a table or other object has been deleted from the database, a full backup will still back up all the space that the deleted table or object took up.
Differential backups may be used by SQL server to reduce the size of the backups, but differential backups have some drawbacks. For example, a differential backup must be restored to a live instance of the database, which will result in downtime of the database. SQL server also support log backups to backup a list of transactions that have occurred; like differential backups, log backups need to be played back to a live instance of the database during restoration. It would be preferable to prepare a full copy of a point-in-time database file for restoration without requiring any assistance from the SQL server.
Another way to reduce the size of database backups, other than performing differential or log backups, is to perform incremental backups. However, SQL server currently does not support incremental backups of the database. Therefore, what is needed is a way to perform an incremental backup making use of the snapshot and data tracking mechanisms maintained by SQL server, while also preserving the ability to do a fast, efficient restoration from the incremental backup.
In view of the above, methods and mechanisms for performing incremental backups of a SQL database are desired.
SUMMARY OF THE INVENTION
Various embodiments of methods and mechanisms for performing incremental backups of a SQL server database are contemplated. In one embodiment, a full backup of the database may be performed. After the full backup, subsequent backups may be incremental backups. To perform an incremental backup, first a request to perform a full backup of the database may be conveyed to the SQL server. The SQL server may behave as though a full backup of the database is being performed, even though an incremental backup may actually be performed. Next, a snapshot of the database may be taken. One or more maps may be retrieved from the snapshot. The one or more maps may include information identifying the extents that have changed since a prior full backup, prior snapshot, or prior incremental backup. After identifying the changed extents, the changed extents may be retrieved from the snapshot and stored as an incremental backup file in a backup storage device. Then, the snapshot may be discarded. At some point after the snapshot of the database is taken, the SQL server may reset the live copy of the DCM bitmap as though a full backup operation were performed.
In another embodiment, after identifying the changed extents, one or more allocation maps may be retrieved and read to determine if each of the changed extents is allocated to a table or other object. If a changed extent is not allocated, then the changed extent will not be stored as part of the incremental backup. One or more maps may also be stored as part of the incremental backup. The method further comprises repeating the above described steps for a plurality of incremental backups and snapshots.
In a further embodiment, previously stored full backup may be converted to a partial backup such as an incremental backup or a differential backup. In one embodiment, a stored snapshot of the database may be retrieved from a storage device. The stored snapshot may correspond to a previous full backup operation performed on the database. The stored full backup may be converted into an incremental backup file to reduce the storage utilization for that particular backup. To convert the stored snapshot into an incremental backup file, one or more maps identifying changed extents may be retrieved from the snapshot. Alternatively, the one or more maps identifying changed extents may be stored separately from the snapshot. Then, the changed extents may be retrieved from the stored snapshot and stored as an incremental backup file in a backup storage device. The unchanged data from the backup may be discarded. Alternatively, other similar techniques may be used to convert a stored full backup file into an incremental backup file.
In another embodiment, a restore operation may be requested following one or more incremental backups. A media server may retrieve a prior full backup file from a backup storage device and write the prior full backup file to a storage device, such as a disk or other storage device associated with the media server or the SQL server. The media server may perform this step without requiring any input from the SQL server. This may allow the SQL server to continue performing operations as part of the normal functionality of the database, such as processing new transactions. Next, the media server may retrieve one or more incremental backup files and write the changed extents from the incremental backup files to the appropriate locations within the full backup file. The media server may write changed extents to the full backup file from a plurality of incremental backup files; the plurality of incremental backup files may correspond to a plurality of incremental backups that were performed following the full backup operation. The media server may also write changed extents from the incremental backup files in the order they were created, such that changed extents from the oldest incremental backup file are written first, and changed extents from the newest incremental backup file are written last. The media server may determine where the changed extents belong in the unmounted full backup file by reading the one or more maps that were stored as part of the incremental backup operation. The media server may write the changed extents back within the unmounted full backup file without requiring any input from the SQL server.
These and other features and advantages will become apparent to those of ordinary skill in the art in view of the following detailed descriptions of the approaches presented herein.
BRIEF DESCRIPTION OF THE DRAWINGS
The above and further advantages of the methods and mechanisms may be better understood by referring to the following description in conjunction with the accompanying drawings, in which:
FIG. 1 is a diagram that illustrates a database archival system in accordance with one or more embodiments.
FIG. 2 illustrates a database server creating a snapshot.
FIG. 3 illustrates a snapshot image in accordance with one or more embodiments.
FIG. 4 illustrates a media server and a storage device with stored database backup files in accordance with one or more embodiments.
FIG. 5 illustrates one embodiment of stored full backup files being converted into incremental backup files.
FIG. 6 illustrates one embodiment of a database archival system.
FIG. 7 illustrates one embodiment of an unmounted database file reconstructed from a full backup file and an incremental backup file.
FIG. 8 is a generalized flow diagram illustrating one embodiment of an incremental backup operation.
FIG. 9 is a generalized flow diagram illustrating one embodiment of a restore operation following from an incremental backup.
DETAILED DESCRIPTION
In the following description, numerous specific details are set forth to provide a thorough understanding of the methods and mechanisms presented herein. However, one having ordinary skill in the art should recognize that the various embodiments may be practiced without these specific details. In some instances, well-known structures, components, signals, computer program instructions, and techniques have not been shown in detail to avoid obscuring the approaches described herein. It will be appreciated that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements.
Referring to FIG. 1, a generalized block diagram of one embodiment of a database archival system is shown. Database server 110 and media server 130 are connected to network 120. In one embodiment, database server 110 may be a Microsoft SQL Server. In some embodiments, database server 110 may also be connected to an applications server (not shown), such as a Microsoft® SharePoint® server.
Network 120 may comprise a variety of network connections including combinations of local area networks (LANs), such as Ethernet networks and Fibre Channel (FC) networks, and wireless local area networks (WLANs) based on the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (Wi-Fi), and wide area networks (WANs), such as the Internet, cellular data networks, and other data communication networks such as a virtual private network (VPN) implemented over a public network (e.g., the Internet). Other network connections and architectures are possible and contemplated.
Media server 130 may manage backup storage device 140, and media server 130 may store backup data and metadata received from database server 110 in backup storage device 140. Media server 130 may host software to perform tasks associated with backing up and restoring data to database server 110. Media server 130 is representative of any number of media servers, master servers, or other types of servers which may be connected to network 120. In other embodiments, media server 130 may be a master server, other type of server, or some combination of one or more servers in a database archival system.
Media server 130 may be directly connected to backup storage device 140 or media server 130 may be connected to backup storage device 140 over any of a variety of networks, such as a LAN, storage area network (SAN), or other network. In one embodiment, backup storage device 140 may be an adapter card directly attached to a bus of media server 130. Media server 130 may use internal memory (e.g., random-access memory (RAM)) for buffering data when receiving and sending data to and from database server 110, backup storage device 140, or other devices. Backup storage device 140 is representative of any number of backup storage devices, and may comprise any of a variety of types of storage media, such as a hard disk drive, disk volume, server blade, flash drive, optical drive, tape drive, tape volume, robotic tape library, or other storage medium.
Database 150 may represent both a database program and/or one or more actual databases implemented therein. The database program refers to the executable commands, user interfaces and other program code for operating the database. The included databases may further comprise various tables, indexes, relationships, queries, stored procedures, file systems, security layers, networking interfaces, etc., which are configured to operate on a plurality of data records.
The records in database 150 may be arranged in tables (row and column arrangement). The term “record” as used herein shall refer to an entry in a database. A collection of associated records may be collectively described as a “table” in the database. A record may consist of one or more fields, which may serve as indexes (or keys) to other records in other tables. For example, in a document management database, each record in a document table may represent a document stored in the database. In one embodiment, the document may be stored in the fields of the record itself. In some embodiments, the document may be represented in a record by a reference to the document, such as a memory location. In addition, the database may create and modify a mounted database file for storing and accessing any given implementation of a relational database. In some embodiments, database 150 may execute on a dedicated computing system, such as database server 110, that is configured for access by other server and client computers via network 120.
Database 150 may include various kinds of functions associated with a relational database, such as add and query procedures. The query function may retrieve information from the database, such as a change map, allocation maps, objects, tables, records, and other data. The add function may store information in the database. Databases 150 may be a Microsoft SQL Server database and the interface used to provide access to database 150 may use SQL. Data may be stored and retrieved from database 150 at a page level. Each page may have a size of 8 kilobytes (KB) and may consist of a header and data. The page header may contain an object ID to which the data in the page belongs. Server input/output (I/O) operations may be performed at the page level, such that database server 110 reads or writes whole pages.
After a full backup process wherein a full backup of database 150 is generated, a subsequent incremental backup process may be employed to generate an incremental backup and capture only the extents that have changed since the most recent full backup. The generation of incremental backups may continue indefinitely, wherein a continuous number of subsequent incremental backups may be performed and created, wherein each incremental backup includes extents that have changed after the most recently performed incremental backup. The changed extents from the plurality of incremental backup operations may be stored in backup storage device 140.
For a restore operation, the most recently generated full backup may be restored in a process of writing the database file to a storage device, such as backup storage device 140, physical memory of database server 110, or other storage device. The changed extents stored in the first incremental backup file may then be distributed to the appropriate memory locations within the database file to re-instantiate the database file to the state that database 150 was at the time that the first incremental backup was initiated. This process may then be successively iterated for each of the incremental backups in an order in which the series of incremental backups were generated. At the end of the process, database server 110 may be notified that the database file has been reconstructed and is ready to be restored as a live instance of database 150.
Instead of restoring the entire database, a user or administrator may wish to restore one or more data items (e.g. files, emails, images) from the backed up database. Database server 110 may retrieve the one or more requested data items from the recovered database file and restore the items to database 150. The process of restoring one or more data items may be referred to as a granular restore process.
Media server 130 and database server 110 of FIG. 1 may be any type of computing device (e.g., server, desktop personal computer (PC), laptop, smartphone) and comprise various hardware and software components. The hardware components may include one or more processors, memory devices, and input/output (I/O) devices, connected together via a bus architecture. The software components may include an operating system stored in a memory device. The operating system may be any of various types of operating systems, such as Microsoft Windows®, Linux®, Solaris®, or others. The operating system may be operable to provide various services to the user and may support the execution of various programs such as backup applications, server applications, database applications, software agents, or any of a variety of other applications.
In other embodiments, the number and type of database servers, databases, media servers, networks, and backup storage devices is not limited to those shown in FIG. 1. Any number and combination of media servers, database servers, and databases may be interconnected in network architectures via various combinations of modem banks, direct LAN connections, wireless connections, WAN links, etc.
Referring now to FIG. 2, an illustration of a database server creating a snapshot image is shown. Database server 210 manages database 220, and database server 210 may be connected to storage device 230. Storage device 230 is representative of any number of storage devices, and storage device 230 may be any of the types of storage media previously described. Alternatively, database server 210 may use physical memory or other local storage to store snapshot 240 and other data related to database 220.
As shown in FIG. 2, snapshot 240 is stored in storage device 230. Snapshot 240 may be created by database server 210, and snapshot 240 may represent a backup image of database 220. Snapshot 240 may be a static, point-in-time representation of database 220. Snapshot 240 may be a copy of a full image of the entire database, and database server 210 may store snapshot 240 in storage device 230 after performing the snapshot backup. A media server (not shown) may access snapshot 240 to perform an incremental backup. Alternatively, a media server may access snapshot 240 to perform a full backup. Database server 210 may consider a snapshot backup as a full backup, and database server 210 may reset maps and other metadata to indicate that the snapshot backup was the equivalent of a full backup.
Referring now to FIG. 3, one embodiment of a snapshot image is shown. Snapshot 310 represents an image taken from a SQL database during a snapshot backup by a SQL server. Snapshot 310 may contain all of the data from the database, including metadata and one or more maps. The maps may include differential change map (DCM) 320, global allocation map (GAM) 330, shared global allocation map (SGAM) 340, index allocation map (IAM) 350, and objects 360. Objects 360 are representative of any number of objects which may exist in the underlying SQL database from which snapshot 310 was created. Objects 360 may be organized into extents, and objects 360 may be representative of any type of data stored in a database, including tables, records, documents, items, lists, and other data. In some embodiments, the SQL database may consist of one or more files, each with its own set of maps. In those embodiments, snapshot 310 may contain multiple DCM's, GAM's, SGAM's, IAM's, etc.
A media server may retrieve DCM 320 from snapshot 310. Then, the media server may read the pages of DCM 320 to determine which extents have been modified since a previous full or incremental backup. The media server may execute a query to retrieve the pages that make up the DCM from snapshot 310. The first DCM page may be located at the 7th page of snapshot 310. The second DCM page may be located 512232 pages offset from the first DCM page, at the 512239th page. The third page DCM page may be offset 1024464 pages from the first DCM page, at the 1022471th page, and so on.
The media server may also execute a query to retrieve one or more allocation maps from snapshot 310. The allocation maps may contain information about the extents that an object or index uses. For example, the allocation maps may contain bitmasks of extents indicating which extents are in use for that object. The one or more allocation maps may include GAM 330, SGAM 340, and IAM 350. These allocation maps may allow the media server to determine if the changed extents have been allocated. For example, an extent may have changed because its corresponding object was deleted. Therefore, the extent may not actually contain any data that needs to be backed up, even though DCM 320 may indicate that the extent has changed. By checking the allocation maps, the media server may reduce the number of extents that need to be stored as part of the incremental backup.
The media server may retrieve from snapshot 310 only the changed extents which have been allocated to an object. Then, the media server may store the retrieved extents in a storage device. The media server may also store metadata including one or more maps as part of the incremental backup. Alternatively, the media server could backup snapshot 310 in its entirety as part of a full backup. However, performing a full backup of snapshot 310 may take up a much larger amount of storage space than performing an incremental backup. After the changed extents and one or more maps are retrieved from snapshot 310 and stored in a backup storage device, snapshot 310 may be discarded. The above steps regarding snapshot 310 described as being performed by a media server may also be performed by a database server, other server, or other type of computing device.
Referring now to FIG. 4, one embodiment of a media server and a backup storage device with stored database backup files is shown. Media server 410 may store files associated with backups of a database in backup storage device 420. Full backup file 425 is stored in backup storage device 420, and full backup file 425 may contain data from a prior full database backup operation. In one embodiment, full backup file 425 may be a master data file (MDF). Media server 410 may also be configured to generate and store a schema of table and index information along with the backed up contents in the full backup file 425. The schema may refer to the data structure of a database file, and the schema may include memory locations that define certain data structures within the database file. The schema may be used to quickly and efficiently locate objects in full backup file 425, without having to perform extensive searching operations. The schema may be generated by querying a database when a full backup of the database is being created. The schema may be used to access or restore the contents of full backup file 425 without using the live database or the database server.
Incremental backup files 430 and 440 are also stored in backup storage device 420. Incremental backup files 430 and 440 may also be referred to as block level incremental files. Incremental backup files 430 and 440 contain the changed extents that are backed up as part of incremental backup operations of a database. Incremental backup files 430 and 440 are representative of any number of files associated with any number of incremental backup operations that may be performed. For example, if ten incremental backups are performed on a database connected to media server 410, then there may be ten incremental backup files stored in backup storage device 420.
In one embodiment, full backup file 425 and/or incremental backup files 430 and 440 may be binary files that are sequentially accessed, using standard file I/O calls to the file system of backup storage device 420. The file system may be an information system which references and stores data, hierarchically organized in files and directories, in a volume created on backup storage device 420. In some embodiments, full backup file 425 and/or incremental backup files 430 and 440 may be structured in block units of memory, also referred to as pages or allocation units.
Metadata 435 and 445 are also stored in backup storage device 420, and metadata 435 corresponds to incremental backup file 430 and metadata 445 corresponds to incremental backup file 440. Metadata 435 includes additional data, such as one or more maps, that may be stored in backup storage device 420 as part of the incremental backup operation associated with incremental backup file 430. The one or more maps may include a DCM, GAM, SGAM, IAM, and other maps. Additional information may also be stored in metadata 435 relating to incremental backup file 430. Metadata 435 may be used to facilitate restore operations for one or more data items from incremental backup file 430. In another embodiment, there may be one metadata store in backup storage device 420 containing metadata associated with multiple incremental backup operations. In a further embodiment, metadata 435 may be stored within incremental backup file 430. The above described features of metadata 435 may also apply to metadata 445.
In one embodiment, when a new full database backup operation is performed, media server 410 may delete the old full database backup file from backup storage device 420. Media server 410 may also delete the old metadata and incremental backup files at that time. In another embodiment, media server 410 may retain one or more prior full database backup files, incremental backup files, and/or metadata files when a new full database backup operation is performed. Media server 410 may have a retention policy regarding metadata files, incremental backup files, and full database backup files that involves deleting older files to free up storage space in backup storage device 420.
In another embodiment, full backup file 425 may be converted into an incremental backup file (or a differential backup file) to reduce the storage utilization associated with full backup file 425. If full backup file 425 corresponds to a snapshot backup, then one or more maps that identify data which has changed as compared to an earlier backup may be retrieved from full backup file 425. Alternatively, the maps identifying the changed data (which may be identified as extents) may be stored separately from full backup file 425, and the maps may be retrieved from this separate file or location. After the maps have been retrieved and the changed data has been identified, the changed data may be retrieved from full backup file 425 and stored as an incremental backup file in backup storage device 420. Alternatively, a different algorithm may be used to convert full backup file 425 into an incremental backup file. After full backup file 425 has been converted into an incremental backup file, full backup file 425 may be discarded from backup storage device 420. An identification of the earlier backup to which the newly created incremental backup corresponds may also be stored.
For full backup file 425 to be compressed into a converted incremental backup file, a previous full backup file that was created prior to full backup file 425 may need to be stored in backup storage device 420. The previous full backup file may be referenced by (or otherwise associated with) the converted incremental backup file to facilitate any potential restore operations. A future restore operation may then utilize both the previous full backup file and the converted incremental backup file.
Referring now to FIG. 5, an illustration of system and method for compressing previously stored full backup files is shown. In the example, stored full backup files are converted into partial (e.g., incremental) backup files. Media server 510 is connected to backup storage device 520, and backup storage device 520 stores full backup files 530, 540, 550, and 560. Full backup files 530-560 are representative of any number of full backup files which may be stored in backup storage device 520.
Full backup files 530-560 may correspond to full backup operations that were performed earlier (e.g., consecutively) without any incremental or differential backup operations performed in between the full backup operations. The storage space used to store full backup files 530-560 may be reduced by compressing one or more of full backup files 530-560 into converted incremental backup files.
When converting previously created full backup files to partial backup files, an earlier stored full backup file may be used as an anchor, or starting point/reference, for the later full backup files which are to be converted. In the example shown in FIG. 5, full backup file 530 may be used as the anchor full backup file. The next stored full backup file following the anchor file (i.e., full backup file 540) may be compressed into a converted incremental backup file by reading one or more maps that identify the changed data, retrieving the changed data from full backup file 540, and storing the changed data as an incremental backup file (i.e., converted incremental backup file 545). After converted incremental backup file 545 has been created, full backup file 540 may be discarded. In other embodiments, different methods may be used to convert a full backup file into an incremental backup file. This process may continue by compressing full backup files 550 and 560 into converted incremental backup files 555 and 565, respectively. Then, full backup files 550 and 560 may be discarded. This process may result in a significant reduction in storage utilization for the stored backup files. The anchor full backup file (i.e., full backup file 530) and converted incremental backup files 545-565 may be moved to a cloud-based storage location, tape device, or left on backup storage device 520. A full or granular restore may be performed using full backup file 530 and one or more of converted incremental backup files 545-565.
Turning now to FIG. 6, one embodiment of a database archival system is shown. Database server 610 is connected to network 680 and database 630. Media server 670 is connected to network 680 and storage device 620. In another embodiment, storage device 620 may be directly connected to database server 610, and media server 670 may access storage device 620 over network 680. A user or administrator may request to restore the database to a specific point-in-time associated with a specific incremental backup. Alternatively, a user or administrator may request to restore one or more data items from a specific point-in-time. Media server 670 may store backups of database 630, and media server 670 may merge a full backup file with one or more incremental backup files as part of a restore operation of one or more data items.
Unmounted database file 660 contains full backup file 640 and incremental backup file 650. The term “unmounted database file” as used herein is meant to include a database that contains data for a content management application that is not currently activated on a live instance of the content management application. Full backup file 640 may correspond to the most recent full backup of database 630 that was performed prior to the point-in-time selected by the user. Full backup file 640 may contain all of the data from database 630 at the time the full backup operation was performed. Incremental backup file 650 may correspond to an incremental backup that occurred at the selected point-in-time. Incremental backup file 650 is representative of any number of incremental backups that may have been performed subsequent to the full backup operation corresponding to full backup file 640 and prior to the selected point-in-time.
Database server 610 may include a granular restore function to add specific objects or records from unmounted database file 660 to database 630. The granular restore function may also include a means for selecting one or more records or objects for restoration. In one embodiment, a user interface for selecting and restoring records or objects may be provided as part of a granular restore operation. Granular recovery may enable administrators or users to select only the records or objects needed from unmounted database file 660 without having to recover the entire file. In some embodiments, objects may be documents such as Microsoft Word®, Excel®, PowerPoint®, portable document format (PDF), video, audio files, and others. In other embodiments, objects may include sites, sub-sites, lists, and list items.
In one embodiment, objects may be restored from unmounted database file 660 to the working copy of database 630, or to another copy of database 630. In another embodiment, objects may be buffered in memory in database server 610 before being restored to the working copy of database 630. In a further embodiment, objects may be restored from unmounted database file 660 to a file system on a storage medium, database server 610, media server 670, other server, client, or other computing device. In a still further embodiment, objects may be restored to an internal portal application or other software application.
A user may perform differential and log backups as well as full and incremental backups. The differential and log backups may be intermixed with the full and incremental backups. The methods and mechanisms described herein may also be used to perform incremental backups and to restore the database to incremental backups, while also performing differential and log backups and restoring from differential and log backups. For example, a user may perform a full backup, an incremental backup, two differential backups, and then a log backup. A user may then wish to restore the database to its state as it existed following the log backup. The full backup file may be written to a storage device, and then the incremental backup file may be superimposed (i.e., logically merged) on the full backup file. Then the second differential backup file may be restored on top of the full plus incremental file. Finally, the log backup may be played back on the recovered database file. Other sequences of full, incremental, differential, and log backups may be performed in accordance with the methods and mechanisms described herein.
Referring now to FIG. 7, a block diagram of one embodiment of an unmounted database file reconstructed from a full backup file and an incremental backup file is shown. Unmounted database file 660, full backup file 640, and incremental backup file 650 correspond to the same files of FIG. 6. Full backup file 640 includes objects 711-719 that are representative of any number of stored database objects. Objects 711-719 may be representative of any type of data stored in a database, including tables, records, documents, items, lists, and other data. Incremental backup file 650 includes objects 722 and 729 which may be representative of any number of objects that have changed in between the time when full backup file 640 was created and the time when incremental backup file 650 was created. Objects 722 and 729 correspond to changed extents that were collected in the incremental backup operation that created incremental backup file 650. Also, the objects displayed in full backup file 640 and incremental backup file 650 may include metadata describing the objects.
FIG. 7 depicts one embodiment of a restore operation. A restore application may write objects 711 and 713-719 from full backup file 640 to unmounted database file 660 as objects 701 and 703-708, respectively. Then, the restore application may write objects 722 and 729 from incremental backup file 650 to unmounted database file 660 as objects 702 and 709. The restore application may use one or more allocation maps and/or other metadata stored with incremental backup file 650 to determine the appropriate location for writing objects 722 and 729 to unmounted database file 660. Objects 712 and 719 may be overwritten by objects 722 and 729, respectively. After objects 722 and 729 have been written from incremental backup file 650 to unmounted database file 660, the restore application may notify the SQL server that unmounted database file 660 has been reconstructed and is ready to be restored to the live copy of the database. The restore application may run on a database server, media server, or other computing device.
In another embodiment, the restore application may use full backup file 640 as the starting point for the restore application. The restore application may write the objects from incremental backup file 650 (and any additional incremental backup files corresponding to further incremental backup operations that were performed) to full backup file 640, with the changed objects overwriting the original objects. In a further embodiment, the restore application may write full backup file 640 and incremental backup file 650 back on top of the working copy of the database or to another copy of the database. In a still further embodiment, objects may be buffered in memory before being restored to the working copy of the database. In a still further embodiment, objects may be restored from full backup file 640 and differential backup file 650 to a file system on a storage medium, SQL server, media server, other server, or other computing device. In a still further embodiment, objects may be restored to an internal portal application or other software application.
The illustrations of unmounted database file 660, full backup file 640, and incremental backup file 650 in FIG. 7 are logical representations of these files. The actual structure and organization of these files may be different from how they appear in FIG. 7. For example, additional data may be appended to incremental backup file 650. If new objects are added to the database after full backup file 640 is created, metadata describing the new objects may be added to the end of incremental backup file 650. Also, if objects are deleted from the database after full backup file 640 is created, metadata describing the deleted objects may be appended to incremental backup file 650. The restore application may use the metadata to determine which objects to add and which objects to delete from unmounted database file 660.
The restore application may generate a plurality of unmounted database files corresponding to different point-in-time instances of the database. The restore application may generate a user interface for a user to access and select from the plurality of point-in-time database instances. The user may wish to restore one or more objects from a backup copy of the database from a specific point-in-time. Alternatively, the user may wish to restore the entire database from a specific point-in-time. The user interface presented by the restore application may display a plurality of backups for the user to select from when considering a restore operation. The point-in-time backups may be listed according to the date or time on which the backups were performed. Other methods of listing and organizing the point-in-time backups are possible and contemplated.
Referring now to FIG. 8, one embodiment of a method for performing an incremental backup of a database is shown. For purposes of discussion, the steps in this embodiment are shown in sequential order. It should be noted that in various embodiments of the method described below, one or more of the elements described may be performed concurrently, in a different order than shown, or may be omitted entirely. Other additional elements may also be performed as desired.
The method 800 starts in block 810, and then a request to perform a full backup of the database may be conveyed in block 820. The request may be made by a user or administrator and conveyed to a database server. Alternatively, the request may be made automatically by a database server, media server, or other computing device in accordance with a prearranged backup schedule. The database server may behave as though a full database backup is being performed even though only an incremental backup file may actually be performed. Next, a snapshot of the database may be taken in block 830. The snapshot may be performed by a database server. At some point after the snapshot of the database is taken, the database server may reset the live copy of the DCM bitmap as though a full backup operation were performed. Resetting the live copy of the DCM bitmap will clear all of the changed data/extent indicators from the bitmap and allow the database server to track only changes that occur after the snapshot has been taken.
After block 830, one or more maps may be retrieved from the snapshot (block 840). The maps may include a DCM, GAM, SGAM, IAM, and/or other maps. The maps may be read to determine which extents have changed subsequent to a prior backup (block 850). The maps may also be used to determine if the changed extents are allocated. The prior backup may have been a full backup, snapshot backup, or incremental backup.
After block 850, the changed extents may be retrieved from the snapshot (block 860). The one or more maps may be used to locate the changed extents within the snapshot. In one embodiment, only the changed extents that are allocated to objects may be retrieved. Next, the changed extents may be stored as an incremental backup file in a storage device (block 870). Also, the one or more maps and any additional metadata may also be stored in a storage device. Then, the snapshot may be discarded in block 880. After block 880, method 800 may end in block 890.
Turning now to FIG. 9, one embodiment of a method for performing a restore operation from an incremental backup is shown. For purposes of discussion, the steps in this embodiment are shown in sequential order. It should be noted that in various embodiments of the method described below, one or more of the elements described may be performed concurrently, in a different order than shown, or may be omitted entirely. Other additional elements may also be performed as desired.
The method 900 starts in block 910, and then a request to perform a restore operation from a backup version of the database may be detected in block 920. The restore operation may be requested by a user or administrator, and the restore operation may be requested based on a specific point-in-time of the database corresponding to a prior backup operation. The prior backup operation may have been a full, incremental, differential, or log backup of the database. Next, a prior full database backup file may be retrieved in block 930. The prior full database backup file may correspond to the most recent full backup operation of the database at or prior to the specific point-in-time requested by the user. Then, the prior full database backup file may be stored in a storage device (block 940). In one embodiment, the storage device may be a separate storage device from the backup storage device containing the full database backup file. In another embodiment, the storage device may be the same as the backup storage device containing the full database backup file. In a further embodiment, the storage device may be one or more storage devices attached to the database server associated with the live instance of the database.
After block 940, the changed extents corresponding to an incremental backup operation may be retrieved from a backup storage device (block 950). Also, one or more stored maps associated with the incremental backup operation may also be retrieved from the backup storage device. The one or more stored maps may include the DCM, GAM, SGAM, IAM, and/or other maps. Additional metadata associated with the changed extents may also be retrieved from the backup storage device. Next, the changed extents may be written to the appropriate locations within the prior full database backup file (block 960). The one or more maps may be used to determine the appropriate locations within the prior full database backup file. Then, the database server may be notified of the reconstructed database backup file (block 970). The database server may be notified that the reconstructed database file is ready to be restored. The database server may restore the entire reconstructed file, or the database server may restore one or more objects from the reconstructed file. After block 970, method 900 may end in block 980.
It is noted that the above-described embodiments may comprise software. In such an embodiment, program instructions and/or a database (both of which may be referred to as “instructions”) that represent the described systems and/or methods may be stored on a computer readable storage medium. Generally speaking, a computer readable storage medium may include any storage media accessible by a computer during use to provide instructions and/or data to the computer. For example, a computer readable storage medium may include storage media such as magnetic or optical media, e.g., disk (fixed or removable), tape, CD-ROM, DVD-ROM, CD-R, CD-RW, DVD-R, DVD-RW, or Blu-Ray. Storage media may further include volatile or non-volatile memory media such as RAM (e.g., synchronous dynamic RAM (SDRAM), double data rate (DDR, DDR2, DDR3, etc.) SDRAM, low-power DDR (LPDDR2, etc.) SDRAM, Rambus DRAM (RDRAM), static RAM (SRAM)), ROM, non-volatile memory (e.g. Flash memory) accessible via a peripheral interface such as the USB interface, etc. Storage media may include micro-electro-mechanical systems (MEMS), as well as storage media accessible via a communication medium such as a network and/or a wireless link.
In various embodiments, one or more portions of the methods and mechanisms described herein may form part of a cloud computing environment. In such embodiments, resources may be provided over the Internet as services according to one or more various models. Such models may include Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). In IaaS, computer infrastructure is delivered as a service. In such a case, the computing equipment is generally owned and operated by the service provider. In the PaaS model, software tools and underlying equipment used by developers to develop software solutions may be provided as a service and hosted by the service provider. SaaS typically includes a service provider licensing software as a service on demand. The service provider may host the software, or may deploy the software to a customer for a given period of time. Numerous combinations of the above models are possible and are contemplated.
Although several embodiments of approaches have been shown and described, it will be apparent to those of ordinary skill in the art that a number of changes, modifications, or alterations to the approaches as described may be made. Changes, modifications, and alterations should therefore be seen as within the scope of the methods and mechanisms described herein. It should also be emphasized that the above-described embodiments are only non-limiting examples of implementations.

Claims (14)

What is claimed is:
1. A method for performing an incremental backup of a database, the method comprising:
initiating the incremental backup by conveying a request to a database server to perform a full backup of the database;
in response to said request to perform the full backup:
retrieving one or more maps associated with the database, said one or more maps including an identification of data which has changed since a prior backup, wherein the one or more maps include a differential change map (DCM) comprising a bitmap which indicates all data that has changed since the prior backup;
resetting the DCM associated with the database as if a full backup were performed in response to said request such that the DCM indicates no changes have occurred since a most recent full backup;
retrieving the changed data;
storing the changed data as an incremental backup file in a storage device; and
storing said one or more maps in association with the incremental backup file;
wherein a schema of the database is automatically generated by querying the database when the prior backup is performed.
2. The method as recited in claim 1, further comprising taking a snapshot of the database, in response to the request to perform the full backup.
3. The method as recited in claim 1, wherein the one or more maps include a global allocation map (GAM) comprising information about data extents that have been allocated, a shared global allocation map (SGAM) comprising information about mixed extents that have at least one unused page, and/or an index allocation map (IAM) comprising information about extents that a table or index uses, and wherein prior to retrieving the changed data, the method further comprising:
reading the one or more maps to determine if the changed extents are allocated; and
retrieving the changed extents only if they are allocated.
4. The method as recited in claim 1, further comprising:
detecting a request corresponding to said incremental backup file to perform a restore operation;
identifying a full database backup file associated with the incremental backup file;
creating a restored database by performing a restore operation using the incremental backup file and the full database backup file associated with the incremental backup file; and
notifying a database server of the restored database.
5. The method as recited in claim 1, further comprising:
identifying a previously stored full backup;
retrieving a map associated with the previously stored full backup;
utilizing said map to identify particular data which has changed since a backup performed prior to the previously stored full backup;
storing the particular data as part of a compressed version of the previously stored full backup; and
discarding data of the previously stored full backup which has not changed since the backup performed prior to the previously stored full backup.
6. A computer readable storage medium comprising program instructions to perform an incremental backup of a database, wherein when executed the program instructions are configured to:
initiate the incremental backup by conveying a request to perform a full backup of the database;
in response to said request to perform the full backup:
retrieve one or more maps associated with the database, said one or more maps including an identification of data which has changed since a prior backup, wherein the one or more maps include a differential change map (DCM) comprising a bitmap which indicates all data that has changed since the prior backup;
reset the DCM associated with the database as if a full backup were performed in response to said request such that the DCM indicates no changes have occurred since a most recent full backup;
retrieve the changed data;
store the changed data as an incremental backup file in a storage device; and
store said one or more maps in association with the incremental backup file;
wherein a schema of the database is automatically generated by querying the database when the prior backup is performed.
7. The computer readable storage medium as recited in claim 6, wherein the program instructions are further configured to take a snapshot of the database, in response to the request to perform the full backup.
8. The computer readable storage medium as recited in claim 6, wherein the one or more maps include a global allocation map (GAM) comprising information about data extents that have been allocated, a shared global allocation map (SGAM) comprising information about mixed extents that have at least one unused page, and/or an index allocation map (IAM) comprising information about extents that a table or index uses, and wherein prior to retrieving the changed data, the instructions are configured to:
read the one or more maps to determine if the changed extents are allocated; and
retrieve the changed extents only if they are allocated.
9. The computer readable storage medium as recited in claim 6, wherein the program instructions are further configured to:
detect a request corresponding to said incremental backup file to perform a restore operation;
identify a full database backup file associated with the incremental backup file;
create a restored database by performing a restore operation using the incremental backup file and the full database backup file associated with the incremental backup file; and
notify a database server of the restored database.
10. The computer readable storage medium as recited in claim 9, wherein the program instructions are further configured to:
identify a previously stored full backup;
retrieve a map associated with the previously stored full backup;
utilize said map to identify particular data which has changed since a backup performed prior to the previously stored full backup;
store the particular data as part of a compressed version of the previously stored full backup; and
discard data of the previously stored full backup which has not changed since the backup performed prior to the previously stored full backup.
11. A system for performing an incremental backup of a database, the system comprising:
a database server;
a media server;
a database; and
one or more storage devices;
wherein in response to a request to perform a full backup, the database server is configured to:
initiate the incremental backup using a request to initiate a full backup; and
wherein the media server is configured to:
retrieve one or more maps associated with the database, said one or more maps including an identification of data which has changed since a prior backup, wherein the one or more maps include a differential change map (DCM) comprising a bitmap which indicates all data that has changed since the prior backup;
reset the DCM associated with the database as if a full backup were performed in response to said request such that the DCM indicates no changes have occurred since a most recent full backup;
retrieve the changed data;
store the changed data as an incremental backup file in a storage device; and
store said one or more maps in association with the incremental backup file;
wherein a schema of the database is automatically generated by querying the database when the prior backup is performed.
12. The system as recited in claim 11, wherein the system is configured to take a snapshot of the database, in response to the request to perform the full backup.
13. The system as recited in claim 11, wherein the one or more maps include a global allocation map (GAM) comprising information about data extents that have been allocated, a shared global allocation map (SGAM) comprising information about mixed extents that have at least one unused page, and/or an index allocation map (IAM) comprising information about extents that a table or index uses, and wherein prior to retrieving the changed data, the system is configured to:
read the one or more maps to determine if the changed extents are allocated; and
retrieve the changed extents only if they are allocated.
14. The system as recited in claim 11, wherein the media server is further configured to:
detect a request corresponding to said incremental backup file to perform a restore operation;
identify a full database backup file associated with the incremental backup file;
create a restored database by performing a restore operation using the incremental backup file and the full database backup file associated with the incremental backup file; and
notify a database server of the restored database.
US12/986,666 2011-01-07 2011-01-07 Method and system of performing incremental SQL server database backups Active US8635187B2 (en)

Priority Applications (5)

Application Number Priority Date Filing Date Title
US12/986,666 US8635187B2 (en) 2011-01-07 2011-01-07 Method and system of performing incremental SQL server database backups
JP2011289030A JP6495568B2 (en) 2011-01-07 2011-12-28 Method, computer readable storage medium and system for performing incremental SQL server database backup
EP20120150113 EP2474909A3 (en) 2011-01-07 2012-01-03 Method and system of performing incremental SQL server database backups
CN201210003647.0A CN102591982B (en) 2011-01-07 2012-01-06 Perform the method and system of increment SQL server database backup
US14/159,235 US9703640B2 (en) 2011-01-07 2014-01-20 Method and system of performing incremental SQL server database backups

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US12/986,666 US8635187B2 (en) 2011-01-07 2011-01-07 Method and system of performing incremental SQL server database backups

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/159,235 Continuation US9703640B2 (en) 2011-01-07 2014-01-20 Method and system of performing incremental SQL server database backups

Publications (2)

Publication Number Publication Date
US20120179655A1 US20120179655A1 (en) 2012-07-12
US8635187B2 true US8635187B2 (en) 2014-01-21

Family

ID=45557852

Family Applications (2)

Application Number Title Priority Date Filing Date
US12/986,666 Active US8635187B2 (en) 2011-01-07 2011-01-07 Method and system of performing incremental SQL server database backups
US14/159,235 Active US9703640B2 (en) 2011-01-07 2014-01-20 Method and system of performing incremental SQL server database backups

Family Applications After (1)

Application Number Title Priority Date Filing Date
US14/159,235 Active US9703640B2 (en) 2011-01-07 2014-01-20 Method and system of performing incremental SQL server database backups

Country Status (4)

Country Link
US (2) US8635187B2 (en)
EP (1) EP2474909A3 (en)
JP (1) JP6495568B2 (en)
CN (1) CN102591982B (en)

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140258241A1 (en) * 2013-03-08 2014-09-11 Oracle International Corporation Zero and near-zero data loss database backup and recovery
US9703640B2 (en) 2011-01-07 2017-07-11 Veritas Technologies Llc Method and system of performing incremental SQL server database backups
US9977716B1 (en) 2015-06-29 2018-05-22 Veritas Technologies Llc Incremental backup system
US10146631B1 (en) * 2015-09-30 2018-12-04 EMC IP Holding Company LLC Incremental forever backups for exchange
US10318386B1 (en) * 2014-02-10 2019-06-11 Veritas Technologies Llc Systems and methods for maintaining remote backups of reverse-incremental backup datasets
US10423493B1 (en) 2015-12-21 2019-09-24 Amazon Technologies, Inc. Scalable log-based continuous data protection for distributed databases
US10503604B2 (en) 2014-06-26 2019-12-10 Hewlett Packard Enterprise Development Lp Virtual machine data protection
US10567500B1 (en) 2015-12-21 2020-02-18 Amazon Technologies, Inc. Continuous backup of data in a distributed data store
US10621049B1 (en) 2018-03-12 2020-04-14 Amazon Technologies, Inc. Consistent backups based on local node clock
US10754844B1 (en) 2017-09-27 2020-08-25 Amazon Technologies, Inc. Efficient database snapshot generation
US10831614B2 (en) 2014-08-18 2020-11-10 Amazon Technologies, Inc. Visualizing restoration operation granularity for a database
US10990581B1 (en) 2017-09-27 2021-04-27 Amazon Technologies, Inc. Tracking a size of a database change log
US11042454B1 (en) 2018-11-20 2021-06-22 Amazon Technologies, Inc. Restoration of a data source
US11042503B1 (en) 2017-11-22 2021-06-22 Amazon Technologies, Inc. Continuous data protection and restoration
US11126505B1 (en) 2018-08-10 2021-09-21 Amazon Technologies, Inc. Past-state backup generator and interface for database systems
US11182372B1 (en) 2017-11-08 2021-11-23 Amazon Technologies, Inc. Tracking database partition change log dependencies
US11269731B1 (en) 2017-11-22 2022-03-08 Amazon Technologies, Inc. Continuous data protection
US20220083426A1 (en) * 2020-09-15 2022-03-17 EMC IP Holding Company LLC Method and system for hybrid incremental file-based backups
US11385969B2 (en) 2009-03-31 2022-07-12 Amazon Technologies, Inc. Cloning and recovery of data volumes
US11755415B2 (en) 2014-05-09 2023-09-12 Amazon Technologies, Inc. Variable data replication for storage implementing data backup

Families Citing this family (73)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9705730B1 (en) 2013-05-07 2017-07-11 Axcient, Inc. Cloud storage using Merkle trees
US8924360B1 (en) 2010-09-30 2014-12-30 Axcient, Inc. Systems and methods for restoring a file
US8954544B2 (en) 2010-09-30 2015-02-10 Axcient, Inc. Cloud-based virtual machines and offices
US9235474B1 (en) * 2011-02-17 2016-01-12 Axcient, Inc. Systems and methods for maintaining a virtual failover volume of a target computing system
US8589350B1 (en) 2012-04-02 2013-11-19 Axcient, Inc. Systems, methods, and media for synthesizing views of file system backups
US10284437B2 (en) 2010-09-30 2019-05-07 Efolder, Inc. Cloud-based virtual machines and offices
CN102841897B (en) * 2011-06-23 2016-03-02 阿里巴巴集团控股有限公司 A kind of method, Apparatus and system realizing incremental data and extract
US8849878B1 (en) * 2011-09-30 2014-09-30 Emc Corporation Efficient data rehydration
CN103678396B (en) * 2012-09-20 2017-06-13 阿里巴巴集团控股有限公司 A kind of data back up method and device based on data model
WO2014052333A1 (en) * 2012-09-28 2014-04-03 Emc Corporation System and method for full virtual machine backup using storage system functionality
US9817834B1 (en) * 2012-10-01 2017-11-14 Veritas Technologies Llc Techniques for performing an incremental backup
US9785647B1 (en) 2012-10-02 2017-10-10 Axcient, Inc. File system virtualization
US9852140B1 (en) 2012-11-07 2017-12-26 Axcient, Inc. Efficient file replication
US9449039B2 (en) 2012-11-26 2016-09-20 Amazon Technologies, Inc. Automatic repair of corrupted blocks in a database
GB2508659A (en) 2012-12-10 2014-06-11 Ibm Backing up an in-memory database
CN103064763B (en) * 2012-12-27 2015-12-02 华为技术有限公司 A kind of data back up method and relevant device, system
GB2509930A (en) * 2013-01-17 2014-07-23 Ibm Data backup recovery
US9292153B1 (en) 2013-03-07 2016-03-22 Axcient, Inc. Systems and methods for providing efficient and focused visualization of data
US9397907B1 (en) 2013-03-07 2016-07-19 Axcient, Inc. Protection status determinations for computing devices
CN103345435B (en) * 2013-06-28 2015-04-22 环境保护部华南环境科学研究所 Destination sever system for data backup
US9772907B2 (en) * 2013-09-13 2017-09-26 Vmware, Inc. Incremental backups using retired snapshots
CN103617161A (en) * 2013-09-26 2014-03-05 金蝶软件(中国)有限公司 Data storing method and device for SAAS mode
US11194667B2 (en) 2014-02-07 2021-12-07 International Business Machines Corporation Creating a restore copy from a copy of a full copy of source data in a repository that is at a different point-in-time than a restore point-in-time of a restore request
US10372546B2 (en) 2014-02-07 2019-08-06 International Business Machines Corporation Creating a restore copy from a copy of source data in a repository having source data at different point-in-times
US11169958B2 (en) 2014-02-07 2021-11-09 International Business Machines Corporation Using a repository having a full copy of source data and point-in-time information from point-in-time copies of the source data to restore the source data at different points-in-time
US10387446B2 (en) 2014-04-28 2019-08-20 International Business Machines Corporation Merging multiple point-in-time copies into a merged point-in-time copy
US9367402B1 (en) * 2014-05-30 2016-06-14 Emc Corporation Coexistence of block based backup (BBB) products
CN104182302A (en) * 2014-09-15 2014-12-03 北京国双科技有限公司 Database backup method and device
US9766985B1 (en) 2014-10-09 2017-09-19 EMC IP Holding Company LLC Deviceless brokerless backup
US20160140191A1 (en) * 2014-11-19 2016-05-19 Datos IO Inc. Method and apparatus for the storage and retrieval of time stamped blocks of data
CN104503865B (en) * 2014-12-10 2017-09-29 杭州斯凯网络科技有限公司 The method that PostgreSQL quickly recovers to random time point
JP6281511B2 (en) * 2015-03-24 2018-02-21 日本電気株式会社 BACKUP CONTROL DEVICE, BACKUP CONTROL METHOD, AND PROGRAM
US10078555B1 (en) * 2015-04-14 2018-09-18 EMC IP Holding Company LLC Synthetic full backups for incremental file backups
US9996429B1 (en) 2015-04-14 2018-06-12 EMC IP Holding Company LLC Mountable container backups for files
US9946603B1 (en) 2015-04-14 2018-04-17 EMC IP Holding Company LLC Mountable container for incremental file backups
US10140189B2 (en) 2015-04-28 2018-11-27 International Business Machines Corporation Database recovery and index rebuilds
CN104866391B (en) * 2015-05-13 2019-08-02 三星电子(中国)研发中心 A kind of end message backup method and device based on increment information system
US9940203B1 (en) * 2015-06-11 2018-04-10 EMC IP Holding Company LLC Unified interface for cloud-based backup and restoration
US10394661B2 (en) * 2015-09-22 2019-08-27 International Business Machines Corporation Policy driven data updates
KR101658741B1 (en) * 2015-11-23 2016-09-21 (주)클로닉스 Mixing back up and restoration device using incremental back up and differential back up of computer system and method for controlling the same
US10511456B2 (en) 2016-06-12 2019-12-17 Apple Inc. Presenting accessory group controls
US10498552B2 (en) 2016-06-12 2019-12-03 Apple Inc. Presenting accessory state
US11003147B2 (en) 2016-06-12 2021-05-11 Apple Inc. Automatically grouping accessories
CN106126371A (en) * 2016-06-15 2016-11-16 腾讯科技(深圳)有限公司 Data return a grade method, Apparatus and system
CN106126370A (en) * 2016-06-15 2016-11-16 上海爱数信息技术股份有限公司 Based on the Server free backup method and the system that store increment bitmap between snapshot
US9558077B1 (en) * 2016-06-16 2017-01-31 International Business Machines Corporation Relational database recovery
CN106095622A (en) * 2016-06-22 2016-11-09 上海爱数信息技术股份有限公司 Data back up method and device
CN109933461A (en) * 2016-06-28 2019-06-25 华为技术有限公司 A kind of method and apparatus of data processing
US10572530B2 (en) 2016-07-03 2020-02-25 Apple Inc. Prefetching accessory data
US10168925B2 (en) * 2016-08-18 2019-01-01 International Business Machines Corporation Generating point-in-time copy commands for extents of data
US10235099B2 (en) 2016-08-18 2019-03-19 International Business Machines Corporation Managing point-in-time copies for extents of data
US10469281B2 (en) 2016-09-24 2019-11-05 Apple Inc. Generating suggestions for scenes and triggers by resident device
CN107957918B (en) * 2016-10-14 2019-05-10 腾讯科技(深圳)有限公司 Data reconstruction method and device
US10884875B2 (en) * 2016-12-15 2021-01-05 Palantir Technologies Inc. Incremental backup of computer data files
CN110347514B (en) * 2017-01-20 2021-03-16 腾讯科技(深圳)有限公司 Event processing method and device
CN107544870A (en) * 2017-06-14 2018-01-05 新华三云计算技术有限公司 A kind of disk backup method of virtue machine and device
US10713238B2 (en) * 2017-11-14 2020-07-14 Snowflake Inc. Database metadata in immutable storage
CN109995808A (en) * 2017-12-29 2019-07-09 上海共联通信信息发展有限公司 A kind of enterprise data storage system
US11288251B2 (en) * 2018-05-25 2022-03-29 Microsoft Technology Licensing, Llc Supporting concurrent updates to a database page
US11221983B1 (en) * 2018-08-29 2022-01-11 EMC IP Holding Company LLC Multi-level indexing of backup files
CN110209528B (en) * 2018-11-30 2022-10-28 腾讯科技(深圳)有限公司 Data backup method, device, server and storage medium
CN109815060A (en) * 2019-01-30 2019-05-28 北京百度网讯科技有限公司 Method and device for backup information
US11561999B2 (en) * 2019-01-31 2023-01-24 Rubrik, Inc. Database recovery time objective optimization with synthetic snapshots
CN111143323B (en) * 2019-12-02 2022-04-08 新华三大数据技术有限公司 MPP database management method, device and system
CN111708660B (en) * 2020-06-17 2023-09-15 山东山大电力技术股份有限公司 Backup system, recovery system and method based on container sandbox
US11561722B2 (en) 2020-08-25 2023-01-24 Micron Technology, Inc. Multi-page parity data storage in a memory device
CN114647659A (en) * 2020-12-17 2022-06-21 金篆信科有限责任公司 Data processing method and device, electronic equipment and storage medium
CN113032181A (en) * 2021-02-26 2021-06-25 上海爱数信息技术股份有限公司 Single-user mailbox backup and recovery system and method thereof
CN113641694B (en) * 2021-07-16 2023-12-22 南京国电南自维美德自动化有限公司 Database massive historical data backup method and database massive historical data recovery method
CN113282573B (en) * 2021-07-22 2021-09-17 成都云祺科技有限公司 Database recovery method, system and storage medium based on IAM page
CN113742140B (en) * 2021-11-03 2022-03-18 统信软件技术有限公司 File backup method and device and computing equipment
US20230153327A1 (en) * 2021-11-17 2023-05-18 International Business Machines Corporation Loading data in a target database system using different synchronization programs
CN115292094B (en) * 2022-08-10 2023-11-14 广州鼎甲计算机科技有限公司 Data recovery processing method, device, equipment, storage medium and program product

Citations (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6085298A (en) * 1994-10-13 2000-07-04 Vinca Corporation Comparing mass storage devices through digests that are representative of stored data in order to minimize data transfer
US6101585A (en) 1997-11-04 2000-08-08 Adaptec, Inc. Mechanism for incremental backup of on-line files
US6249792B1 (en) * 1998-12-16 2001-06-19 Microsoft Corporation On-line dynamic file shrink facility
US6460054B1 (en) * 1999-12-16 2002-10-01 Adaptec, Inc. System and method for data storage archive bit update after snapshot backup
US6665815B1 (en) 2000-06-22 2003-12-16 Hewlett-Packard Development Company, L.P. Physical incremental backup using snapshots
WO2004034197A2 (en) 2002-10-07 2004-04-22 Commvault Systems, Inc. System and method for managing stored data
US6829688B2 (en) 2002-06-20 2004-12-07 International Business Machines Corporation File system backup in a logical volume management data storage environment
US20040268068A1 (en) 2003-06-24 2004-12-30 International Business Machines Corporation Efficient method for copying and creating block-level incremental backups of large files and sparse files
US6847983B2 (en) 2001-02-28 2005-01-25 Kiran Somalwar Application independent write monitoring method for fast backup and synchronization of open files
US6880051B2 (en) 2002-03-14 2005-04-12 International Business Machines Corporation Method, system, and program for maintaining backup copies of files in a backup storage device
US6981177B2 (en) 2002-04-19 2005-12-27 Computer Associates Think, Inc. Method and system for disaster recovery
US20060075294A1 (en) * 2004-09-22 2006-04-06 International Business Machines Coproration System and Method for Reliably Storing Data and Providing Efficient Incremental Backup and Asynchronous Mirroring by Preferentially Handling New Data
US20060161802A1 (en) 2005-01-14 2006-07-20 Farstone Tech, Inc. Backup/recovery system and methods regarding the same
US20060218204A1 (en) 2005-03-25 2006-09-28 International Business Machines Corporation Log stream validation in log shipping data replication systems
US20060242211A1 (en) 2002-07-15 2006-10-26 Becker Gregory A System and method for backing up a computer system
US20070174325A1 (en) 2006-01-24 2007-07-26 International Business Machines Corporation Method and system for building a database from backup data images
US7310654B2 (en) 2002-01-31 2007-12-18 Mirapoint, Inc. Method and system for providing image incremental and disaster recovery
US20080244204A1 (en) 2007-03-29 2008-10-02 Nick Cremelie Replication and restoration of single-instance storage pools
US20080263109A1 (en) 2007-04-19 2008-10-23 Data Domain, Inc. Seeding replication
US20100005259A1 (en) * 2008-07-03 2010-01-07 Anand Prahlad Continuous data protection over intermittent connections, such as continuous data backup for laptops or wireless devices
US20100023716A1 (en) 2008-07-23 2010-01-28 Jun Nemoto Storage controller and storage control method
US20100049930A1 (en) * 2008-08-25 2010-02-25 Vmware, Inc. Managing Backups Using Virtual Machines
US20100058010A1 (en) 2008-09-04 2010-03-04 Oliver Augenstein Incremental backup using snapshot delta views
US20100077165A1 (en) * 2008-08-25 2010-03-25 Vmware, Inc. Tracking Block-Level Changes Using Snapshots
US20100122324A1 (en) 2006-11-15 2010-05-13 Palm, Inc. Over the air services for mobile devices
US7814056B2 (en) * 2004-05-21 2010-10-12 Computer Associates Think, Inc. Method and apparatus for data backup using data blocks
US20110004586A1 (en) * 2009-07-15 2011-01-06 Lon Jones Cherryholmes System, method, and computer program product for creating a virtual database
US8005797B1 (en) * 2008-04-01 2011-08-23 Acronis Inc. File-level continuous data protection with access to previous versions

Family Cites Families (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5212784A (en) 1990-10-22 1993-05-18 Delphi Data, A Division Of Sparks Industries, Inc. Automated concurrent data backup system
JP3260923B2 (en) 1993-09-20 2002-02-25 富士通株式会社 Backup control apparatus and method for data processing system
JPH09244933A (en) * 1996-03-05 1997-09-19 Nippon Telegr & Teleph Corp <Ntt> Method and device for backing up data base
US6397307B2 (en) 1999-02-23 2002-05-28 Legato Systems, Inc. Method and system for mirroring and archiving mass storage
US6714952B2 (en) 1999-11-10 2004-03-30 Emc Corporation Method for backup and restore of a multi-lingual network file server
US6460055B1 (en) 1999-12-16 2002-10-01 Livevault Corporation Systems and methods for backing up data files
US7072896B2 (en) * 2000-02-16 2006-07-04 Verizon Laboratories Inc. System and method for automatic loading of an XML document defined by a document-type definition into a relational database including the generation of a relational schema therefor
US7266574B1 (en) 2001-12-31 2007-09-04 Emc Corporation Identification of updated files for incremental backup
US6938135B1 (en) 2002-10-04 2005-08-30 Veritas Operating Corporation Incremental backup of a data volume
US7062496B2 (en) * 2003-02-12 2006-06-13 International Business Machines Corporation Automatic data abstraction generation using database schema and related objects
US7743022B2 (en) 2003-02-28 2010-06-22 Microsoft Corporation Method and system for synchronizing data shared among peer computing devices
US7694086B1 (en) 2003-06-30 2010-04-06 Symantec Operating Corporation Method and system for incremental backup of data volumes
US7284104B1 (en) 2003-06-30 2007-10-16 Veritas Operating Corporation Volume-based incremental backup and recovery of files
EP1654659A4 (en) 2003-08-05 2007-05-09 Sepaton Inc Emulated storage system
US7315923B2 (en) 2003-11-13 2008-01-01 Commvault Systems, Inc. System and method for combining data streams in pipelined storage operations in a storage network
WO2005050381A2 (en) 2003-11-13 2005-06-02 Commvault Systems, Inc. Systems and methods for performing storage operations using network attached storage
US7406464B2 (en) * 2003-12-08 2008-07-29 Ebay Inc. Custom caching
US7103740B1 (en) 2003-12-31 2006-09-05 Veritas Operating Corporation Backup mechanism for a multi-class file system
US7251749B1 (en) 2004-02-12 2007-07-31 Network Appliance, Inc. Efficient true image recovery of data from full, differential, and incremental backups
US7197520B1 (en) 2004-04-14 2007-03-27 Veritas Operating Corporation Two-tier backup mechanism
US7266655B1 (en) 2004-04-29 2007-09-04 Veritas Operating Corporation Synthesized backup set catalog
US7536424B2 (en) 2004-05-02 2009-05-19 Yoram Barzilai System and methods for efficiently managing incremental data backup revisions
US7756833B2 (en) 2004-09-22 2010-07-13 Microsoft Corporation Method and system for synthetic backup and restore
US7725438B1 (en) 2005-01-31 2010-05-25 Veritas Operating Corporation Method and apparatus for efficiently creating backup files
US8918366B2 (en) 2005-02-07 2014-12-23 Mimosa Systems, Inc. Synthetic full copies of data and dynamic bulk-to-brick transformation
CN101243413B (en) * 2005-06-24 2013-08-14 信科索尔特公司 System and method for virtualizing backup images
US7465154B2 (en) 2006-04-18 2008-12-16 United Technologies Corporation Gas turbine engine component suction side trailing edge cooling scheme
US7519858B2 (en) 2006-08-18 2009-04-14 Computer Associates Think, Inc. Selective file restoration from incremental backups
JP2008059443A (en) * 2006-09-01 2008-03-13 Hitachi Ltd Storage system and backup method
JP4900811B2 (en) * 2007-03-30 2012-03-21 株式会社日立製作所 Storage system and storage control method
EP1990740A1 (en) * 2007-05-08 2008-11-12 Sap Ag Schema matching for data migration
US7949635B1 (en) 2007-10-26 2011-05-24 Acronis Inc. Backup server architecture
US8112397B2 (en) 2007-12-26 2012-02-07 Symantec Operating Corporation Automatically adjusting a number of backup data sources concurrently backed up to a storage device on a server computer
US8244681B2 (en) 2008-06-09 2012-08-14 Symantec Operating Corporation Creating synthetic backup images on a remote computer system
US9558075B2 (en) 2009-11-24 2017-01-31 Veritas Technologies Llc Synthetic full backup generation
US8700682B2 (en) * 2009-12-24 2014-04-15 Vertafore, Inc. Systems, methods and articles for template based generation of markup documents to access back office systems
US8984031B1 (en) * 2010-09-29 2015-03-17 Emc Corporation Managing data storage for databases based on application awareness
US8635187B2 (en) 2011-01-07 2014-01-21 Symantec Corporation Method and system of performing incremental SQL server database backups

Patent Citations (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6085298A (en) * 1994-10-13 2000-07-04 Vinca Corporation Comparing mass storage devices through digests that are representative of stored data in order to minimize data transfer
US6101585A (en) 1997-11-04 2000-08-08 Adaptec, Inc. Mechanism for incremental backup of on-line files
US6249792B1 (en) * 1998-12-16 2001-06-19 Microsoft Corporation On-line dynamic file shrink facility
US6460054B1 (en) * 1999-12-16 2002-10-01 Adaptec, Inc. System and method for data storage archive bit update after snapshot backup
US6665815B1 (en) 2000-06-22 2003-12-16 Hewlett-Packard Development Company, L.P. Physical incremental backup using snapshots
US6847983B2 (en) 2001-02-28 2005-01-25 Kiran Somalwar Application independent write monitoring method for fast backup and synchronization of open files
US7310654B2 (en) 2002-01-31 2007-12-18 Mirapoint, Inc. Method and system for providing image incremental and disaster recovery
US6880051B2 (en) 2002-03-14 2005-04-12 International Business Machines Corporation Method, system, and program for maintaining backup copies of files in a backup storage device
US6981177B2 (en) 2002-04-19 2005-12-27 Computer Associates Think, Inc. Method and system for disaster recovery
US6829688B2 (en) 2002-06-20 2004-12-07 International Business Machines Corporation File system backup in a logical volume management data storage environment
US20060242211A1 (en) 2002-07-15 2006-10-26 Becker Gregory A System and method for backing up a computer system
WO2004034197A2 (en) 2002-10-07 2004-04-22 Commvault Systems, Inc. System and method for managing stored data
US20040268068A1 (en) 2003-06-24 2004-12-30 International Business Machines Corporation Efficient method for copying and creating block-level incremental backups of large files and sparse files
US7814056B2 (en) * 2004-05-21 2010-10-12 Computer Associates Think, Inc. Method and apparatus for data backup using data blocks
US20060075294A1 (en) * 2004-09-22 2006-04-06 International Business Machines Coproration System and Method for Reliably Storing Data and Providing Efficient Incremental Backup and Asynchronous Mirroring by Preferentially Handling New Data
US20060161802A1 (en) 2005-01-14 2006-07-20 Farstone Tech, Inc. Backup/recovery system and methods regarding the same
US20060218204A1 (en) 2005-03-25 2006-09-28 International Business Machines Corporation Log stream validation in log shipping data replication systems
US20070174325A1 (en) 2006-01-24 2007-07-26 International Business Machines Corporation Method and system for building a database from backup data images
US20100122324A1 (en) 2006-11-15 2010-05-13 Palm, Inc. Over the air services for mobile devices
US20080244204A1 (en) 2007-03-29 2008-10-02 Nick Cremelie Replication and restoration of single-instance storage pools
US20080263109A1 (en) 2007-04-19 2008-10-23 Data Domain, Inc. Seeding replication
US8005797B1 (en) * 2008-04-01 2011-08-23 Acronis Inc. File-level continuous data protection with access to previous versions
US20100005259A1 (en) * 2008-07-03 2010-01-07 Anand Prahlad Continuous data protection over intermittent connections, such as continuous data backup for laptops or wireless devices
US20100023716A1 (en) 2008-07-23 2010-01-28 Jun Nemoto Storage controller and storage control method
US20100077165A1 (en) * 2008-08-25 2010-03-25 Vmware, Inc. Tracking Block-Level Changes Using Snapshots
US20100049930A1 (en) * 2008-08-25 2010-02-25 Vmware, Inc. Managing Backups Using Virtual Machines
US20100058010A1 (en) 2008-09-04 2010-03-04 Oliver Augenstein Incremental backup using snapshot delta views
US20110004586A1 (en) * 2009-07-15 2011-01-06 Lon Jones Cherryholmes System, method, and computer program product for creating a virtual database

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
European Search Report for Application No. 12150113.4-2224 mailed Jul. 5, 2012.

Cited By (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11914486B2 (en) 2009-03-31 2024-02-27 Amazon Technologies, Inc. Cloning and recovery of data volumes
US11385969B2 (en) 2009-03-31 2022-07-12 Amazon Technologies, Inc. Cloning and recovery of data volumes
US9703640B2 (en) 2011-01-07 2017-07-11 Veritas Technologies Llc Method and system of performing incremental SQL server database backups
US9563655B2 (en) * 2013-03-08 2017-02-07 Oracle International Corporation Zero and near-zero data loss database backup and recovery
US20140258241A1 (en) * 2013-03-08 2014-09-11 Oracle International Corporation Zero and near-zero data loss database backup and recovery
US10318386B1 (en) * 2014-02-10 2019-06-11 Veritas Technologies Llc Systems and methods for maintaining remote backups of reverse-incremental backup datasets
US11755415B2 (en) 2014-05-09 2023-09-12 Amazon Technologies, Inc. Variable data replication for storage implementing data backup
US10503604B2 (en) 2014-06-26 2019-12-10 Hewlett Packard Enterprise Development Lp Virtual machine data protection
US10831614B2 (en) 2014-08-18 2020-11-10 Amazon Technologies, Inc. Visualizing restoration operation granularity for a database
US9977716B1 (en) 2015-06-29 2018-05-22 Veritas Technologies Llc Incremental backup system
US10146631B1 (en) * 2015-09-30 2018-12-04 EMC IP Holding Company LLC Incremental forever backups for exchange
US10567500B1 (en) 2015-12-21 2020-02-18 Amazon Technologies, Inc. Continuous backup of data in a distributed data store
US10423493B1 (en) 2015-12-21 2019-09-24 Amazon Technologies, Inc. Scalable log-based continuous data protection for distributed databases
US11153380B2 (en) 2015-12-21 2021-10-19 Amazon Technologies, Inc. Continuous backup of data in a distributed data store
US10990581B1 (en) 2017-09-27 2021-04-27 Amazon Technologies, Inc. Tracking a size of a database change log
US10754844B1 (en) 2017-09-27 2020-08-25 Amazon Technologies, Inc. Efficient database snapshot generation
US11182372B1 (en) 2017-11-08 2021-11-23 Amazon Technologies, Inc. Tracking database partition change log dependencies
US11042503B1 (en) 2017-11-22 2021-06-22 Amazon Technologies, Inc. Continuous data protection and restoration
US11269731B1 (en) 2017-11-22 2022-03-08 Amazon Technologies, Inc. Continuous data protection
US11860741B2 (en) 2017-11-22 2024-01-02 Amazon Technologies, Inc. Continuous data protection
US10621049B1 (en) 2018-03-12 2020-04-14 Amazon Technologies, Inc. Consistent backups based on local node clock
US11126505B1 (en) 2018-08-10 2021-09-21 Amazon Technologies, Inc. Past-state backup generator and interface for database systems
US11579981B2 (en) 2018-08-10 2023-02-14 Amazon Technologies, Inc. Past-state backup generator and interface for database systems
US11042454B1 (en) 2018-11-20 2021-06-22 Amazon Technologies, Inc. Restoration of a data source
US20220083426A1 (en) * 2020-09-15 2022-03-17 EMC IP Holding Company LLC Method and system for hybrid incremental file-based backups

Also Published As

Publication number Publication date
EP2474909A3 (en) 2012-08-08
CN102591982A (en) 2012-07-18
US9703640B2 (en) 2017-07-11
JP2012146301A (en) 2012-08-02
JP6495568B2 (en) 2019-04-03
US20140136484A1 (en) 2014-05-15
CN102591982B (en) 2018-02-16
US20120179655A1 (en) 2012-07-12
EP2474909A2 (en) 2012-07-11

Similar Documents

Publication Publication Date Title
US9703640B2 (en) Method and system of performing incremental SQL server database backups
US9411821B1 (en) Block-based backups for sub-file modifications
US10705919B2 (en) Data backup using metadata mapping
US8856080B2 (en) Backup using metadata virtual hard drive and differential virtual hard drive
US9348827B1 (en) File-based snapshots for block-based backups
US10146631B1 (en) Incremental forever backups for exchange
US10146643B2 (en) Database recovery and index rebuilds
EP2622481B1 (en) Method and system of performing a granular restore of a database from a differential backup
CN105718548B (en) Based on the system and method in de-duplication storage system for expansible reference management
JP4807992B2 (en) Synthetic backup and restore methods and systems
JP5756394B2 (en) Computer program, system, and method for restoring a restore set of files from backup objects stored in a sequential backup device
US8433863B1 (en) Hybrid method for incremental backup of structured and unstructured files
EP2590078B1 (en) Shadow paging based log segment directory
US9424137B1 (en) Block-level backup of selected files
EP2488949A1 (en) De-duplication storage system with multiple indices for efficient file storage
US9558077B1 (en) Relational database recovery
US9223811B2 (en) Creation and expiration of backup objects in block-level incremental-forever backup systems
US9251020B1 (en) Systems and methods for file-level replication
US9575990B2 (en) Partitioning data within a distributed data storage system using virtual file links
US10795588B1 (en) Check point recovery based on identifying used blocks for block-based backup files
Gotseva et al. Database backup strategies and recovery models

Legal Events

Date Code Title Description
AS Assignment

Owner name: SYMANTEC CORPORATION, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BEATTY, LOUIS J.;PAYNE, MICHAEL A.;DEVOS, STEVEN R.;AND OTHERS;SIGNING DATES FROM 20110106 TO 20110107;REEL/FRAME:025611/0441

STCF Information on status: patent grant

Free format text: PATENTED CASE

AS Assignment

Owner name: VERITAS US IP HOLDINGS LLC, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SYMANTEC CORPORATION;REEL/FRAME:037697/0412

Effective date: 20160129

AS Assignment

Owner name: WILMINGTON TRUST, NATIONAL ASSOCIATION, AS COLLATERAL AGENT, CONNECTICUT

Free format text: SECURITY INTEREST;ASSIGNOR:VERITAS US IP HOLDINGS LLC;REEL/FRAME:037891/0726

Effective date: 20160129

Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTH CAROLINA

Free format text: SECURITY INTEREST;ASSIGNOR:VERITAS US IP HOLDINGS LLC;REEL/FRAME:037891/0001

Effective date: 20160129

Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTH

Free format text: SECURITY INTEREST;ASSIGNOR:VERITAS US IP HOLDINGS LLC;REEL/FRAME:037891/0001

Effective date: 20160129

Owner name: WILMINGTON TRUST, NATIONAL ASSOCIATION, AS COLLATE

Free format text: SECURITY INTEREST;ASSIGNOR:VERITAS US IP HOLDINGS LLC;REEL/FRAME:037891/0726

Effective date: 20160129

AS Assignment

Owner name: VERITAS TECHNOLOGIES LLC, CALIFORNIA

Free format text: MERGER AND CHANGE OF NAME;ASSIGNORS:VERITAS US IP HOLDINGS LLC;VERITAS TECHNOLOGIES LLC;REEL/FRAME:038455/0752

Effective date: 20160329

FPAY Fee payment

Year of fee payment: 4

AS Assignment

Owner name: WILMINGTON TRUST, NATIONAL ASSOCIATION, AS NOTES COLLATERAL AGENT, DELAWARE

Free format text: SECURITY INTEREST;ASSIGNOR:VERITAS TECHNOLOGIES LLC;REEL/FRAME:054370/0134

Effective date: 20200820

AS Assignment

Owner name: VERITAS US IP HOLDINGS, LLC, CALIFORNIA

Free format text: TERMINATION AND RELEASE OF SECURITY IN PATENTS AT R/F 037891/0726;ASSIGNOR:WILMINGTON TRUST, NATIONAL ASSOCIATION, AS COLLATERAL AGENT;REEL/FRAME:054535/0814

Effective date: 20201127

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8