WO2017023342A1

WO2017023342A1 - Backup changes in transaction log file

Info

Publication number: WO2017023342A1
Application number: PCT/US2015/055068
Authority: WO
Inventors: Veeresh Mallappa ANAMI; Mandar Nanivadekar
Original assignee: Hewlett Packard Enterprise Development Lp
Priority date: 2015-07-31
Filing date: 2015-10-12
Publication date: 2017-02-09

Abstract

Any blocks of a transaction log file of a client that have changed since a previous backup of the transaction log file of the client are retrieved. The transaction log file may include transactions performed on a database of the client. The changed blocks are backed up to a host. A framework of the client does not support backing up the transaction log file separately from a database data file of the volume. The host is to retrieve and/or backup the transaction log file separately from the database data file.

Description

BACKUP CHANGE IN TRANSACTION LOG FILE

BACKGROUND

[0001] Recovery models are designed to control transaction log maintenance. A recovery model may have a database property that controls how transactions are logged, whether the transaction log requires (and allows) backing up, what kinds of restore operations are available, etc. However, changes since the most recent backup are unprotected. In the event of a disaster, those changes will have to be redone.

BREF DESCRIPTION OF THE DRAWNGS

[0002] The following detailed description references the drawings, wherein:

[0003] FIG. 1 is an example block diagram of a device to backup a change in a transaction log file;

[0004] FIG. 2 is an example block diagram of a computing device including instructions for backing up a change in a transaction log file;

[0005] FIG. 3 is an example flowchart of a method for backing up a change in a transaction log file; and

[0006] FIG.4 is another example flowchart of a method for backing up a change in a transaction log file.

DETAILED DESCRIPTION

[0007] Specific details are given in the following description to provide a thorough understanding of embodiments. However, it will be understood that embodiments may be practiced without these specific details. For example, systems may be shown in block diagrams in order not to obscure embodiments in unnecessary detail. In other instances, well-known processes, structures and techniques may be shown without unnecessary detail in order to avoid obscuring embodiments.

[0008] In computer systems, a framework is often a layered structure indicating what kind of programs can or should be built and how they would interrelate. Some computer system frameworks also include actual programs, specify programming interfaces, or offer programming tools for using the frameworks. A framework may be for a set of functions within a system and how they interrelate; the layers of an operating system; the layers of an application subsystem; how communication should be standardized at some level of a network; and so forth.

[0009] For example, Microsoft Virtual Shadow Copy Services (VSS) is a framework provided by Microsoft to achieve application consistent backups of business applications like Microsoft SQL Server, Exchange Server, SharePoint, Active Directory etc. However, the VSS doesn't support backup and restore of transaction logs for some types of applications, like SQL, SharePoint etc. Due to this limitation, customers will need to carry out either full or differential database backups that involve backup of database data files (.mdf) or transaction log files (.Idf). These type of backups may be expensive operations in terms of storage space requirements, backup window period and point-in-time recovery as compared to transaction logs backup. [0010] Examples provide a method to perform transactional log backups without backing up the database data file. In one example, any blocks of a transaction log file of a client that have changed since a previous backup of the transaction log file of the client are retrieved. The transaction log file may include transactions performed on a database of the client. The changed blocks are backed up to a host. A framework of the client does not support backing up the transaction log file separately from a database data file of the volume. The host is to retrieve and/or backup the transaction log file separately from the database data file.

[0011 ] Thus, examples provide lesser work loss exposure, allows point-in-time recovery of database, and less data to be backed up as only changes in the transaction log are backed up as compared to full and differential backups (where both database and transaction log data backup is carried out).

[0012] Further, examples may improve the restore process due to instant access of backed up data and improve backup operation by offloading the tasks of providing transactional log data by a server as a snapshot of source volume is used for retrieving the transactional log data. Also, examples may be used with an existing framework, such as in conjunction with the VSS for applications that are already using VSS SQL writer for full and differential backups.

