A block-level data backup system and method

Abstract

The present invention discloses a block-level data backup system, which includes a console, a client, and a backup server. The client includes a client service module, a backup task execution module, and a block change monitoring module that are connected in sequence. The console is used to manage the client and the backup server, formulate a backup plan and send it to the client and the backup server. The client service module is used to receive the full backup or incremental backup plan of the user. The backup task execution module is used to execute the backup task. The backup task execution module includes a full backup sub-module and an incremental backup sub-module, and each sub-module is implemented through a main thread, a read thread, a compression thread, an encryption thread, and a write thread. The block change monitoring module is used to monitor the block changes, save the block change information in the form of a bitmap and provide it for the backup execution module to use. The present invention uses block-level change tracking technology to monitor the changed blocks of the volume to be protected, and can obtain accurate change data, thereby ensuring the consistency of the backup data.

Description

Technical Field

[0001] The present invention generally relates to the technical field of computer disaster recovery and backup, and more particularly to a block-level data backup system and method. Background Art

[0002] To avoid data loss, users usually store files and data in a backup system, which can generally store a large amount of data. When a data failure or a disaster occurs, the data can be restored through the backup system to avoid unnecessary losses.

[0003] From the perspective of backup types, backups are divided into full backups, incremental backups, differential backups, etc.

[0004] Full backup: Back up all specified data, regardless of whether the data has been changed since the last backup. A full backup is the basis for an incremental backup.

[0005] Incremental backup: Back up data objects that have been changed since the last full backup or incremental backup. A successful full backup must be performed before an incremental backup can be made. When restoring data using an incremental backup, the corresponding full backup and all incremental backups before that incremental backup are required.

[0006] From the perspective of backup technologies, backups are divided into file-level backups and block-level backups, etc.

[0007] File-level backup: When specifying certain files for backup, first, the logical blocks of each file are searched, and then the physical blocks. Since the logical blocks are scattered on the physical blocks, and the physical blocks are also scattered on different sectors. It is necessary to search layer by layer, and finally the entire file is copied. File-level backup is time-consuming, inefficient, not real-time, has a long backup time, and when making an incremental backup, if a small part of a single file is modified, the entire file will be backed up instead of just the modified part.

[0008] Block-level backup: Refers to physical block replication, which is highly efficient, real-time, has a short backup time, and when making an incremental backup, only the modified physical blocks are backed up. Block-level backup can well solve the long backup scenario with a large number of small file objects, excessive fragmentation, and excessive handles.

[0009] Backup plan: A backup plan generally includes four important backup elements: what to back up, how to back up, where to back up to, and when to back up. What to back up generally refers to the objects to be backed up, such as files, folders, volumes, disks, databases, etc. How to back up generally refers to full backup, incremental backup, etc. Where to back up to generally refers to where the backed-up data is saved, usually on another storage device or in the cloud, etc. When to back up generally refers to the time when the backup runs and how to repeat the execution, etc.

[0010] Restore point: A time-point snapshot image of a backup created after a backup is successfully executed.

[0011] File-level backups have the following disadvantages: It is necessary to search layer by layer and finally complete the entire file copy. File-level backups are time-consuming, inefficient, not real-time, have a long backup time, and during incremental backups, if a small part of a single file is modified, the entire file will be backed up instead of just the modified part. In the scenario of a large number of small files, file-level backups will result in problems such as too many objects, too many fragments, and too many handles. Summary of the Invention

[0012] The present invention aims at the deficiencies in the prior art and provides a method and a computer program product for backing up data.

[0013] To achieve the above object, the present invention adopts the following technical solutions:

[0014] A block-level data backup system includes a console, a client, and a backup server. The number of clients and the number of backup servers are both greater than or equal to 1. The client includes a client service module, a backup task execution module, and a block change monitoring module connected in sequence. The console is used to manage the client and the backup server, formulate a backup plan, and send it to the client and the backup server. The client service module is used to receive a full backup or incremental backup plan from the user. The backup task execution module is used to execute backup tasks. The backup task execution module includes a full backup sub-module and an incremental backup sub-module. Each sub-module is implemented through a main thread, a read thread, a compression thread, an encryption thread, and a write thread. The block change monitoring module (203) is used to monitor block changes, that is, the changes in the sectors of the volume to be protected in the plan, so as to avoid scanning the entire disk to obtain the changed files, and save the block change information in the form of a bitmap for use by the backup execution module.

