HK1236640A - Hybrid backup and recovery management system for database versioning and virtualization with data transformation - Google Patents

Description

Hybrid backup and reduction management system and backup method and reduction method thereof

Technical Field

The present invention relates to a restoration management system for controlling and virtualizing a database version, and more particularly, to a hybrid backup restoration management system with database conversion capability for controlling and virtualizing a database version, a backup method thereof, and a restoration method thereof.

Background

The database is a core requirement of all cloud services. Even in a closed environment of a business or plant, the flow of data to and from all user-related files may be an important source of data for the business operator. Thus, the database for data collection and access is made to play the role of decision-making facilitator, and the database management becomes an indispensable technology in daily life.

Backup restore is the most fundamental and important ring of all operations for database management. Recently, there are two implementations of the above work. One is to consider file level operations, exemplified by Oracle's RMAN (a restore management software), which notifies the backup execution module (i.e., Oracle database manager) of the item's need when a backup job is requested by a database manager. The backup-conducting module prepares the required data from the original storage device. After reading the data in the original storage device, the RMAN writes the data in a file format to a backup storage device, such as a tape or disk. The above procedure can be applied to both initial full back-up and incremental back-up. This means that the database manager can see the results of the backup through the RMAN, presenting it in the form of an "archive" as it expects.

There are problems with archive level backup restore operations. Because the backed up data is a file, it takes time to gather the contents of the file scattered over many unconnected blocks. Archive level backups take longer than volume level backups, especially at the time of the initial full backup. In addition, backup files are mainly used for recovery purposes, and the restored data can only be presented in the format of their source files (databases), and may not be suitable for other purposes such as startup, training, etc. without data conversion.

Another way to implement backup restore is through volume level operations, which is also commonly used. For example, it is implemented in IBM corporation Logical Volume Manager (LVM) and EMC corporation Business Continuity Volume (BCV). Taking the logical volume manager as an example, when a backup operation is requested by a database manager, the restore management software will notify the backup proceeding module (e.g., Oracle database manager) about the request. The backup performing module synchronizes the required data managed by the logical volume manager in the original volume to the backup volume through the snapshot and through the service continuity volume function. The primary and/or backup volumes are managed by a logical volume manager and may each contain many disks.

Volume level backup restore operations also have a number of problems. First, because volume-level backup restores are not common to database management operations, it is difficult for database managers to accommodate many new ideas stemming from volume-level backup restore software. At the same time, the database management personnel are too familiar with the interfaces and operation modes of the archive level management software, so that the operation steps and ideas which are used by the database management personnel in the past are not easy to change. Second, as with archive level backup restore operations, these backup files are used primarily for recovery purposes, and the restore data can only be presented in the format of their original database.

From the above description, it is apparent that backup data, whether for archive-level or volume-level operations, is limited to the format in which it is restored. This is a waste of resources, and the restored data can be applied to many aspects, such as training, restoration, research and development, data mining, and cloud application. In addition, if metadata can be added to the backup file, more metadata can be transformed. Applications of database translation capabilities such as power-on or database format changes (for power-on, disk IDs or database IDs that are needed by some operating systems or database systems may be emulated and added to the backup file). Preferably, the restored data may be application-aware and different from the state of the data prior to backup.

Due to the above needs, a backup-restore management system for a database is highly desirable.

Disclosure of Invention

This paragraph of text extraction and compilation has certain features of the present invention. Other features will be disclosed in subsequent paragraphs. Various modifications and similar arrangements based on the same idea are intended to be covered by the scope of this application.

In order to meet the above needs, the present invention discloses a hybrid backup-restore management system with database transformation capability for database version control and virtualization. The hybrid backup-restore management system comprises at least one original storage device, at least one target storage device, a database management subsystem and a conversion module. The at least one original storage device can perform snapshot on an original volume in the original storage device, wherein the original volume comprises a database. At least one target storage device for creating an image of the raw volume.

The database management subsystem is used for receiving an initial backup instruction and an incremental backup instruction, stopping the current action in the original volume according to the initial backup instruction or the incremental backup instruction, recording the time of receiving the initial backup instruction or the incremental backup instruction in a time mark area as a time mark, indicating the original storage device to snapshot the original volume, storing all snapshot blocks in the original volume into a target volume according to the initial backup instruction, storing a file changed between two snapshots into the target volume according to the incremental backup instruction, and restoring the database.