[0013] Referring now to the drawings, FIG. 1 is an example block diagram of a device 100 to backup a change in a transaction log file. The device 100 may include or be part of a microprocessor, a controller, a memory module or device, a notebook computer, a desktop computer, an all-in-one system, a server, a network device, a wireless device, and the like. [0014] The device 100 is shown to include a writer unit 110 and a request unit 120. The writer and request units 110 and 120 may include, for example, a hardware device including electronic circuitry for implementing the functionality described below, such as control logic and/or memory. In addition or as an alternative, the writer and request units 110 and 120 may be implemented as a series of instructions encoded on a machine-readable storage medium and executable by a processor.

[0015] The request unit 120 may request a snapshot 136 of a volume 134 of a client 130. The term snapshot may refer to a snapshot is the state of a system at a particular point in time and the term volume may refer to a single accessible storage area with a single file system. The writer unit 110 may create the snapshot 136 of the volume 134 of the client 130 while an application 132 included in the snapshot 136 continues to operate under a normal state. The snapshot 136 may include a database data file 137 and a transaction log file 138.

[0016] The request unit 120 may backup changes in the transaction log file 138 compared to a previous backup session 142 without backing up the database data file 137. The backed up changes in the transaction log file 138 may be appended to the previous backup session 142 at a host 140. A framework of the client 130 may not support backing up the transaction log file 138 separately from the database data file 137, such as the VSS.

[0017] The host 140 may be, for example, a media server that stores data on configured storage devices. The client 130 may be for example, a SQL server that logs any database changes in the transactional log file 138. The transactional log file 138 may contain every transaction that is being performed on a database, such as a relational database like a SQL database. The transactional log file 138 may keep increasing whenever any database change operations are performed like creating tables, adding/deleting rows into the table, modifying rows, deleting tables etc. Such database change transactions are recorded in the transaction log file 138.

[0018] While the device 100 is shown to be separate from the client 130 and host 140, examples of the device 100 may be included in the client 130, the 140 host, or a combination thereof. The device 100 is explained in greater detail below with respects to FIGS. 2-4.

[0019] FIG. 2 is an example block diagram of a computing device 200 including instructions for backing up a change in a transaction log file. In the embodiment of FIG. 2, the computing device 200 includes a processor 210 and a machine- readable storage medium 220. The machine-readable storage medium 320 further includes instructions 222 and 224 for backing up a change in a transaction log file.

[0020] The computing device 200 may be included in or part of, for example, a microprocessor, a controller, a memory module or device, a notebook computer, a desktop computer, an all-in-one system, a server, a network device, a wireless device, or any other type of device capable of executing the instructions 222 and 224. In certain examples, the computing device 200 may include or be connected to additional components such as memories, controllers, etc.

[0021] The processor 210 may be, at least one central processing unit (CPU), at least one semiconductor-based microprocessor, at least one graphics processing unit (GPU), a microcontroller, special purpose logic hardware controlled by microcode or other hardware devices suitable for retrieval and execution of instructions stored in the machine-readable storage medium 220, or combinations thereof. The processor 210 may fetch, decode, and execute instructions 222 and 224 to implement backing up the change in the transaction log file. As an alternative or in addition to retrieving and executing instructions, the processor 210 may include at least one integrated circuit (IC), other control logic, other electronic circuits, or combinations thereof that include a number of electronic components for performing the functionality of instructions 222 and 224.