[0015] Further, the backup plan includes the volume to be protected by the client, the backup server to which the backup is to be made, the start time of the first full backup, the start time of the first incremental backup, and backup settings. The backup settings include encryption and compression.

[0016] A block-level data backup method includes the following steps:

[0017] S1. The client service module receives the backup plan sent by the console.

[0018] S2. The client service initiates a full backup task according to the start time of the first full backup and the full backup method set in the plan.

[0019] S3. The backup task execution module creates a restore point.

[0020] S4. The backup task execution module takes a snapshot of the volume to be protected in the plan to obtain a snapshot volume, and at the same time notifies the block change monitoring driver module to start monitoring the changed blocks of the volume to be protected, and uses a persistent bitmap to save the information of the changed blocks;

[0021] S5. Open the snapshot volume, traverse the clusters of the snapshot volume to obtain all valid clusters, that is, the clusters with file data, and generate cluster bitmap information. The clusters with file data are represented by 1, otherwise by 0;

[0022] S6. Traverse the cluster bitmap. For the bits with a value of 1, obtain the offset position according to the traversed bitmap subscript, read the data from the sector at the corresponding offset position of the snapshot volume, back up the read data and the corresponding data offset position. Recording the offset position is for future restoration. After that, delete the snapshot volume to complete the full backup task;

[0023] S7. The client service initiates an incremental backup task according to the first incremental backup start time and the incremental backup method set in the plan;

[0024] S8. Detect whether the conditions are met. If so, execute step S9 of the incremental backup task; otherwise, change the backup task to a full backup and return to step S1 to perform a full backup again;

[0025] S9. Take a snapshot of the volume to be protected in the plan to obtain a snapshot volume, and return the name of the snapshot volume to the backup task execution module. Notify the block change monitoring module to copy out the persistent bitmap recording the changed block information to generate a temporary bitmap to save the changed blocks of the volume to be protected from this moment;

[0026] S10. The backup task execution module generates a restore point, opens the snapshot volume, and traverses the incremental snapshot volume to obtain the valid cluster bitmap of the incremental snapshot volume; merge the valid cluster bitmap of the incremental snapshot volume and the persistent bitmap of the changed blocks to obtain all the changed blocks from the last backup to the time when the snapshot was taken for this incremental backup;

[0027] S11. The backup task execution module obtains the offset addresses of all changed blocks according to the merged bitmap information, reads the data from the corresponding sectors of the incremental snapshot volume, backs up the read data and the corresponding data offset position, and then deletes the incremental snapshot volume. Notify the block change monitoring module to clear the persistent bitmap, copy the temporary bitmap to the persistent bitmap, and delete the temporary bitmap to complete the incremental backup task.

[0028] Further, in step 4, the changed blocks are represented by 1 in the persistent bitmap, the unchanged blocks are represented by 0, and the bitmap subscript represents the position of the block.

[0029] Further, the step S6 specifically includes the following steps:

[0030] S61. The main thread puts the cluster bitmap information to be read into the read task queue;

[0031] S62. The read thread takes out a read task from the read task queue and reads the data according to the cluster bitmap information and the offset position information of the valid clusters;

[0032] S63. Check whether compression is set in the backup plan. If it is set, put the read data into the compression task queue; otherwise, execute S64;

[0033] S64. Check whether encryption is set in the backup plan. If it is set, put the read data into the encryption task queue; otherwise, put the read data into the write data task queue;

[0034] S65. The compression thread takes out the data from the compression queue, performs compression, and then checks whether encryption is set in the backup plan. If it is set, put the compressed data into the encryption queue; otherwise, put the compressed data into the write data task queue;

[0035] S66. The encryption thread takes out the data from the encryption queue, performs encryption, and then puts it into the write data queue;

[0036] S67. The write data thread takes out the data from the write data queue and backs it up to the backup server (3).

[0037] The beneficial effects of the present invention are as follows:

[0038] 1. The present invention combines the block-level change tracking technology and the snapshot technology. The snapshot technology is used to perform a snapshot operation on the volume to be protected to ensure the consistency of the backup file system and other applications. The block-level change tracking technology is used to monitor the changed blocks of the volume to be protected, and accurate changed data can be obtained, thereby ensuring the consistency of the backup data. In addition, by generating a restore point, the file to be restored can be directly and quickly found when restoring data later. In summary, the consistency of the backup data is ensured, and volume-level backup can be performed without interrupting the customer's business, and there will be no situation where the file system is damaged due to consistency problems or the restored data is unavailable.