And the conversion module is used for converting the blocks in the target volume into a plurality of file formats after the block storage in the target volume is finished, and storing the changed parts of the changed files into the available blocks of other target volumes, wherein the plurality of files are the same as the files in the original volume when the first snapshot occurs, and the changed files are changed between two snapshots of the original volume. The mapping table in the conversion module stores the mapping relationship between the blocks and the corresponding converted files or the mapping relationship between the changed files and the corresponding blocks.

The restoration management module is connected to at least one original storage device through the database management subsystem and used for sending an initial backup instruction and an incremental backup instruction, checking whether the files backed up in the target volume are the same as the files in the original volume, and sending a restoration instruction to the database management subsystem for database restoration. The conversion module can be software, hardware or firmware.

The hybrid backup-restore management system further includes an application module for changing the data format of the data in the target volume from one database system to another database system and/or adding new functionality to the target volume so that the stored data can provide new functionality to the original volume after the database is restored from the stored data.

Preferably, the new function is to have boot capability or to change at least one original storage device to at least one virtual machine disk. The application module is software, hardware or firmware.

The invention also discloses a backup method using the hybrid backup reduction management system, which comprises the following steps: the restoration management module sends an initial backup instruction to the database management subsystem; stopping the current action in the original volume according to the initial backup instruction; recording the time of receiving the initial backup instruction as a time mark; according to the instruction of the restoration management module, carrying out snapshot on the original volume through at least one original storage device; storing all snapshot blocks in the original volume to a target volume in at least one target storage device according to an initial backup instruction; after the storage of the blocks in the target volume is finished, the blocks in the target volume are converted into a plurality of file formats by a conversion module; and checking, by the restore management module, whether the backed-up archive in the target volume is the same as the archive in the original volume.

The backup method may further comprise the steps of: the restoration management module sends an incremental backup instruction to the database management subsystem; stopping the current action in the original volume according to the incremental backup instruction; recording the time of receiving the incremental backup instruction as another time mark and storing the time mark in a time mark area; according to the instruction of the restoration management module, carrying out snapshot on the original volume through at least one original storage device; the changed portion of the changed archive, which is the original volume, is changed between two snapshots is stored in the available blocks of other target volumes according to the incremental backup instructions. Storing the mapping relation between the changed files and the corresponding blocks; and checking, by the restore management module, whether the backed-up archive in the target volume is the same as the archive in the original volume.

The invention also discloses a restoration method using the hybrid backup restoration management system, which comprises the following steps: the restoration management module sends a restoration instruction to the database management subsystem to restore the database; designating a reduction time in the specific time stamp for reduction; and according to the mapping table, restoring the database to the state of the restoration time by copying the mapping to the relevant file in the target volume.

The invention utilizes the advantage of high speed of data transmission in the volume level format, but enables database management personnel to see the backup and recovery program and interface which are used by the database management personnel (in the file level format). The above needs are met by certain plug-in modules that maintain an existing database management system.

Drawings

FIG. 1 is a diagram of a hybrid backup-restore management system according to an embodiment of the present invention;

FIG. 2 is a diagram illustrating an embodiment of mapping tables used for initial backup;

FIG. 3 is a diagram illustrating mapping tables used in one embodiment of a copy operation;

FIG. 4 is a diagram illustrating an embodiment of a mapping table for incremental backup according to the present invention;

FIG. 5 is a flowchart of an embodiment of an initial backup in the present invention;

FIG. 6 is a flow chart of an embodiment of incremental backup in the present invention;

FIG. 7 is a flow chart of an embodiment of the reduction of the present invention;

10-a hybrid backup restoration management system; 100-a host; 200-a primary storage device cluster; 210-hard disk; 220-solid state disk; 250-original volume; 270-database; 300-a target storage device cluster; 310-hard disk; 350-target volume; 400-a database management subsystem; 420-time stamp region; 500-restore management module; 600-a conversion module; 610-a mapping table; 700-application module.

Detailed Description

The present invention will be more specifically described with reference to the following embodiments.