[0022] The machine-readable storage medium 220 may be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. Thus, the machine-readable storage medium 220 may be, for example, Random Access Memory (RAM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a storage drive, a Compact Disc Read Only Memory (CD-ROM), and the like. As such, the machine-readable storage medium 220 can be non-transitory. As described in detail below, machine- readable storage medium 220 may be encoded with a series of executable instructions for backing up the change in the transaction log file.

[0023] Moreover, the instructions 222 and 224, when executed by a processor (e.g., via one processing element or multiple processing elements of the processor) can cause the processor to perform processes, such as, the processes of FIG. 3 or 4. For example, the compare instructions 222 may be executed by the processor 210 to compare a current transaction log file at a client to a transaction log file at a host that was previously backed up from the client.

[0024] The backup instructions 224 may be executed by the processor 210 to backup any blocks from the current transaction log file that have changed from the transaction log file at the host. The blocks may be backed up from a snapshot of a volume of the client that is created without interrupting operation of an associated application of the client. The snapshot may include both a database data file and a transaction log file. The blocks of the transaction log file may be backed up without backing up the database data file. The client may restore the database data and transaction log files from the host using a copy of the transaction log and database data file provided by the host.

[0025] FIG. 3 is an example flowchart of a method 300 for backing up a change in a transaction log file. Although execution of the method 300 is described below with reference to the device 100, other suitable components for execution of the method 300 can be utilized, such as the computing device 200. Additionally, the components for executing the method 300 may be spread among multiple devices (e.g., a processing device in communication with input and output devices). In certain scenarios, multiple devices acting in coordination can be considered a single device to perform the method 300. The method 300 may be implemented in the form of executable instructions stored on a machine-readable storage medium, such as storage medium 220, and/or in the form of electronic circuitry.

[0026] At block 310, the device 100 retrieves any blocks of a transaction log file 138 of a client 130 that have changed since a previous backup 142 of a volume 134 of the client 130. The transaction log file 138 may include transactions performed on a database of the client 130. At block 320, the device 100 backs up the changed blocks to a host 140. A framework of the client 130 does not support backing up the transaction log file 138 separately from a database data file 137 of the volume 134. The host 140 may retrieve and/or backup the transaction log file 138 separately from the database data file 137. [0027] FIG. 4 is another example flowchart of a method 400 for backing up a change in a transaction log file. Although execution of the method 400 is described below with reference to the device 100, other suitable components for execution of the method 400 can be utilized, such as the computing device 200. Additionally, the components for executing the method 400 may be spread among multiple devices (e.g., a processing device in communication with input and output devices). In certain scenarios, multiple devices acting in coordination can be considered a single device to perform the method 400. The method 400 may be implemented in the form of executable instructions stored on a machine-readable storage medium, such as storage medium 220, and/or in the form of electronic circuitry.

[0028] At block 410, the device 100 backs up both a database data file 137 and a transaction log file 138 using a framework of the client 130. The database data file may include the data included in the transactions of the transaction log file 138. At block 420, the device 100 creates a full snapshot 136 of the volume 134 of the client 130 using the framework of the client 130. The full snapshot may include both the transaction and database data files 137 and 138. The client 130 may flush all in-memory data to the volume 134 before the snapshot 136 is created. Also, the client 130 may create the snapshot 136 while an application 132 included in the snapshot 136 continues to operate under a normal state.

[0029] At block 430, the device 100 retrieves any blocks of the transaction log file 138 of a client 130 that have changed since a previous backup 142 of a volume 134 of the client 130. The transaction log file 138 may include transactions performed on a database of the client 130. The retrieving at block 430 determines the changed blocks of the transaction log file 138 of the client based on a comparison to a transaction log file 138 at the host 140 that was backed up from the client 130 from a previous backup session 142. The transaction log file 138 may only include transactions that are committed to the volume by the client.

[0030] At block 440, the device 100 backs up the changed blocks to a host 140. A framework of the client 130 does not support backing up the transaction log file 138 separately from a database data file 137 of the volume 134. The host 140 may retrieve and/or backup the transaction log file 138 separately from the database data file 137. The backing up at block 440 may be repeated to create a plurality of backup session 142. The transaction log file 138 from each of the backup sessions 142 may be stored as separate file. The transaction and database data files 137 and 138 may be stored as separate files.

[0031] At block 450, the device 100 and/or host 140 receive a restore request from the client 130. The restore request may include a restore point up to a selected backup session 142. At block 460, the device 100 and/or host 140 may create and provide a virtual transaction log file based on a consolidated chain of backup sessions up to at least the selected session. The virtual transaction log file may be assembled on the fly with a logical consolidation, not actual consolidation, of the backup sessions. At least one of a location, size and offset of the plurality of backup sessions may be mapped to a table 144. The virtual transaction log file may be formed based on the table 144.

[0032] For example, assume there are ten backup sessions in which one of the backup sessions is a full backup session and the remainder of the backup sessions are transaction log backups. If a user selects to restore up to a fifth backup session, then the restore chain may be carried out in the following order: the full backup session, a first backup session, a second backup session, a third backup session, a fourth backup session and the fifth backup session.

[0033] The host 140 may present the virtual transaction log file in response to an input/output (I/O) request from the client 130. The table 144 may be used to convert a virtual address of the presented virtual transaction log file to an actual address at the host 140, in response to the I/O request of the client 130. For example, the host 140 may use a hooking mechanism, like the FUSE technology on a Linux platform or file system filter drivers on a Windows platform. The hooking mechanism may trap I/O requests received from the client 130 and process them and map to physical storage locations to satisfy I/O requests.

[0034] The client 130 may read the plurality of backup sessions up to the selected backup session of the virtual transaction log file in consecutive order to restore the database data file 137. The client 130 may roll forward completed transactions and roll back incomplete transactions, after the selected backup session is restored. The transaction log file 138 may wrap around if a physical size limit is reached. An amount of the wrap around may be limited by an oldest log record required for a successful database-wide restore.

Claims

CLAIMS We claim:

1. A method, comprising:

retrieving any blocks of a transaction log file of a client that have changed since a previous backup of the transaction log file of the client, the transaction log file to include transactions performed on a database of the client; and

backing up the changed blocks to a host, wherein

a framework of the client does not support backing up the transaction log file separately from a database data file of a volume, and

the host is to at least one of retrieve and backup the transaction log file separately from the database data file.

2. The method of claim 1 , wherein,

the retrieving determines the changed blocks of the transaction log file of the client based on a comparison to a transaction log file at the host that was backed up from the client from a previous backup session,

the transaction log file only includes transactions that are committed to the volume by the client.

3. The method of claim 1 , further comprising:

backing up both a database data file and the transaction log file using the framework of the client, before the retrieving, wherein

the database data file includes the data included in the transactions of the transaction log file.

4. The method of claim 3, further comprising:

creating a full snapshot of the volume of the client using the framework of the client before the retrieving, the full snapshot to include both the transaction and database data files, wherein

the client is to flush all in-memory data to the volume before the snapshot is created.

5. The method of claim 4, wherein the client is to create the snapshot while an application included in the snapshot continues to operate under a normal state.

6. The method of claim 4, wherein,

the backing up is repeated to create a plurality of backup sessions, the transaction log file from each of the backup sessions is stored as separate file, and

the transaction and database data files are stored as separate files.

7. The method of claim 6, wherein,

the host is to receive a restore request from the client, the restore request to include a restore point up to a selected backup session, and

the host is to create and provide a virtual transaction log file based on a consolidated chain of backup sessions up to at least the selected session.

8. The method of claim 7, wherein,

at least one of a location, size and offset of the plurality of backup sessions are mapped to a table, and

the virtual transaction log file is formed based on the table.

9. The method of claim 8, wherein,

the host is to present the virtual transaction log file in response to an input/output (I/O) request from the client, and

the table is used to convert a virtual address of the presented virtual transaction log file to an actual address at the host, in response to the I/O request of the client.

10. The method of claim 9, wherein,

the client is to read the plurality of backup sessions up to the selected backup session of the virtual transaction log file in consecutive order to restore the database data, and

the client is to roll forward completed transactions and roll back incomplete transactions, after the selected backup session is restored.

11. The method of claim 1 , wherein,

the transaction log file wraps around if a physical size limit is reached, and

an amount of the wrap around is limited by an oldest log record required for a successful database-wide restore.

12. A device, comprising:

a request unit to request a snapshot of a volume of a client; and a writer unit to create the snapshot of the volume of the client while an application included in the snapshot continues to operate under a normal state, the snapshot to include a database data file and a transaction log file, wherein the request unit is to backup changes in the transaction log file compared to a previous backup session without backing up the database data file, and a framework of the client does not support backing up the transaction log file separately from the database data file.

13. The device of claim 12, wherein the backed up changes in the transaction log file are appended to a logical end of the previous backup session at a host.

14. A non-transitory computer-readable storage medium storing instructions that, if executed by a processor of a device, cause the processor to: compare a current transaction log file at a client to a transaction log file at a host that was previously backed up from the client; and

backup any blocks from the current transaction log file that have changed from the transaction log file at the host, wherein

the blocks are backed up from a snapshot of a volume of the client that is created without interrupting operation of an associated application of the client, the snapshot includes both a database data file and a transaction log file, and

the blocks of the transaction log file are backed up without backing up the database data file.

15. The non-transitory computer-readable storage medium of claim 14, wherein the client is to restore the database data and transaction log files from the host using a copy of the transaction log and database data file provided by the host.