[0039] 2. Based on the changed block bitmap technology, the present invention enables the changed blocks during incremental backup to be quickly and reliably recorded, avoiding the problem of lost changed blocks and further ensuring the consistency of the backup data.

[0040] 3. When backing up data, the present invention adopts the producer-consumer mode, using different threads for reading data, encrypting data, compressing data, and writing data, improving the concurrency performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 is a schematic structural diagram of the system of the present invention;

[0042] Figure 2 is a schematic flowchart of the method of the present invention;

[0043] Figure 3 is a schematic diagram of the full backup process in the present invention;

[0044] Figure 4 is a schematic diagram of the incremental backup process in the present invention;

[0045] Figure 5 is a schematic diagram of the main thread process when backing up data;

[0046] Figure 6 is a schematic diagram of the read thread process when backing up data;

[0047] Figure 7 is a schematic diagram of the compression thread process when backing up data;

[0048] Figure 8 is a schematic diagram of the encryption thread process when backing up data;

[0049] Figure 9 is a schematic diagram of the write thread process when backing up data;

[0050] Figure 10 is a schematic diagram of bitmap information merging;

[0051] Explanation of the markings in the figure: 1. Console, 2. Client, 3. Backup server, 201. Client service module, 202. Backup task execution module, 203. Block change monitoring module. Detailed implementation manners

[0052] Now, the present invention will be further described in detail with reference to the accompanying drawings.

[0053] The present invention provides a block-level data backup system, as Figure 1As shown in the figure, it includes a console 1, a client 2, and a backup server 3. The number of clients (2) and the number of backup servers (3) are both greater than or equal to 1. The client 2 includes a client service module 201, a backup task execution module 202, and a block change monitoring module 203 that are connected in sequence. The console 1 is used to manage the client 2 and the backup server 3, formulate a backup plan, and send it to the client 2 and the backup server 3. The client service module 201 is used to receive the full backup or incremental backup plan from the user. The backup task execution module 202 is used to execute the backup task. The backup task execution module 202 includes a full backup sub-module and an incremental backup sub-module, and each sub-module is implemented through a main thread, a read thread, a compression thread, an encryption thread, and a write thread. The block change monitoring module 203 is used to monitor the block changes, that is, the changes in the sectors of the volume to be protected in the plan, so as to avoid scanning the entire disk to obtain the changed files, and save the block change information in the form of a bitmap for the backup execution module 202 to use.

[0054] As Figure 2 shown, a data timed volume-level backup method includes the following steps:

[0055] S1. The client service module 201 receives the backup plan sent by the console 1.

[0056] S2. The client service initiates a full backup task according to the first full backup start time and the full backup method set in the plan.

[0057] S3. The backup task execution module 202 creates a restore point.

[0058] S4. The backup task execution module 202 performs a snapshot operation on the volume to be protected in the plan to obtain a snapshot volume, and at the same time notifies the block change monitoring driver module 203 to start monitoring the changed blocks of the volume to be protected, and uses a persistent bitmap to save the information of the changed blocks. In the persistent bitmap, 1 represents the changed block, 0 represents the unchanged block, and the bitmap subscript represents the position of the block.

[0059] S5. Open the snapshot volume, traverse the clusters of the snapshot volume to obtain all valid clusters, that is, the clusters with file data, generate cluster bitmap information, use 1 to represent the clusters with file data, and otherwise use 0 to represent.

[0060] S6. Traverse the cluster bitmap. For the bits with a value of 1, obtain the offset position according to the traversed bitmap subscript, read the data from the sector at the corresponding offset position of the snapshot volume, back up the read data and the corresponding data offset position, record the offset position for future restoration, and then delete the snapshot volume to complete the full backup task.

[0061] S7. The client service initiates an incremental backup task according to the first incremental backup start time and the incremental backup method set in the plan.

[0062] S8. Detect whether the condition is met. If it is met, execute the incremental backup task step S9. Otherwise, change the backup task to a full backup, return to step S1, and perform a full backup again.

[0063] S9. Perform a snapshot operation on the volume to be protected in the plan to obtain a snapshot volume, and return the name of the snapshot volume to the backup task execution module. Notify the block change monitoring module 203 to copy out the persistent bitmap recording the changed block information and generate a temporary bitmap to save the changed blocks of the volume to be protected from this moment.