Referring to FIG. 1, FIG. 1 illustrates an embodiment of a hybrid backup-restore management system with database conversion capabilities for database version control and virtualization. The hybrid backup-restore management system 10 includes a primary storage device cluster 200, a target storage device cluster 300, a database management subsystem 400, a transformation module 600, and an application module 700. In fact, the restore management module 500 is also needed for smooth operation of the hybrid backup-restore management system 10. However, in many instances, the restore management module 500 is incorporated into the database management subsystem 400. For a better understanding of the present invention, the restore management module 500 is a separate unit from the database management subsystem 400. The database management subsystem 400, the restore management module 500, the conversion module 600, and the application module 700 are provided in the host 100. Each of the above 4 components may be software installed in an operating system of the host 100 to perform a specific work. One or all of the above 4 components may also be hardware, for example, an external card is plugged into the motherboard of the host 100. Alternatively, the firmware in the rom may be a form of the above components. In the present embodiment, the above 4 components are all in the form of software. Of course, in actual practice, the conversion module 600 and the application module 700 may be two software modules installed on one host, while the database management subsystem 400 and the restoration management module 500 are two hardware modules installed on another host. Alternatively, the software modules of the restore management module 500, the conversion module 600 and the application module 700 are installed on the same host, but the database management subsystem 400 is installed on another host. The type and installation of the 4 components are very flexible, and the invention is not limited thereto.

The primary storage cluster 200 includes hard disks 210 and solid state disks 220. The original storage cluster 200 can provide space for storing data. According to the inventive concept of the present invention, only one primal storage device can also be used instead of the primal storage device cluster 200. In this example, the backup restore of the database is performed by only a single primary storage device. Generally, the same backup restore procedure can be applied to many original storage devices, which may form a RAID (redundant Array of Inexplicit disks). The primary storage device may be a hard disk, a solid state disk, or a hybrid disk. The primary storage cluster 200 features a snapshot of the primary volumes 250, and the database 270 is thus formed in the primary volumes 250. For example, a NetApp hard disk in the market may be a good choice.

The target storage device cluster 300 includes 4 hard disks 310 (named hard disk 1, hard disk 2, hard disk 3, and hard disk 4, respectively). The target storage cluster 300 can provide space for backing up data, databases, or for backing up image files of a single disk or cluster disks. Similarly, only one target storage device can be used in place of the target storage device cluster 300. That is, the backup may be in one disk as long as its capacity is large enough. Like the original storage device, the target storage device may also be a hard disk, a solid state disk, or a hybrid disk. According to the present invention, the target storage cluster 300 is used to create the raw volume image 250.

It should be noted that according to the present invention, the original cluster of storage devices 200 and the target cluster of storage devices 300 may be located at a very close distance. For example, they may be part of a RAID, with the data being backed up or restored being transferred over an internal connection. They may also be Storage devices in a data center or a Storage Area Network (SAN) used by an enterprise, and backup or restore data is transmitted through the LAN. The original cluster of storage devices 200 and the target cluster of storage devices 300 may also be located at a significant distance. In this case, the primary storage cluster 200 and the target storage cluster 300 may be located in different data centers, and the remote backup restoration is processed through the internet or a Wide Area Network (WAN).

In the present embodiment, the raw volume 250 is a logical volume, and the entire space of the hard disk 210 and the solid state disk 220 is used as the raw volume 250. Some space in the raw volume 250 is reserved for the database 270 and the remainder of the raw volume 250 may be reserved for extensions of the database 270, to store some data unrelated to the database 270, and/or metadata for the database 270. Of course, in addition to copying the entire space of the hard disks 210 and the solid state disks 220, the original volume 250 may also use only a portion of the space in the original storage cluster 200, which is not limited in the present invention.

The database management subsystem 400 is used to connect the primary 200 and target 300 storage clusters. Although there are some existing database systems on the market that can be used as the database management subsystem 400, such as the Oracle database management solution, it must have the following functions: receiving an initial backup command and an incremental backup command, stopping the current operation in the database 270, recording the time when the initial backup command or the incremental backup command is received as the time stamp of the time stamp area 420, instructing the original storage device to perform a snapshot on the original volume 250, storing all snapshot blocks in the original volume 250 to the target volume 350 in at least one target storage device (the target storage device cluster 300) according to the initial backup command, storing a file of changes between two snapshots of the original volume to the target volume 350 according to the incremental backup command, and restoring the database 270. The timestamp zone 420 is the memory space in the host used by the database management subsystem 400, and it mainly records the data content and time of each backup. These records will be used to restore the database 270 back to the state at the particular point in time. A detailed description of the above functions will be presented through the operation of the hybrid backup-restore management system 10.

