Data backup and recovery methods, devices, electronic equipment and storage media
By constructing BIO metadata containing segment information to be backed up in a Linux environment and using sector granularity for backup and recovery, the data consistency problem caused by file system incompatibility is solved, and complete recovery of BIO data is achieved.
Patent Information
- Application Number
- CN202511612732.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-06
- Publication Date
- 2026-03-06
- Estimated Expiration
- 2045-11-06
AI Technical Summary
In the Linux environment, existing data backup methods suffer from file system incompatibility, making it difficult to maintain consistency after BIO data recovery. In particular, due to the differences in BIO data structures between different file systems, some segments of data are truncated or misaligned, making it impossible to reconstruct the original segment structure.
By acquiring the original BIO data of the target block device, constructing BIO metadata to be backed up that includes segment information, performing backup at the sector level, and reconstructing the data structure based on this segment information during recovery to ensure that the backup data is consistent with the original data.
It ensures that BIO data backup and recovery maintains consistency across different file systems, avoiding the problem of segment data truncation and ensuring that the restored target BIO data is completely consistent with the original data.
Smart Images

Figure CN121070696B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data processing technology, and in particular to a data backup and recovery method, apparatus, electronic device, and storage medium. Background Technology
[0002] With increasing data storage demands and system complexity, data backup has become a crucial means of protecting data security. Traditional data protection suffers from problems such as long backup windows and lengthy recovery times. Therefore, continuous data protection technology has emerged. In a Linux environment, this technology refers to the system continuously monitoring data changes and automatically saving and recording every change in BIO data in real time. In the event of a disaster or data corruption, it can quickly roll back and restore data at any point in time, thereby achieving data protection.
[0003] Current continuous data protection technologies have some issues in Linux environments, leading to inconsistencies between the target BIO data restored from the backed-up BIO data and the original BIO data after backing up the original BIO data of a client's file system to a storage server. Specifically, firstly, there is file system incompatibility. Currently, when backing up BIO data from various client file systems to a storage server, backups are performed at the block granularity (4096B). Since BIO data typically contains one or more segments, and the BIO data structures of different file systems vary, some file systems (such as EXT4) have segments of the same size (4096B) in their BIO data. In this case, backing up each segment according to the block size allows for the reconstruction of each segment during recovery, maintaining data consistency. However, in some file systems (such as XFS), the segment lengths of BIO data vary. If backups are still performed at the block size, some segments may be truncated and backed up into two separate blocks, making it difficult to reconstruct data consistent with the original BIO data during recovery. Second, the backup only records the overall information of the BIO data, lacking records of information for each segment. This results in some segments being truncated or misaligned during recovery, making it impossible to reconstruct the original segment structure and maintain consistency with the original BIO data.
[0004] Therefore, current data backup methods have a technical problem that makes it difficult to guarantee data consistency after BIO data backup and recovery, and need to be improved. Summary of the Invention
[0005] This application provides a data backup and recovery method, apparatus, electronic device, and storage medium to alleviate the technical problem that data consistency is difficult to guarantee after BIO data backup and recovery in current data backup methods.
[0006] To address the aforementioned technical problems, this application provides the following technical solutions:
[0007] This application provides a data backup and recovery method, the method comprising:
[0008] In response to a data backup request, the original BIO data of the target block device is obtained, and the BIO data to be backed up and the BIO metadata to be backed up are obtained based on the original BIO data. The BIO data to be backed up includes n segments to be backed up, where n is a positive integer. The BIO metadata to be backed up includes the first segment quantity data, the first segment length data of each segment to be backed up, and the first segment offset data of each segment to be backed up.
[0009] The sector currently pointed to by the sector pointer in the backup data disk is determined as the starting sector. Based on the starting sector, the number of the first segment, and the length of each of the first segments, a set of target sectors to be written for each segment to be backed up is determined, and each segment to be backed up is written into the corresponding set of target sectors to obtain the backed-up BIO data.
[0010] In response to a data recovery request, the segment structure of the backed-up BIO data is determined based on the first segment quantity data, the length data of each first segment, and the offset data of each first segment. The backed-up BIO data is then restored based on the segment structure to obtain the target BIO data.
[0011] In one embodiment, the step of determining a set of target sectors to be written for each of the backed-up sectors based on the starting sector, the number of the first segments, and the length of each of the first segments, and writing each of the backed-up sectors into the corresponding set of target sectors to obtain the backed-up BIO data includes:
[0012] Based on the first segment of quantity data, determine n target sectors to be written;
[0013] Based on the first segment length data and sector length data, the i-th number of the i-th target sectors to be written to the i-th segment to be backed up is obtained. The i-th number of sectors starting from the starting sector are determined as the i-th target sector. The i-th segment to be backed up is written into the i-th target sector, and the first sector after the i-th target sector is updated as the new starting sector. i is initially set to 1.
[0014] Let i equal i+1, and iteratively execute the following operations: obtaining the i-th number of target sectors to be written to the i-th segment to be backed up based on the i-th first segment length data and sector length data; determining the i-th number of sectors starting from the starting sector as the i-th target sector; writing the i-th segment to be backed up into the i-th target sector; updating the first sector after the i-th target sector to the new starting sector; and setting i equal to i+1, until i equals n, to obtain the backed-up BIO data.
[0015] In one embodiment, the step of obtaining the i-th number of the i-th target sectors to be written to the i-th segment to be backed up, based on the i-th first segment length data and the sector length data, includes:
[0016] Calculate the ratio of the length of the i-th segment to the length of the sector;
[0017] The ratio is determined as the i-th number of the i-th target sectors to be written to the i-th segment to be backed up.
[0018] In one embodiment, the step of determining the segment structure of the backed-up BIO data based on the first segment quantity data, the length data of each first segment, and the offset data of each first segment includes:
[0019] Based on the first segment quantity data, determine the second segment quantity data of the backed-up segments included in the backed-up BIO data; based on the length data of each first segment, determine the second segment length data of each backed-up segment; based on the offset data of each first segment, determine the write position of each backed-up segment in the target block device.
[0020] Based on the second segment quantity data, the second segment length data, and the write position, the segment structure of the backed-up BIO data is obtained.
[0021] In one embodiment, the step of restoring the backed-up BIO data based on the segment structure to obtain the target BIO data includes:
[0022] Based on the second segment quantity data and the second segment length data, read n backed-up segments from the backup data disk;
[0023] The backed-up segments are restored based on their corresponding write locations to obtain the target BIO data.
[0024] In one embodiment, the steps of acquiring the raw BIO data of the target block device and obtaining the BIO data to be backed up and the BIO metadata to be backed up based on the raw BIO data include:
[0025] The raw BIO data of the target block device is monitored by a monitoring program;
[0026] If the original BIO data is detected, the CDP kernel module obtains the original BIO data before it is executed, and copies and splits the original BIO data to obtain the BIO data to be backed up and the BIO metadata to be backed up.
[0027] In one embodiment, prior to the step of responding to the data backup request, the method further includes:
[0028] Receive the first creation operation of the data backup task through the first creation interface;
[0029] In response to the first creation operation, a data backup request is generated;
[0030] Prior to the steps in responding to a data recovery request, the following are also included:
[0031] Receive the second creation operation of the data recovery task through the second creation interface;
[0032] In response to the second creation operation, a data recovery request is generated.
[0033] Meanwhile, this application also provides a data backup and recovery device, the device comprising:
[0034] The first response module is used to respond to a data backup request, obtain the original BIO data of the target block device, and obtain the BIO data to be backed up and the BIO metadata to be backed up based on the original BIO data. The BIO data to be backed up includes n segments to be backed up, where n is a positive integer. The BIO metadata to be backed up includes the first segment quantity data, the first segment length data of each segment to be backed up, and the first segment offset data of each segment to be backed up.
[0035] The module is used to determine the sector currently pointed to by the sector pointer in the backup data disk as the starting sector, and to determine a set of target sectors to be written for each of the backed-up sectors based on the starting sector, the first segment quantity data and the length data of each first segment, and to write each of the backed-up sectors into the corresponding set of target sectors to obtain the backed-up BIO data.
[0036] The second response module is used to respond to a data recovery request by determining the segment structure of the backed-up BIO data based on the first segment quantity data, the length data of each first segment, and the offset data of each first segment, and then restoring the backed-up BIO data based on the segment structure to obtain the target BIO data.
[0037] This application also provides an electronic device including a memory and a processor; the memory stores an application program, and the processor is used to run the application program within the memory to perform the steps in the data backup and recovery method described in any of the preceding claims.
[0038] This application provides a computer-readable storage medium storing multiple instructions adapted for loading by a processor to execute the steps in the data backup and recovery method described above.
[0039] Beneficial Effects: This application provides a data backup and recovery method, apparatus, electronic device, and storage medium. The method first responds to a data backup request by acquiring the original BIO data of the target block device. Based on the original BIO data, it obtains the BIO data to be backed up and the BIO metadata to be backed up. The BIO data to be backed up includes n segments to be backed up, where n is a positive integer. The BIO metadata to be backed up includes the first segment quantity data, the first segment length data of each segment to be backed up, and the first segment offset data of each segment to be backed up. Then, it determines the sector currently pointed to by the sector pointer in the backup data disk as the starting sector. Based on the starting sector, the first segment quantity data, and the first segment length data, it determines a set of target sectors to be written to each segment to be backed up, and writes each segment to be backed up into the corresponding set of target sectors to obtain the backed-up BIO data. Finally, in response to a data recovery request, it determines the segment structure of the backed-up BIO data based on the first segment quantity data, the first segment length data, and the first segment offset data, and restores the backed-up BIO data based on the segment structure to obtain the target BIO data. This application constructs BIO metadata containing segment information, enabling backup of BIO data at the sector level based on this metadata. Since the segment length of each backup segment is an integer multiple of the sector length under different file systems, this backup method is compatible with file systems where the segment length is not block aligned. Each backup segment can be stored in a corresponding set of target sectors without truncation. Furthermore, during recovery, the segment structure of the backed-up BIO data can be determined first based on this segment information, and then the data can be recovered based on this segment structure. Since this segment structure is the same as the segment structure of the original BIO data, the recovered target BIO data can maintain consistency with the original BIO data. Attached Figure Description
[0040] The technical solution and other beneficial effects of this application will become apparent from the following detailed description of specific embodiments in conjunction with the accompanying drawings.
[0041] Figure 1 A schematic diagram illustrating the applicable scenarios for the data backup and recovery methods provided in the embodiments of this application.
[0042] Figure 2 This is a flowchart illustrating the data backup and recovery method provided in the embodiments of this application.
[0043] Figure 3 This is a diagram illustrating the raw BIO data in the EXT4 and XFS file systems.
[0044] Figure 4 This is a schematic diagram of the BIO metadata to be backed up in the prior art and embodiments of this application.
[0045] Figure 5This is a first schematic diagram of the first creation interface in the embodiments of this application.
[0046] Figure 6 This is a first schematic diagram of the first creation interface in the embodiments of this application.
[0047] Figure 7 This is a second schematic diagram of the first creation interface in the embodiments of this application.
[0048] Figure 8 This is a third schematic diagram of the first creation interface in the embodiments of this application.
[0049] Figure 9 This is a fourth schematic diagram of the first creation interface in the embodiments of this application.
[0050] Figure 10 This is a fifth schematic diagram of the first creation interface in the embodiments of this application.
[0051] Figure 11 This is a first schematic diagram of the second creation interface in the embodiments of this application.
[0052] Figure 12 This is a second schematic diagram of the second creation interface in the embodiments of this application.
[0053] Figure 13 This is a third schematic diagram of the second creation interface in the embodiments of this application.
[0054] Figure 14 This is a fourth schematic diagram of the second creation interface in the embodiments of this application.
[0055] Figure 15 This is a fifth schematic diagram of the second creation interface in the embodiments of this application.
[0056] Figure 16 A schematic diagram of the data backup and recovery device provided in the embodiments of this application.
[0057] Figure 17 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0058] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.
[0059] Please see Figure 1 , Figure 1This is a schematic diagram illustrating a scenario in which the data backup and recovery method provided in this application embodiment is applied. The scenario includes an application server 11 and a storage server 12. The storage server 12 includes a BIO metadata disk 121, a BIO data disk 122, and a full data disk 123. The application server 11 shares these disks with the storage server 12 through network sharing protocols such as NFS or iSCSI. The application server 11 includes a backup program 111 and a CDP (Continuous Data Protection) kernel module 112. Both of them perform continuous data protection on the target block device 113 based on the Linux environment. Specifically, application server 11 first performs a full backup of target block device 113 using backup program 111. The full backup data is stored in full data disk 123 via network sharing technology. Then, incremental backup is performed. Backup program 111 sends a monitoring command to CDP kernel module 112. Upon receiving the command, CDP kernel module 112 listens for user I / O operations. After detecting a user I / O operation, it intercepts the corresponding original BIO data before it is executed by target block device 113, and splits it into BIO data to be backed up and BIO metadata to be backed up, storing them in BIO data disk 122 and BIO metadata disk 121 respectively. When a data recovery command is received, the backed-up BIO metadata and backed-up BIO data are read from the corresponding disks of storage server 12. The target BIO data is reconstructed based on the two and restored to target block device 113. In the following embodiments, the specific implementation process of the data backup and recovery method will be further explained in conjunction with this scenario.
[0060] Please see Figure 2 , Figure 2 This is a flowchart illustrating the data backup and recovery method provided in this application embodiment. The method specifically includes:
[0061] S1: In response to the data backup request, obtain the original BIO data of the target block device, and obtain the BIO data to be backed up and the BIO metadata to be backed up based on the original BIO data. The BIO data to be backed up includes n segments to be backed up, where n is a positive integer. The BIO metadata to be backed up includes the first segment quantity data, the first segment length data of each segment to be backed up, and the first segment offset data of each segment to be backed up.
[0062] The target block device refers to the device that requires continuous data protection. This device uses blocks as the unit of read and write operations. Raw BIO (Block I / O Vector) data refers to a data structure describing user I / O operations. Raw BIO data may include one or more raw segments. The data backup referred to in this application refers to backing up the raw BIO data after incremental backup has begun. The data backup and recovery methods in this application are applicable to the Linux environment.
[0063] When a user wants to perform an incremental backup of a target block device, they initiate a data backup request. Upon receiving the data backup request, the application server responds by first retrieving the original BIO data, then processing it to obtain the BIO data to be backed up and the BIO metadata to be backed up. The BIO data to be backed up refers to the data that is identical to the original BIO data and needs to be written to the BIO data disk of the storage service server for backup. The BIO metadata to be backed up refers to data selected from the BIO data to be backed up, used to provide a reference for backup and recovery, and also needs to be written to the BIO metadata disk of the storage service server for backup.
[0064] The BIO data to be backed up consists of n segments, where n is a positive integer. For different file systems on the target block device, the segment length of each segment may or may not be aligned with the block size. Specifically, each block in the block device is 4096 bytes. When the file system is EXT4, the segment length of each segment to be backed up is one block size, also 4096 bytes. However, when the file system is XFS, the segment lengths vary and may be smaller than one block size, such as 512 bytes, 1024 bytes, etc. But regardless of the file system, in the Linux environment, the segment length is always an integer multiple of the sector length (512 bytes).
[0065] The BIO metadata to be backed up includes the first segment quantity data, the first segment length data of each segment to be backed up, and the first segment offset data of each segment to be backed up. The first segment of data indicates that the BIO data to be backed up contains n segments. The length data L1 to Ln of each segment indicates the length of each segment to be backed up. The offset data W1 to Wn of each segment is used to locate the write position of each segment in the corresponding block of the target block device. For example, if three segments to be backed up correspond to the same block in the target block device, and the lengths of the three segments are 1024B, 1024B, and 512B respectively, then the offset data W1 of the first segment to be backed up is 0, indicating that the segment is written from the beginning of the corresponding block without offset. The offset data W2 of the second segment to be backed up is 1024B, indicating that the segment starts writing 1024B from the beginning of the corresponding block with an offset of 1024B. The offset data W3 of the third segment to be backed up is 2048B, indicating that the segment starts writing 2048B from the beginning of the corresponding block with an offset of 2048B.
[0066] In addition to the BIO metadata to be backed up, other basic data of the BIO data to be backed up also include BIO execution time, BIO size, sector number of the disk operated on, and the location of the data blocks carried by the BIO in the backup file. This data is also used to provide a reference for backup and recovery.
[0067] In one embodiment, S1 specifically includes:
[0068] S11: Listen to the raw BIO data of the target block device through the listening program.
[0069] S12: If raw BIO data is detected, the CDP kernel module obtains the raw BIO data before it is executed, and copies and splits the raw BIO data to obtain the BIO data to be backed up and the BIO metadata to be backed up.
[0070] After incremental backup begins, user I / O of the target block device is submitted to the BIO queue. The application server listens to see if the BIO queue is empty. If it is empty, it continues to listen. If it is not empty, it means that there is a new user I / O. At this time, the CDP kernel module intercepts the original BIO data corresponding to the user I / O before it is executed by the target block device, copies and splits it to obtain the BIO data and metadata to be backed up, and performs subsequent backup operations. The original BIO data will continue to be executed normally.
[0071] Through the above process, a synchronization mechanism is introduced to ensure that the backup operation of the original BIO data precedes the actual operation, avoiding the staleness of the backup data due to the concurrent order, and further ensuring the real-time performance and accuracy of continuous data protection.
[0072] S2: Determine the sector currently pointed to by the sector pointer in the backup data disk as the starting sector. Based on the starting sector, the number of the first segment, and the length of each first segment, determine a set of target sectors to be written for each segment to be backed up. Write each segment to be backed up into the corresponding set of target sectors to obtain the backed-up BIO data.
[0073] The backup data disk refers to the BIO data disk in the storage server. This disk is mainly used for writing BIO data to be backed up, resulting in backup files. The backup data disk performs backups at the sector level, meaning that data is written sector by sector. The first sector that can be written to the backup data disk is the starting sector, indicated by a sector pointer. The BIO data to be backed up consists of n segments. Writing these n segments to a set of target sectors yields the backed-up BIO data. The position and number of the target sectors (including at least one sector) corresponding to each segment are determined based on the starting sector, the number of segments in the first segment, and the length of each segment.
[0074] In one embodiment, S2 specifically includes:
[0075] S21: Based on the first segment of quantity data, determine the n target sectors to be written.
[0076] S22: Based on the first segment length data and the sector length data, obtain the i-th number of the i-th target sectors to be written to the i-th segment to be backed up. Determine the i-th number of sectors starting from the starting sector as the i-th target sector. Write the i-th segment to be backed up into the i-th target sector and update the first sector after the i-th target sector to the new starting sector. i is initially 1.
[0077] S23: Let i equal i+1, and repeatedly execute the following operations: obtaining the i-th number of target sectors to be written to the i-th segment to be backed up based on the i-th first segment length data and sector length data; determining the i-th number of sectors starting from the starting sector as the i-th target sector; writing the i-th segment to be backed up into the i-th target sector; updating the first sector after the i-th target sector to the new starting sector; and setting i equal to i+1, until i equals n, to obtain the backed-up BIO data.
[0078] Since each segment to be backed up needs to be written to a set of target sectors, the number of BIO data to be backed up can be determined based on the first segment's quantity data, which indicates that n sets of target sectors need to be written. For ease of explanation, n is set to 3 in this embodiment.
[0079] Let i equal 1. Starting from the first segment to be backed up, based on the first segment length and sector length, the first number n1 of the first group of target sectors to be written to the first segment to be backed up can be determined. Since the first segment to be backed up needs to be written starting from the starting sector, the first group of target sectors includes n1 sectors starting from the starting sector. After writing the first segment to be backed up into the first group of target sectors, the first sector that can be written to the backup data disk is the first sector after the first group of target sectors. At this time, this sector is updated to the new starting sector, and the sector pointer is set to this sector.
[0080] Let i equal i+1, now i equals 2. For the second segment to be backed up, based on the same principle, we first determine the second number n2 of the second group of target sectors to be written to the second segment based on the length of the first segment and the sector length. Since the second segment to be backed up needs to be written starting from a new starting sector, the second group of target sectors includes n2 sectors starting from the new starting sector. After writing the second segment to be backed up into the second group of target sectors, the first sector that can be written to the backup data disk is the first sector after the second group of target sectors. At this time, update this sector to the new starting sector and point the sector pointer to this sector.
[0081] Repeat the above steps to write each segment to be backed up into the corresponding set of target sectors in sequence, thus completing the sector-level backup of the BIO data to be backed up and obtaining the backed-up BIO data.
[0082] In one embodiment, S22 specifically includes:
[0083] S221: Calculate the ratio of the length of the i-th first segment to the length of the sector.
[0084] S222: Determine the ratio as the i-th number of the i-th target sectors to be written to the i-th segment to be backed up.
[0085] Specifically, the number of the i-th target sectors in the i-th group is the sum of the length of the first segment and the sector length. For example, if the segment lengths of the first to third segments to be backed up are 512B, 2048B, and 4096B respectively, and the sector length is 512B for each segment, then the number of the first target sectors in the first group, n1, is 512B / 512B = 1; the number of the second target sectors in the second group, n2, is 2048B / 512B = 4; and the number of the third target sectors in the third group, n3, is 4096B / 512B = 8. Since the BIO segment length of various file systems in the Linux environment is always an integer multiple of the sector length, the number of target sectors determined by this method is also an integer, and data will not be truncated when writing each segment to be backed up.
[0086] S3: In response to the data recovery request, determine the segment structure of the backed-up BIO data based on the first segment quantity data, the length data of each first segment, and the offset data of each first segment, and restore the backed-up BIO data based on the segment structure to obtain the target BIO data.
[0087] When a user wants to restore the backed-up BIO data of the target block device, a data recovery request is initiated. After receiving the data recovery request, the application server responds by first determining the segment structure of the backed-up BIO data based on the first segment quantity data, the length data of each first segment, and the offset data of each first segment. Then, based on the segment structure, the backed-up BIO data is restored into multiple backed-up BIO segments and written to the target block device to obtain the target BIO data.
[0088] Since the first segment quantity data, the length data of each first segment, and the offset data of each first segment are derived from the original BIO data, the segment structure of the backed-up BIO data determined based on these data is consistent with the segment structure of the original BIO data. Therefore, the target BIO data to be restored will also be consistent with the segment structure of the original BIO data.
[0089] In one embodiment, S3 specifically includes:
[0090] S31: Based on the first segment quantity data, determine the second segment quantity data of the backed-up segments included in the backed-up BIO data; based on the length data of each first segment, determine the second segment length data of each backed-up segment; based on the offset data of each first segment, determine the write position of each backed-up segment in the target block device.
[0091] S32: Based on the second segment quantity data, the length data of each second segment, and each write position, obtain the segment structure of the backed-up BIO data.
[0092] When determining the segment structure, firstly, the number of the second segment contained in the backed-up BIO data is determined based on the first segment quantity data. Since the second segment quantity data is equal to the first segment quantity data, when the BIO data to be backed up includes n segments to be backed up, the backed-up BIO data also includes n backed-up BIO segments. Next, the second segment length data of each backed-up segment is determined based on the length data of each first segment. Since the second segment length of each backed-up BIO segment is equal to the first segment length of each segment to be backed up, when the first segment lengths of the n segments to be backed up are L1 to Ln respectively, the second segment lengths of the n backed-up BIO segments are also L1 to Ln respectively. Finally, the write position of each backed-up segment in the target block device is determined based on the offset data of each first segment. Since the write positions are the same, when the first segment offset data of the n segments to be backed up are W1 to Wn respectively, the second offset data of the n backed-up BIO segments are also W1 to Wn respectively. These data can locate the write position of each backed-up segment in the corresponding block of the target block device. Based on the second segment quantity data n, n second segment length data L1 to Ln, and n write positions, the segment structure of the backed-up BIO data can be obtained.
[0093] In one embodiment, S3 specifically includes:
[0094] S33: Based on the second segment quantity data and the second segment length data, read n backed-up segments from the backup data disk.
[0095] S34: Restore each backed-up segment based on its corresponding write position to obtain the target BIO data.
[0096] After obtaining the segment structure of the backed-up BIO data, n backed-up segments are read from the backup data disk according to the second segment quantity data n. The second segment lengths of the n backed-up segments are L1 to Ln, respectively. According to the first to nth write positions, the first to nth backed-up segments are written to the corresponding write positions of the target block device, resulting in n target BIO segments. These target BIO segments together constitute the target BIO data.
[0097] In one embodiment, the process further includes the following step before S1:
[0098] S1a: Receive the first creation operation of the data backup task through the first creation interface.
[0099] S1b: In response to the first creation operation, generate a data backup request.
[0100] Prior to S3, it also included:
[0101] S3a: Receive the second creation operation of the data recovery task through the second creation interface.
[0102] S3a: In response to the second creation operation, generate a data recovery request.
[0103] In this embodiment, both data backup requests and data recovery requests can be generated by configuring the front-end interface of the backup product, and the data backup and data recovery tasks will be completed automatically after generation.
[0104] Specifically, the application server displays a first creation interface to the user, receives the user's initial creation operation for the data backup task through this interface, and then generates a data backup request in response to this operation. For example... Figure 5 and Figure 6 As shown, the user first selects the CDP backup object on the first creation interface. The application server responds to this operation by determining the target block device to be backed up, and then proceeds as follows: Figure 7 As shown, the user selects a storage pool on the first creation interface. The application server responds to this operation by determining the backup data disk to be written to, and then proceeds as follows: Figure 8 As shown, the user configures the CDP backup strategy on the first creation interface. The application server responds to this operation by determining information such as the backup cycle, backup time point, and data retention window. After configuration, as shown... Figure 9 As shown, you can preview all configured information to see if it meets expectations. Finally, click "OK" to complete the creation of the data backup task. After creation, the application server can generate a data backup request based on this task and automatically execute the data backup steps in S1 and S2. Figure 10 As shown, you can also view the details of created tasks in the relevant interface.
[0105] The application server displays a second creation interface to the user and receives the user's second creation operation for the data recovery task through this interface. For example... Figure 11 As shown, the user first selects the recovery object on the second creation interface. The application server responds to this operation by determining the backup file to be recovered, and then... Figure 12 and Figure 13 As shown, on the second creation interface, the user selects the recovery target. The application server responds to this operation by determining information such as the backup time range, recovery time point, recovery target host, and recovery volume. After configuration, as shown... Figure 14 As shown, you can preview all configured information to see if it meets expectations. Finally, click "OK" to complete the creation of the data recovery task. After creation, the application server can generate a data recovery request based on this task and automatically execute the data recovery steps in S3. Figure 15 As shown, you can also view the details of created tasks in the relevant interface.
[0106] This application allows users to automatically complete the data backup and recovery steps from S1 to S3 simply by performing configuration operations on the relevant interfaces. The operation is simple, and the status can be queried throughout the process, enabling timely awareness of whether the data backup and recovery are in good condition, thus ensuring high reliability of continuous data protection.
[0107] In existing technologies, when backing up BIO data from various file systems of customers to storage servers, backups are performed at the block granularity (4096B). Since BIO data usually contains one or more segments, and the BIO data structure varies between different file systems, some file systems (such as EXT4) have each segment of BIO data with a segment length of one block size (4096B). In this case, backing up each segment according to the block size allows each block to be reconstructed during recovery, maintaining data consistency. However, in some file systems (such as XFS), the segment lengths of BIO data vary. If backups are still performed according to the block size, some segments will be truncated and backed up into two separate blocks. During recovery, the reconstructed data will be difficult to keep consistent with the original BIO data.
[0108] Specifically, such as Figure 3 As shown, for the EXT4 file system, assuming the original BIO data contains segment 1 and segment 2, with segment length "bv_len" of 4096 bytes and segment offset "bv_offset" of 0, and since each block in the backup data disk is also 4096 bytes long, when backing up segment 1 and segment 2, segment 1 will be backed up to block 1' and segment 2 to block 2', and both segments 1 and 2 will be written starting from the beginning of block 1' and block 2', respectively. After the backup is complete, the size of block 1' and block 2' will both be 4096 bytes. Because this backup method does not change the structure of segment 1 and segment 2, a structure consistent with the original BIO data can be obtained during data recovery.
[0109] For the XFS file system, assuming the original BIO data contains segments 1, 2, and 3, with segment 1 having a length "bv_len" of 512 bytes and a segment offset "bv_offset" of 0, segment 2 having a length "bv_len" of 2048 bytes and a segment offset "bv_offset" of 512 bytes, and segment 3 having a length "bv_len" of 4096 bytes and a segment offset "bv_offset" of 2560 bytes, since each block in the backup data disk is 4096 bytes long, backing up segments 1, 2, and 3 will back up the entire first half of segments 1, 2, and 3 (a total of 4096 bytes) to block 1', and the second half of segment 3 to block 2', resulting in segment 3 being truncated. Because this backup method alters the structure of each segment, the target BIO data obtained during subsequent data recovery based on the changed structure will obviously not match expectations, leading to the inability to function properly after recovery.
[0110] To address the aforementioned issues, this embodiment of the application changes the original block-level backup to sector-level backup. That is, the backup data disk is no longer stored in blocks but in sectors. Regardless of the file system, in a Linux environment, the segment length is always an integer multiple of the sector length. Therefore, no matter how many segments the original BIO data includes or what the segment length of each segment is, it can be backed up in an integer number of sectors, preventing a segment from being truncated to two sectors.
[0111] In addition, such as Figure 4 As shown, the existing technology's BIO metadata (formerly Metalnfo) only includes basic data of the BIO data to be backed up. Among them, "time" represents the BIO execution time, "bi_size" represents the BIO size, "backup_sect" represents the sector number of the disk operated by B, and "snap_sect" represents the location of the data block carried by the BIO in the backup file. Therefore, during recovery, based on the above BIO metadata, it can only determine that data recovery of the backed-up BIO data is required. It cannot determine how many segments need to be recovered, the length of each segment, or the write position of each segment during recovery. In other words, it cannot determine the segment structure, which will also lead to the inability to recover target BIO data that is consistent with the original BIO data.
[0112] To solve the above problems, such as Figure 4As shown in the embodiment of this application, a "segments_info" field is added to the BIO metadata to be backed up (the improved Metalnfo). In this field, "num_segments" represents the number of segments, "bv_offsets" represents the length of the first segment of each segment to be backed up, and "bv_lens" represents the offset of the first segment of each segment to be backed up. After this addition, the BIO metadata to be backed up contains not only the basic data of the BIO data to be backed up, but also segment information. Based on this segment information, the segment structure of the backed-up BIO data can be determined, and since this segment structure is consistent with the segment structure of the original BIO data, the target BIO data restored based on this can be guaranteed to be consistent with the original BIO data.
[0113] Based on the methods described in the above embodiments, this embodiment will further describe the methods from the perspective of data backup and recovery devices. Please refer to... Figure 16 Data backup and recovery devices may include:
[0114] The first response module 10 is used to respond to a data backup request, obtain the original BIO data of the target block device, and obtain the BIO data to be backed up and the BIO metadata to be backed up based on the original BIO data. The BIO data to be backed up includes n segments to be backed up, where n is a positive integer. The BIO metadata to be backed up includes the first segment quantity data, the first segment length data of each segment to be backed up, and the first segment offset data of each segment to be backed up.
[0115] The module 20 is used to determine the sector currently pointed to by the sector pointer in the backup data disk as the starting sector, and to determine a set of target sectors to be written for each of the backed-up sectors based on the starting sector, the first segment quantity data and the length data of each first segment, and to write each of the backed-up sectors into the corresponding set of target sectors to obtain the backed-up BIO data.
[0116] The second response module 30 is used to respond to a data recovery request by determining the segment structure of the backed-up BIO data based on the first segment quantity data, the length data of each first segment, and the offset data of each first segment, and then restoring the backed-up BIO data based on the segment structure to obtain the target BIO data.
[0117] In one embodiment, the obtaining module 20 includes:
[0118] The first determining submodule is used to determine n target sectors to be written based on the first segment of quantity data;
[0119] The write submodule is used to obtain the i-th number of the i-th target sectors to be written to the i-th segment to be backed up based on the i-th first segment length data and sector length data, determine the i-th number of sectors starting from the starting sector as the i-th target sector, write the i-th segment to be backed up into the i-th target sector, and update the first sector after the i-th target sector to the new starting sector, with i initially set to 1;
[0120] The loop submodule is used to set i equal to i+1 and loop through the following operations: obtaining the i-th number of target sectors to be written to the i-th segment to be backed up based on the i-th first segment length data and sector length data; determining the i-th number of sectors starting from the starting sector as the i-th group of target sectors; writing the i-th segment to be backed up into the i-th group of target sectors; updating the first sector after the i-th group of target sectors to the new starting sector; and setting i equal to i+1, until i equals n, to obtain the backed-up BIO data.
[0121] In one embodiment, the first write submodule includes:
[0122] The calculation unit is used to calculate the ratio of the length of the i-th first segment to the length of the sector;
[0123] The determining unit is used to determine the ratio as the i-th number of the i-th group of target sectors to be written to the i-th segment to be backed up.
[0124] In one embodiment, the second response module 30 includes:
[0125] The second determining submodule is used to determine the second segment quantity data of the backed-up segments included in the backed-up BIO data based on the first segment quantity data, determine the second segment length data of each of the backed-up segments based on the length data of each of the first segments, and determine the write position of each of the backed-up segments in the target block device based on the offset data of each of the first segments.
[0126] The first submodule is used to obtain the segment structure of the backed-up BIO data based on the second segment quantity data, the second segment length data, and the write position.
[0127] In one embodiment, the second response module 30 includes:
[0128] The reading submodule is used to read n backed-up segments from the backup data disk based on the second segment quantity data and the second segment length data;
[0129] The recovery submodule is used to restore each of the backed-up segments based on the corresponding write position to obtain the target BIO data.
[0130] In one embodiment, the first response module 10 includes:
[0131] The listening submodule is used to listen to the raw BIO data of the target block device through a listening program;
[0132] The second submodule is used to, if the original BIO data is detected, obtain the original BIO data through the CDP kernel module before the original BIO data is executed, and copy and split the original BIO data to obtain the BIO data to be backed up and the BIO metadata to be backed up.
[0133] In one embodiment, the apparatus further includes a first receiving module and a first generating module that operate before the first response module 10. The first receiving module is configured to receive a first creation operation of a data backup task through a first creation interface, and the first generating module is configured to generate a data backup request in response to the first creation operation. The apparatus further includes a second receiving module and a second generating module that operate before the second response module 30. The second receiving module is configured to receive a second creation operation of a data recovery task through a second creation interface, and the second generating module is configured to generate a data recovery request in response to the second creation operation.
[0134] Unlike existing technologies, the data backup and recovery device provided in this application constructs BIO metadata containing segment information, enabling backup of the BIO data at the sector level based on this metadata. Since the segment length of each backup segment under different file systems is an integer multiple of the sector length, this backup method is compatible with file systems whose segment lengths are not block aligned. Each backup segment can be stored in a corresponding set of target sectors without truncation issues. Furthermore, during recovery, the segment structure of the backed-up BIO data can be determined first based on this segment information, and then the data can be recovered based on this segment structure. Since this segment structure is the same as the segment structure of the original BIO data, the recovered target BIO data can maintain consistency with the original BIO data.
[0135] Accordingly, embodiments of this application also provide an electronic device, such as... Figure 17 As shown, the electronic device may include a radio frequency (RF) circuit 101, a memory 102 including one or more computer-readable storage media, an input unit 103, a display unit 104, a sensor 105, an audio circuit 106, a WiFi module 107, a processor 108 including one or more processing cores, and a power supply 109, among other components. Those skilled in the art will understand that... Figure 17The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein:
[0136] The radio frequency circuit 101 can be used for receiving and transmitting signals during information transmission or calls. Specifically, it receives downlink information from the base station and hands it over to one or more processors 108 for processing; additionally, it transmits uplink data to the base station. The memory 102 can be used to store software programs and modules. The processor 108 executes various functional applications and performs data backup and recovery by running the software programs and modules stored in the memory 102. The input unit 103 can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical, or trackball signal inputs related to customer settings and function control.
[0137] Display unit 104 can be used to display information input by the customer or information provided to the customer, as well as various graphical client interfaces of the server. These graphical client interfaces can be composed of graphics, text, icons, videos, and any combination thereof.
[0138] The electronic device may also include at least one sensor 105, such as a light sensor, a motion sensor, and other sensors. Audio circuitry 106 includes a speaker that provides an audio interface between the client and the electronic device.
[0139] WiFi is a wireless transmission technology. Electronic devices using the WiFi module 107 can help customers send and receive emails, browse web pages, and access streaming media, providing customers with wireless broadband internet access. Although Figure 17 WiFi module 107 is shown, but it is understood that it is not a necessary component of the electronic device and can be omitted as needed without changing the nature of the application.
[0140] The processor 108 is the control center of the electronic device. It connects various parts of the phone through various interfaces and lines. By running or executing software programs and / or modules stored in the memory 102, and calling data stored in the memory 102, it performs various functions of the electronic device and processes data, thereby monitoring the phone as a whole.
[0141] The electronic device also includes a power supply 109 (such as a battery) that supplies power to the various components. Preferably, the power supply can be logically connected to the processor 108 through a power management system, thereby enabling functions such as managing charging, discharging, and power consumption through the power management system.
[0142] Although not shown, electronic devices may also include cameras, Bluetooth modules, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 108 in the server loads the executable files corresponding to the processes of one or more applications into the memory 102 according to the following instructions, and the processor 108 runs the applications stored in the memory 102 to achieve the following functions:
[0143] In response to a data backup request, the original BIO data of the target block device is obtained, and the BIO data to be backed up and the BIO metadata to be backed up are obtained based on the original BIO data. The BIO data to be backed up includes n segments to be backed up, where n is a positive integer. The BIO metadata to be backed up includes the first segment quantity data, the first segment length data of each segment to be backed up, and the first segment offset data of each segment to be backed up.
[0144] The sector currently pointed to by the sector pointer in the backup data disk is determined as the starting sector. Based on the starting sector, the number of the first segment, and the length of each of the first segments, a set of target sectors to be written for each segment to be backed up is determined, and each segment to be backed up is written into the corresponding set of target sectors to obtain the backed-up BIO data.
[0145] In response to a data recovery request, the segment structure of the backed-up BIO data is determined based on the first segment quantity data, the length data of each first segment, and the offset data of each first segment. The backed-up BIO data is then restored based on the segment structure to obtain the target BIO data.
[0146] The electronic device provided in this application constructs BIO metadata containing segment information, enabling the backup of BIO data to be performed at the sector level based on this metadata. Since the segment length of each backup segment under different file systems is an integer multiple of the sector length, this backup method is compatible with file systems whose segment lengths are not block aligned. Each backup segment can be stored in a corresponding set of target sectors without truncation. Furthermore, during recovery, the segment structure of the backed-up BIO data can be determined first based on this segment information, and then the backed-up BIO data can be recovered based on this segment structure. Since this segment structure is the same as the segment structure of the original BIO data, the recovered target BIO data can maintain consistency with the original BIO data.
[0147] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the detailed description above, which will not be repeated here.
[0148] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.
[0149] Therefore, embodiments of this application provide a computer-readable storage medium storing a plurality of instructions that can be loaded by a processor to perform the following functions:
[0150] In response to a data backup request, the original BIO data of the target block device is obtained, and the BIO data to be backed up and the BIO metadata to be backed up are obtained based on the original BIO data. The BIO data to be backed up includes n segments to be backed up, where n is a positive integer. The BIO metadata to be backed up includes the first segment quantity data, the first segment length data of each segment to be backed up, and the first segment offset data of each segment to be backed up.
[0151] The sector currently pointed to by the sector pointer in the backup data disk is determined as the starting sector. Based on the starting sector, the number of the first segment, and the length of each of the first segments, a set of target sectors to be written for each segment to be backed up is determined, and each segment to be backed up is written into the corresponding set of target sectors to obtain the backed-up BIO data.
[0152] In response to a data recovery request, the segment structure of the backed-up BIO data is determined based on the first segment quantity data, the length data of each first segment, and the offset data of each first segment. The backed-up BIO data is then restored based on the segment structure to obtain the target BIO data.
[0153] The computer-readable storage medium provided in this application constructs BIO metadata containing segment information, enabling the backup of BIO data to be performed at the sector level based on this metadata. Since the segment length of each backup segment under different file systems is an integer multiple of the sector length, this backup method is compatible with file systems whose segment lengths are not block aligned. Each backup segment can be stored in a corresponding set of target sectors without truncation issues. Furthermore, during recovery, the segment structure of the backed-up BIO data can be determined first based on this segment information, and then the backed-up BIO data can be recovered based on this segment structure. Since this segment structure is the same as the segment structure of the original BIO data, the recovered target BIO data can maintain consistency with the original BIO data.
[0154] The foregoing has provided a detailed description of a data backup and recovery method, apparatus, electronic device, and computer-readable storage medium provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the technical solutions and core ideas of this application. Those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.
Claims
1. A backup and recovery method of data, characterized by, The method comprises: in response to a data backup request, obtaining original BIO data of a target block device, obtaining to-be-backed-up BIO data and to-be-backed-up BIO metadata according to the original BIO data, the to-be-backed-up BIO data comprising n to-be-backed-up segments, n being a positive integer, a segment length of each to-be-backed-up segment being an integer multiple of a sector length, the to-be-backed-up BIO metadata comprising first segment quantity data, first segment length data of each to-be-backed-up segment, and first segment offset data of each to-be-backed-up segment; determining a sector currently pointed to by a sector pointer in a backup data disk as a starting sector, determining a group of target sectors to be written into by each to-be-backed-up segment according to the starting sector, the first segment quantity data, and the first segment length data, and writing each to-be-backed-up segment into a corresponding group of target sectors, to obtain backed-up BIO data; in response to a data recovery request, determining a segment structure of the backed-up BIO data according to the first segment quantity data, the first segment length data, and the first segment offset data, and recovering the backed-up BIO data based on the segment structure, to obtain target BIO data.
2. The backup and restoration method of data according to claim 1, characterized in that, The step of determining a group of target sectors to be written into by each to-be-backed-up segment according to the starting sector, the first segment quantity data, and the first segment length data, and writing each to-be-backed-up segment into a corresponding group of target sectors, to obtain backed-up BIO data, comprises: determining n groups of target sectors to be written into according to the first segment quantity data; obtaining an ith number of an ith group of target sectors to be written into by an ith to-be-backed-up segment according to the ith first segment length data and sector length data, determining an ith number of sectors starting from the starting sector as the ith group of target sectors, writing the ith to-be-backed-up segment into the ith group of target sectors, updating a first sector after the ith group of target sectors as a new starting sector, and setting i equal to i+1, i being initially 1; setting i equal to i+1, and repeatedly performing the operations of obtaining an ith number of an ith group of target sectors to be written into by an ith to-be-backed-up segment according to the ith first segment length data and sector length data, determining an ith number of sectors starting from the starting sector as the ith group of target sectors, writing the ith to-be-backed-up segment into the ith group of target sectors, updating a first sector after the ith group of target sectors as a new starting sector, and setting i equal to i+1, until i is equal to n, to obtain the backed-up BIO data.
3. The backup and restoration method of data according to claim 2, characterized in that, The step of obtaining an ith number of an ith group of target sectors to be written into by an ith to-be-backed-up segment according to the ith first segment length data and sector length data comprises: calculating a ratio of the ith first segment length to the sector length; determining the ratio as the ith number of the ith group of target sectors to be written into by the ith to-be-backed-up segment.
4. The backup and restoration method of data according to claim 2, characterized in that, The step of determining a segment structure of the backed-up BIO data according to the first segment quantity data, the first segment length data, and the first segment offset data comprises: According to the first segment quantity data, second segment quantity data of backup segments contained in the backup BIO data is determined, according to each first segment length data, second segment length data of each backup segment is determined, and according to each first segment offset data, a write position of each backup segment in the target block device is determined; According to the second segment quantity data, each second segment length data and each write position, a segment structure of the backup BIO data is obtained.
5. The backup and restoration method of data according to claim 4, characterized in that, The step of restoring the backup BIO data based on the segment structure to obtain target BIO data comprises: According to the second segment quantity data and the second segment length data, n backup segments are read from the backup data disk; Each backup segment is restored based on the corresponding write position to obtain target BIO data.
6. The backup and restoration method of data according to claim 1, characterized in that, The step of obtaining original BIO data of a target block device and obtaining backup BIO data and backup BIO metadata according to the original BIO data comprises: The original BIO data of the target block device is monitored by a listener program; If the original BIO data is monitored, the original BIO data is obtained by a CDP kernel module before the original BIO data is executed, and the original BIO data is copied and split to obtain backup BIO data and backup BIO metadata.
7. The backup and restoration method of data according to claim 1, characterized in that, Before the step of responding to a data backup request, it further comprises: A first creation operation of a data backup task is received through a first creation interface; A data backup request is generated in response to the first creation operation; Before the step of responding to a data recovery request, it further comprises: A second creation operation of a data recovery task is received through a second creation interface; A data recovery request is generated in response to the second creation operation.
8. A backup and recovery apparatus of data, characterized by, The device comprises: A first response module for obtaining original BIO data of a target block device in response to a data backup request, and obtaining backup BIO data and backup BIO metadata according to the original BIO data, the backup BIO data comprising n backup segments, n being a positive integer, the segment length of each backup segment being an integer multiple of the sector length, the backup BIO metadata comprising first segment quantity data, first segment length data of each backup segment, and first segment offset data of each backup segment; A determination module for determining a starting sector as a sector currently pointed to by a sector pointer in a backup data disk, determining a group of target sectors to be written into by each backup segment according to the starting sector, the first segment quantity data and the first segment length data, and writing each backup segment into the corresponding group of target sectors to obtain backup BIO data; A second response module for determining a segment structure of the backup BIO data according to the first segment quantity data, the first segment length data and the first segment offset data in response to a data recovery request, and restoring the backup BIO data based on the segment structure to obtain target BIO data.
9. An electronic device, comprising: The application comprises a memory and a processor; the memory stores an application program, and the processor is used to run the application program in the memory to execute the steps in the data backup and recovery method according to any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The computer program is stored on the computer readable storage medium and is executed by the processor to implement the steps in the data backup and recovery method according to any one of claims 1 to 7.
Citation Information
Patent Citations
Method and system for continuous data protection
CN116601611A
Method for improving CDP real-time data backup speed
CN118733348A