[0064] S10. The backup task execution module 202 generates a restore point, opens the snapshot volume, traverses the incremental snapshot volume to obtain the valid cluster bitmap of the incremental snapshot volume; merge the valid cluster bitmap of the incremental snapshot volume and the persistent bitmap of the changed blocks to obtain all the changed blocks from the last backup to the snapshot during this incremental backup.

[0065] S11. The backup task execution module 202 obtains the offset addresses of all changed blocks according to the merged bitmap information, reads the data from the sectors corresponding to the incremental snapshot volume, backs up the read data and the corresponding data offset positions, then deletes the incremental snapshot volume, notifies the block change monitoring module 203 to clear the persistent bitmap, copies the temporary bitmap to the persistent bitmap, and deletes the temporary bitmap to complete the incremental backup task.

[0066] Step S6 specifically includes the following steps:

[0067] S61. The main thread puts the cluster bitmap information to be read into the read task queue.

[0068] S62. The read thread takes out a read task from the read task queue and reads the data according to the cluster bitmap information and the offset position information of the valid cluster.

[0069] S63. Detect whether compression is set in the backup plan. If it is set, put the read data into the compression task queue; otherwise, execute S64.

[0070] S64. Detect whether encryption is set in the backup plan. If it is set, put the read data into the encryption task queue; otherwise, put the read data into the write data task queue.

[0071] S65. The compression thread takes out the data from the compression queue, performs compression, and then detects whether encryption is set in the backup plan. If it is set, put the compressed data into the encryption queue; otherwise, put the compressed data into the write data task queue.

[0072] S66. The encryption thread takes out the data from the encryption queue, performs encryption, and then puts it into the write data queue.

[0073] S67. The data writing thread retrieves data from the data writing queue and backs it up to the backup server 3

[0074] Figure 3 This is a full backup process, corresponding to S3 - S6 Figure 4 This is an incremental backup process, corresponding to S9 - S11

[0075] To verify the data consistency of the regular backups of the present invention, the initial backup environment prepared in this embodiment is as follows: Prepare a 500GB NTFS (New Technology File System) volume, with 200GB of files sized 2M - 8M in valid data; the incremental backup environment prepared in this embodiment is: randomly add 50GB of files to the volume

[0076] During the first full backup, install the client software on the machine where the volume to be backed up is located, install the backup server software on one machine for storing the backed - up data; install the console 1 on one machine for the client 2, backup server 3 and backup plan; compile a backup plan on the console 1 software, including the volume of the machine to be backed up, the backup server to which it is to be backed up, the first full backup time, the first incremental backup time, the incremental backup time interval, backup settings (encryption, compression), etc. information, and send the plan from the console 1 to the machine to be backed up; the client service 201 receives the plan and executes it

[0077] a1). The client service 201 executes the full backup plan according to the time in the plan, starts the backup execution program 202, generates a restore point for selecting the restore point for full - volume recovery during restoration

[0078] a2). Take a snapshot of the NTFS backup volume, and the execution process starts the block change monitoring module to monitor the changed sectors

[0079] a3). The execution process reads the snapshot volume cluster information through the interface; traverses the cluster information to determine whether the cluster is valid data. After traversal is completed, execute step a6); if the cluster is not valid data, continue traversing, and if it is valid data, execute step a4)

[0080] a4). Read the data of the cluster and record the position offset address

[0081] a5). Back up the data in step a4)

[0082] a6). Delete the snapshot volume

[0083] a7). The task of full backup is successfully completed, the storage makes a success record, and the full backup is finished; compare the backed - up files with the original files, and the size and content are exactly the same, indicating that the full backup has achieved data consistency of the backup