The restore management module 500 is independent of the database management subsystem 400, with the emphasis on backup restore of the database. In the market, some solutions are good choices. Taking Oracle's RMAN as an example. The database manager can input some script programs into the interface of the RMAN to perform backup restore of the database. However, RMAN data transfer is in a file-level format, which means that the data in the database is copied one after the other to a file of destinations, each with portions of the destination file gathered from the relevant blocks. In many cases, the blocks are not arranged in sequence, and the data block collection wastes too much time. While some solutions are capable of providing data transfer in a volume level format (direct replication of 0 and 1 in sequentially arranged blocks), these solutions are not the mainstay of database backup restore systems and are not adopted by most database management personnel. Because the restore management module 500 can only perform archive level format data transfers, or the restore management module 500 can perform both archive and volume level format data transfers, database managers still prefer not to use them because they are low level resource management tasks that are remote from application level operations or file level operations, which are familiar to database managers. In order to operate efficiently, it is therefore desirable that the backup and restore operations save all the processes of the restore management module 500 in a file-level format, and that the actual data transfer be in a volume-level or file-level format, depending on the state. This is the main idea of the invention and the actual operation is explained in detail below.

The restore management module 500 is coupled to the primary volumes 250 through the database management subsystem 400 and is capable of sending the initial backup instructions and the incremental backup instructions described above. In addition, the restore management module 500 is used to check whether the archive of the backup in the target volume 350 is the same as the archive in the original volume 250. For the restore operation, the restore management module 500 sends a restore instruction to the database management subsystem 400 to restore the original volume 250.

The conversion module 600 is connected to the restoration management module 500. Preferably, the conversion module 600 is connected to the restoration management module 500 through a plug-in. The conversion module 600 is used to convert the blocks in the target volume 350 into a plurality of file formats after the block storage in the target volume 350 has been completed. The converted archive is the same as the archive in original volume 250 at the time the first snapshot occurred. If this cannot be done, although there is an image file in the target volume 350, the image file appears to the restore management module 500 as a hashed group of 0's and 1's, as shown in FIG. 1. This is because the format of the image archive is still volume level if the conversion has not been performed. In addition, rather than re-creating new space to store the entire changed archive, the transformation module 600 can store the changed portions of the changed archive, which were the original volume changed between snapshots, in other available blocks in the target volume 350. This is used only in incremental backup jobs. One feature of the present invention is that block replication is applied to the initial backup to save time, while file-level replication is applied to the incremental backup to maintain a familiar model to the original database administrator. It should be noted that after the initial backup is completed, the conversion module 600 must notify the restore management module 500 that the initial backup has been completed at the destination in the format (archive level) recognized by the restore management module 500. Although the initial backup has been performed, this is not done in the manner contemplated by the restore management module 500. The above operation can be achieved by inputting a script program to the restore management module 500.

The conversion module 600 has a mapping table 610, and the mapping table 610 stores the mapping relationship between a block and a corresponding converted file or between a changed file and a corresponding block (unchanged block and changed block). Fig. 2 shows a diagram illustrating how mapping table 610 works. There are 5 files in the database 270, which are file A, file B, file C, file D, and file E. After the initial backup, file A is stored in blocks 001 to 100 of the hard disk 1, file B is stored in blocks 101 to 200 of the hard disk 1, file C is stored in blocks 201 to 240 of the hard disk 1, file D is stored in blocks 241 to 280 of the hard disk 1, and file E is stored in blocks 001 to 100 of the hard disk 2. The above information, the time of the initial backup and the backup (initial backup or incremental backup) type are all kept in the mapping table 610. When the restore management module 500 checks whether the archive in the original volume 250 has been backed up to the target volume 350, it will see the essence of the mapping table 610, rather than a large heap of indistinguishable 1's and 0's. How mapping table 610 operates under the incremental backup operation will be described below.

The application module 700 provides a number of functions to the database 270, or the raw volume 250 after the restore operation of the database 270. The application module 700 can change the data format of the data in the target volume 350 from one database system to another (i.e., database conversion capability), e.g., from an Oracle database to an SQL database. For database conversion capability, U.S. patent application No. 14/547,305 proposes that a method entitled "method and system for data transformation for closed-based acquisition and backup" can be used on the application module 700. Thus, after the data in the target volume 350 is used to restore the database 270 of the original volume 250, the restored database 270 may have the same contents after a backup, but may only be accessed by another database system. In addition, the application module 700 may add new functionality to the target volume 350 so that the stored data can provide the new functionality to the original volume 250 after the database 270 is restored from the stored data. The new function may be a bootable volume (with boot capability) for use on another host, or to change the original storage device to at least one virtual machine disk. The added new functionality may be implemented by adding metadata, related information, and/or an Application Programming Interface (API) for the new functionality to the target volume 350. There are many ways in which this can be done, and there is no limitation to the present invention. For example, the host's boot information may be added to the target volume 350. After the database 270 is restored, the raw volume 250 can be used as a boot volume. The data in the target volume 350 may also be obscured for applications that do not set up to learn some information that may be confidential. The reduced database may be restored to the original volume 250 and the new database can be used for business training or data analysis. Some applications may require changing the database ID or disk ID of the data in the target volume 350, and the stored data can be restored to other storage devices or volumes, where the database management system considers the restored database to be of an acceptable type.

The backup program of the hybrid backup-restore management system 10 will be described below. There are 3 types for backup operations: initial backup, incremental backup, and copy jobs. An initial backup is a full copy of the original volume 250, and an incremental backup only saves the changed archive between the initial backup and its subsequent incremental backup or between two consecutive incremental backups. In this example, each backup may be restored with a particular version. However, the copy operation only copies the entire original volume 250 at each point in time, so that the target volume 350 will only have one archive image version of the backup original volume 250. For the purposes of the present invention, a backup restore may or may not be versioned.

Fig. 5 is a flowchart of an initial backup (applicable to a version backup and copy job (first copy job)) including the steps of: in step S01, the restore management module 500 sends an initial backup command to the database management subsystem 400. Following step S02, the database management subsystem 400 begins to stop the current actions in the primary volume 250 according to the initial backup instructions. Stopping the present action means freezing the original volume 250, and the state of the original volume 250 becomes read only and not written. All actions and changes after the current action time point are stopped will be stored in other files until the backup operation is completed. In step S03, the time when the initial backup command is received is recorded as a time stamp in the time stamp area 420. In step S04, the primary storage device takes a snapshot of the primary volume 250, and the job is instructed by the restore management module 500. In step S05, the original storage device (original storage device cluster 200) stores all snapshot blocks in the original volume 250 to the target volume 350 (indicated by the dashed arrow in fig. 1) in the target storage device (target storage device cluster 300) according to the instruction of the initial backup. In step S06, after the storage of the block 350 in the target volume is completed, the conversion module 600 converts the block in the target volume 350 into a plurality of file formats. The archive of these transitions is the same as the archive in the original volume 250 prior to the snapshot. In step S07, the restore management module 500 checks whether the backed up archive in the target volume 350 is the same as the archive in the original volume 250. If the same, the database manager would consider the backup operation to be performed in a file-level format, but a little faster.

The procedure for the copy operation of the original volume 250 is the same as described above, but repeated over and over again. As shown in FIG. 3, when the second copy operation begins, both files are changed. The file B is modified and stored in blocks 101 to 180 of the hard disk 1. The file E is deleted. It is apparent that the target volume 350 in FIG. 3 is changed and the blocks mapped to the changed archive are also changed. The mapping table 610 records all blocks mapped to the new file.

FIG. 6 is a flowchart of an incremental backup operation, including the steps of: first, in step S11, the restore management module 500 sends an incremental backup command to the database management subsystem 400. Following step S12, the database management subsystem 400 stops the current actions in the primary volume 250 according to the instructions for incremental backup. Next, in step S13, in the time stamp area 420, the time when the incremental backup command is received is recorded as another time stamp. Following step S14, the restore management module 500 instructs the primary volume 250 to be snapshot via the primary storage device. At this time, in step S15, according to the instruction of incremental backup, the original storage device (original storage device cluster 200) stores the changed part of the changed file, which is changed between two snapshots, into the available blocks of other target volumes 350. This is no longer the block level operation performed in the initial backup operation. In step S16, the transformation module 600 stores the mapping relationship between the changed files and the corresponding blocks (source file block and changed part block). By mapping the source file block and the changed part of the block, a complete changed file can be obtained. Finally, in step S17, the restore management module 500 checks whether the backed up archive in the target volume 350 is the same as the archive in the original volume 250. Additional incremental backup operations may be performed by repeating the above steps.

FIG. 4 shows the mapping table 610 with the changes in the target volume 350. Between the initial backup and the first incremental backup, 3 files have changed (or increased). File B is modified, file E is deleted, file F is added to the database and blocks 103-198 of hard disk 2 are stored. If the size of file B becomes shorter, the changed part of file B is that the bits of the last 20 blocks are changed from the block level format point of view. The required data is retained to describe the archival content of the "elapsed" region. This data is thus stored in the block 101 of the hard disk 2. Conversely, if file B becomes larger, the changed portions will be stored in some of the blocks. Similarly, the deleted file E is stored in the block 102 of the hard disk 2. It is clear from FIG. 4 that the mapping table 610 only records blocks that map to changed portions of the changed file. In the target volume 350, the data recording the initial backup does not change.