[0084] Select the backup plan established in Step 1 when performing the first full backup from Console 1, and select the "Incremental Backup" option to perform a manual incremental backup; the manual incremental backup task is sent from Console 2 to Client 2; Client Service 201 receives the manual incremental backup task and starts the backup execution module 202: The backup execution module 202 obtains whether the previous full backup task of this task was successful from the backup server; if it is not successful, change the current incremental backup to a full backup and start from Step 5 of the full backup process; the backup execution module 202 generates a backup restore point for selecting a restore point for recovery during recovery; the backup execution module 202 takes a snapshot of the NTFS backup volume; calls a command to take a snapshot of the NTFS backup volume; at the same time, notify the block change monitoring driver module 203 to copy out the persistent bitmap and start monitoring the changed blocks of the volume to be protected from this moment using the temporary bitmap; open the snapshot volume and obtain the current snapshot volume data bitmap information; merge the valid bitmap of the incremental snapshot volume and the persistent bitmap of the changed blocks to obtain all the changed blocks from the start of the last backup to the end of taking the incremental backup snapshot; loop to obtain the sector offset address; through the obtained offset address, read the sector data corresponding to the snapshot volume offset address; back up the sector data; delete the snapshot volume; notify the block change monitoring module 203 to clear the persistent bitmap, copy the temporary bitmap to the persistent bitmap, delete the temporary bitmap, and use the persistent bitmap to record the changed blocks from this moment; the task incremental backup is successful, store the current backup record, and the incremental backup is completed; use a file comparison tool to compare the data size and content before and after the backup, and if they are exactly the same, it indicates that the incremental backup has also achieved backup data consistency.

[0085] Figure 5 It is a schematic diagram of the main thread's work. The main thread is responsible for creating a read thread, a compression thread, and an encryption thread, and then traversing the snapshot volume bitmap to generate a read request item for the bitmap information with data and put it into the read queue.

[0086] Figure 6 It is a schematic diagram of the read thread's work. The read thread is responsible for reading data. It loops to take out a read request item from the read queue. If the request item is an exit command, end this thread. Otherwise, read the data from the disk according to the information in the request item. If compression is required, generate a compression request item for the read data and put it into the compression queue; if compression is not required but encryption is required, generate an encryption request item for the read data and put it into the encryption queue; if neither compression nor encryption is required, generate a write request item for the read data and put it into the write queue.

[0087] Figure 7It is a schematic diagram of the compression thread's operation. The compression thread is responsible for compressing data. It repeatedly takes a compression request item from the compression queue. If the request item is an exit command, the thread ends. Otherwise, it compresses the data according to the information in the request item. If encryption is required, it generates an encryption request item from the compressed data and places it in the encryption queue; if encryption is not required, it generates a write request item from the compressed data and places it in the write queue.

[0088] Figure 8 It is a schematic diagram of the encryption thread's operation. The encryption thread is responsible for encrypting data. It repeatedly takes an encryption request item from the encryption queue. If the request item is an exit command, the thread ends; otherwise, it encrypts the data according to the information in the request item and places it in the write queue.

[0089] Figure 9 It is a schematic diagram of the write thread's operation. The write thread is responsible for writing data to the backup server. It repeatedly takes a write request item from the write queue. If the request item is an exit command, the thread ends; otherwise, it writes the data to the backup server according to the information in the request item.

[0090] Figure 10 It is a schematic diagram of the bitmap information merging operation. The block bitmap of valid clusters and the bitmap of changed blocks are transformed and merged to obtain the bitmap of data blocks to be backed up.

[0091] It can be seen from this that the present invention provides a block-level backup solution that can ensure data consistency. This method is applicable to the backup scenario of a large number of small files. It ensures the consistency of backup data through snapshot technology and block-level monitoring technology, and can perform full-volume backup and incremental backup on the entire volume on the basis of ensuring file system consistency, belonging to the field of backup. This method can perform volume-level backup without interrupting the customer's business, ensuring that changed data is not lost, thereby ensuring data consistency and preventing situations such as file system damage, unavailable restored data, or data loss due to data consistency issues.

[0092] It should be noted that terms such as "up", "down", "left", "right", "front", "back", etc. cited in the invention are only for the sake of clear narration and are not used to limit the scope of implementation of the present invention. Changes or adjustments in their relative relationships, without substantial changes in technical content, should also be regarded as within the scope of implementation of the present invention.

[0093] The above is only the preferred implementation mode of the present invention. The protection scope of the present invention is not limited to the above embodiments. All technical solutions within the idea of the present invention belong to the protection scope of the present invention. It should be pointed out that for those of ordinary skill in the art in this technical field, several improvements and refinements made without departing from the principle of the present invention should be regarded as within the protection scope of the present invention.

Claims