FIG. 7 is a flow chart of a reduction operation, including the steps of: first, in step S21, the restoration management module 500 sends a restoration instruction to the database management subsystem 400 to restore the database 270. Following step S22, the restore time in the particular timestamp in the timestamp zone 420 is designated for restoring. Finally, in step S23, the database 270 is restored to the restore time status by copying the image to the relevant archive in the target volume 350 according to the mapping table 610.

Although the present invention has been described with reference to the above embodiments, it should be understood that the invention is not limited thereto, and those skilled in the art can make various changes and modifications without departing from the spirit and scope of the invention.

Claims (10)

1. A hybrid backup-restore management system with database conversion capability for database version control and virtualization, comprising:

at least one primary storage device capable of taking a snapshot of a primary volume in the primary storage device, the primary volume comprising a database;

at least one target storage device for creating an image of the raw volume;

the database management subsystem is used for receiving an initial backup instruction and an incremental backup instruction, stopping the current action in the original volume according to the initial backup instruction or the incremental backup instruction, recording the time of receiving the initial backup instruction or the incremental backup instruction in a time mark area as a time mark, indicating the original storage device to carry out snapshot on the original volume, storing all snapshot blocks in the original volume into a target volume according to the initial backup instruction, storing a file changed between two snapshots into the target volume according to the incremental backup instruction, and restoring the database; and

a conversion module, configured to convert blocks in the target volume into formats of a plurality of files after block storage in the target volume is completed, and store a changed part of the changed files into an available block of another target volume, where the plurality of files are the same as files in the original volume when a first snapshot occurs, and the changed files are changed between two snapshots of the original volume;

the mapping table in the conversion module stores the mapping relationship between the blocks and the corresponding converted archives or the mapping relationship between the changed archives and the corresponding blocks.

2. The hybrid backup-restore management system according to claim 1, wherein the restore management module is connected to at least one of the original storage devices through the database management subsystem, and is configured to send the initial backup command and the incremental backup command, check whether the archive backed up in the target volume is the same as the archive in the original volume, and send a restore command to the database management subsystem for database restore.

3. The hybrid backup-restore management system of claim 1, wherein the conversion module is software, hardware, or firmware.

4. The hybrid backup-restore management system according to claim 1, further comprising:

and the application module is used for changing the data format of the data in the target volume from one database system to another database system and/or adding a new function to the target volume, so that the stored data can provide the new function to the original volume after the database is restored by the stored data.

5. The hybrid backup-restore management system of claim 4, wherein the new function is to have boot capability or to change at least one of the original storage devices to at least one virtual machine disk.

6. The hybrid backup-restore management system of claim 4, wherein the application module is software, hardware, or firmware.

7. The hybrid backup-restore management system of claim 1, wherein the original storage device is a hard disk, a solid state disk, or a hybrid disk.

8. A backup method using the hybrid backup-restore management system of claim 2, comprising the steps of:

the restoration management module sends an initial backup instruction to the database management subsystem;

stopping the current action in the original volume according to the initial backup instruction;

recording the time of receiving the initial backup instruction as a time mark;

according to the indication of the restoration management module, carrying out snapshot on the original volume through at least one original storage device;

storing all snapshot blocks in the original volume to a target volume of at least one target storage device according to the initial backup instruction;

after the storage of the blocks in the target volume is finished, converting the blocks in the target volume into a plurality of file formats by a conversion module; and

checking, by a restore management module, whether the backed-up archive in the target volume is the same as the archive in the original volume.

9. The backup method according to claim 8, further comprising the steps of:

the restoration management module sends an incremental backup instruction to the database management subsystem;

stopping the current action in the original volume according to the incremental backup instruction;

recording the time of receiving the incremental backup instruction as another time mark in the time mark area;

according to the indication of the restoration management module, carrying out snapshot on the original volume through at least one original storage device;

storing changed parts of changed files into available blocks of other target volumes according to the incremental backup instruction, wherein the changed files are changed between two snapshots of the original volume;

storing the mapping relation between the changed files and the corresponding blocks; and

checking, by the restore management module, whether the backed up archive in the target volume is the same as the archive in the original volume.

10. A restoration method using the hybrid backup restoration management system of claim 2, comprising the steps of:

the restoration management module sends a restoration instruction to the database management subsystem to restore the database;

designating a reduction time in the specific time stamp for reduction; and

and restoring the database to the state of the restoration time by copying the image to the relevant archive in the target volume according to the image table.