1. A block-level data backup method, characterized in that, It includes the following steps: S1. The client service module (201) receives the backup plan sent by the console (1). S2. The client service initiates a full backup task according to the first full backup start time and full backup method set in the plan. S3. The backup task execution module (202) creates a restore point. S4. The backup task execution module (202) performs a snapshot operation on the volume to be protected in the plan to obtain a snapshot volume, and at the same time notifies the block change monitoring driver module (203) to start monitoring the changed blocks of the volume to be protected, and uses a persistent bitmap to save the information of the changed blocks. S5. Open the snapshot volume, traverse the clusters of the snapshot volume to obtain all valid clusters, that is, the clusters with file data, generate cluster bitmap information, use 1 to represent the clusters with file data, and 0 otherwise. S6. Traverse the cluster bitmap. For the bits with a value of 1, obtain the offset position according to the traversed bitmap subscript, read the data from the sector at the corresponding offset position of the snapshot volume, back up the read data and the corresponding data offset position, record the offset position for future restoration, and then delete the snapshot volume to complete the full backup task. Specifically, it includes the following steps: S61. The main thread puts the cluster bitmap information to be read into the read task queue. S62. The read thread takes a read task from the read task queue and reads the data according to the cluster bitmap information and the offset position information of the valid clusters. S63. Detect whether compression is set in the backup plan. If it is set, put the read data into the compression task queue; otherwise, execute S64. S64. Detect whether encryption is set in the backup plan. If it is set, put the read data into the encryption task queue; otherwise, put the read data into the write data task queue. S65. The compression thread takes the data from the compression queue, compresses it, and then detects whether encryption is set in the backup plan. If it is set, put the compressed data into the encryption queue; otherwise, put the compressed data into the write data task queue. S66. The encryption thread takes the data from the encryption queue, encrypts it, and then puts it into the write data queue. S67. The write data thread takes the data from the write data queue and backs it up to the backup server (3). S7. The client service initiates an incremental backup task according to the first incremental backup start time and incremental backup method set in the plan. S8. Detect whether the conditions are met. If they are met, execute step S9 of the incremental backup task; otherwise, change the backup task to a full backup and return to step S1 to perform a full backup again. S9. Perform a snapshot operation on the volume to be protected in the plan to obtain a snapshot volume, and return the snapshot volume name to the backup task execution module, and notify the block change monitoring module (203) to copy out the persistent bitmap recording the changed block information to generate a temporary bitmap to save the changed blocks of the volume to be protected from this moment. S10. The backup task execution module (202) generates a restore point, opens the snapshot volume, and traverses the incremental snapshot volume to obtain the valid cluster bitmap of the incremental snapshot volume; merge the valid cluster bitmap of the incremental snapshot volume and the persistent bitmap of the changed blocks to obtain all the changed blocks from the last backup to the snapshot during this incremental backup. S11. The backup task execution module (202) obtains the offset addresses of all changed blocks according to the merged bitmap information, reads data from the sectors corresponding to the incremental snapshot volume, backs up the read data and the corresponding data offset positions, then deletes the incremental snapshot volume, notifies the block change monitoring module (203) to clear the persistent bitmap, copies the temporary bitmap to the persistent bitmap, and deletes the temporary bitmap, thereby completing the incremental backup task.

2. The block-level data backup method according to claim 1, characterized in that In step 4, in the persistent bitmap, 1 represents a changed block and 0 represents an unchanged block, and the bitmap subscript represents the position of the block.

3. A block-level data backup system for the block-level data backup method according to claim 1, characterized in that, It includes a console (1), a client (2), and a backup server (3). The number of clients (2) and the number of backup servers (3) are both greater than or equal to 1. The client (2) includes a client service module (201), a backup task execution module (202), and a block change monitoring module (203) connected in sequence. The console (1) is used to manage the client (2) and the backup server (3), formulate a backup plan and send it to the client (2) and the backup server (3). The client service module (201) is used to receive the full backup or incremental backup plan of the user. The backup task execution module (202) is used to execute the backup task. The backup task execution module (202) includes a full backup sub-module and an incremental backup sub-module, and each sub-module is implemented through a main thread, a read thread, a compression thread, an encryption thread, and a write thread. The block change monitoring module (203) is used to monitor block changes and save the block change information in the form of a bitmap for use by the backup execution module (202).

4. The block-level data backup system according to claim 3, wherein The backup plan includes the volumes to be protected by the client, the backup server to which the backup is to be made, the start time of the first full backup, the start time of the first incremental backup, and backup settings. The backup settings include encryption and compression.

Images