Data backup device, method, equipment and storage medium

Abstract

The present application discloses a data backup device, method, equipment and storage medium, which relates to the field of data processing technology. When target data is generated, the target data is stored in the first memory module, so that the business system can timely obtain and process the target data in the first memory module, and write the target data to the system disk through the first write path to complete the initial storage of the target data; after confirming that the target data is successfully written to the system disk, the target data is stored in the second memory module, and then the target data is written to the back-end disk using the second write path. When the target data is written to the back-end disk, it does not affect the business system's reading and writing of the data in the first memory module. Thus, through asynchronous means and independent write paths, the target data is written to the system disk and the back-end disk respectively, which realizes timely backup of the target data and can reduce the impact on system performance.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a data backup device, method, equipment and storage medium. Background Art

[0002] In today's digital age, various systems are widely used in various fields, supporting the normal operation of businesses. However, during the actual operation of these systems, they face many unpredictable problems, such as hardware failures, software vulnerabilities, and cyber attacks. Once these problems occur, they are likely to cause the system to malfunction and even result in data loss or corruption.

[0003] Therefore, during the system development phase, effective system recovery in various disaster scenarios must be carefully considered. When a system failure occurs that cannot be automatically repaired, pre-backed-up data becomes crucial for business recovery. Related technologies primarily perform data backup through real-time or non-real-time backup. However, these data backup methods fail to guarantee timely backups while minimizing the impact on system performance. Summary of the Invention

[0004] The present application provides a data backup device, method, equipment and storage medium to at least solve the problem that the data backup method in the related art cannot ensure the timeliness of data backup while reducing the impact on system performance.

[0005] In a first aspect, the present application provides a data backup device, comprising:

[0006] A first memory module, a second memory module, a processor, a system disk, and a backend disk; the processor is communicatively connected to the first memory module, the second memory module, the system disk, and the backend disk; the first memory module is communicatively connected to the system disk, and the second memory module is communicatively connected to the backend disk;

[0007] a processor, configured to, in response to receiving the target data, store the target data in a first memory module and write the target data to a system disk via a first write path, wherein the first memory module is configured to communicate with a business system so that the business system reads and writes the target data stored in the first memory module;

[0008] The processor is further configured to, in response to determining that the target data is written to the system disk, store the target data in the second memory module and write the target data to the backend disk through the second write path.

[0009] In a second aspect, the present application also provides a data backup method, comprising:

[0010] In response to receiving the target data, the target data is stored in the first memory module and the target data is written to the system disk via the first write path, the first memory module being used to communicate with the business system so that the business system reads and writes the target data stored in the first memory module;

[0011] In response to determining that the target data is written to the system disk, the target data is stored in the second memory module, and the target data is written to the backend disk through the second write path.

[0012] In a third aspect, the present application further provides an electronic device, comprising:

[0013] memory for storing computer programs;

[0014] A processor is used to implement the steps of the data backup method of the second aspect when executing a computer program.

[0015] In a fourth aspect, the present application further provides a computer-readable storage medium, in which a computer program is stored, wherein when the computer program is executed by a processor, the steps of the data backup method of the second aspect are implemented.

[0016] In a fifth aspect, the present application also provides a computer program product, including a computer program, which implements the steps of the data backup method in the second aspect when executed by a processor.

[0017] The data backup device, method, equipment and storage medium provided by the present application, the data backup device includes a first memory module, a second memory module, a processor, a system disk and a back-end disk. When target data is generated, the processor stores the target data in the first memory module, so that the business system can obtain and process the target data in the first memory module in a timely manner to meet the real-time requirements of the business. At the same time, the processor writes the target data to the system disk through the first write path to complete the preliminary storage of the target data; after confirming that the target data is successfully written to the system disk, in order to realize the backup of the data, the processor stores the target data in the second memory module, and then uses the second write path to write the target data to the back-end disk, and when the target data is written to the back-end disk, it will not affect the business system's reading and writing of the data in the first memory module. Thus, by asynchronously and through independent write paths, the target data is written to the system disk and the back-end disk respectively, which realizes the timely backup of the target data and can reduce the impact on system performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0019] Figure 1 A schematic diagram of the structure of a data backup device provided in one embodiment of the present application;

[0020] Figure 2 A schematic structural diagram of a data backup device provided in yet another embodiment of the present application;

[0021] Figure 3 A schematic diagram of the structure of a back-end disk provided in an embodiment of the present application;

[0022] Figure 4 A flowchart of a data backup method provided in one embodiment of the present application;

[0023] Figure 5 A schematic diagram of the structure of an electronic device provided in one embodiment of the present application. DETAILED DESCRIPTION

[0024] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0025] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0026] In today's digital age, various systems are widely used in various fields, supporting the normal operation of businesses. However, during actual system operation, these systems face numerous unpredictable issues, such as hardware failures, software vulnerabilities, and cyberattacks. Once these issues occur, they can potentially cause system failures and even data loss or corruption. Therefore, during the system development phase, effective system recovery in various disaster scenarios must be carefully considered. When a system failure cannot be automatically repaired, pre-backed-up data becomes crucial for business recovery.

[0027] In related technologies, data backup is mainly performed in two ways: real-time backup or non-real-time backup.

[0028] Among them, real-time backup can track and capture data changes in real time for backup, ensuring data integrity to the greatest extent. However, for systems that frequently and intensively modify data, it will increase I / O and CPU overhead, and also cause write latency to be significantly extended.

[0029] Non-real-time backups primarily include scheduled backups and manual backups. While relatively simple to implement, non-real-time backups suffer from significant time window vulnerabilities. This means that data generated between the time of the last backup and the time of the system failure cannot be recovered, making it difficult to meet the needs of applications with extremely high real-time requirements.

[0030] Therefore, the data backup method in the related art cannot ensure the timeliness of data backup while reducing the impact on system performance.

[0031] Therefore, in order to ensure the timeliness of data backup while reducing the impact on system performance when facing the above technical problems, the storage location and write path of business storage and backup storage can be distinguished. Business data is written directly to the system disk through the first memory module and immediately responded to and confirmed, while backup data is asynchronously written to the back-end disk in batches through the independent second memory module. The process of writing backup data to the back-end disk will not affect the business system's reading and writing of data in the first memory module.

[0032] The following specific embodiments describe in detail the technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0033] Figure 1 A schematic diagram of a data backup device according to an embodiment of the present invention; Figure 1 As shown in the figure, a data backup device 10 provided in this embodiment specifically includes: a first memory module 11, a second memory module 12, a processor 13, a system disk 14 and a back-end disk 15. The processor 13 is communicatively connected to the first memory module 11, the second memory module 12, the system disk 14 and the back-end disk 15; the first memory module 11 is communicatively connected to the system disk 14, and the second memory module 12 is communicatively connected to the back-end disk 15.

[0034] Among them, the first memory module 11 is mainly used for data interaction with the business system. The first memory module 11 serves as a data cache between the business system and the system disk 14, and can quickly respond to the read and write requests of the business system, thereby improving the efficiency of data reading and writing. Since the read and write speed of the memory is higher than that of the system disk 14, the first memory module 11 can improve the access efficiency of the business system to data and meet the real-time requirements of the business system for data reading and writing. When the business system needs to read data, it can be obtained directly from the first memory module 11, avoiding the performance overhead caused by frequent access to the system disk 14; when the business system needs to write data, the data is first written to the first memory module 11, and then coordinated by the processor 13 to be written to the system disk 14, ensuring the real-time and smoothness of the business system.

[0035] The business system is a system that can communicate with the data backup device. The business system can change as the application scenario of the data backup device changes.

[0036] For example, in an e-commerce system, data generated by operations such as user ordering and payment can be quickly stored in the first memory module 11, and the business system can also quickly read these data for subsequent processing to ensure the smooth progress of the business process.

[0037] The second memory module 12 is primarily used as a temporary storage area during the data backup process after the target data is written to the system disk 14. The second memory module 12 receives the target data forwarded by the processor 13 from the first memory module 11 and writes the data to the backend disk 15 via a second write path. The provision of the second memory module 12 allows the data backup process to be independent of the business system's data read and write processes, thereby minimizing the impact on business system performance.

[0038] System disk 14 is the primary data storage medium, used to store daily operational data for the business system. Processor 13 writes target data to system disk 14 via the first write path, ensuring persistent data storage. System disk 14 typically has a large storage capacity and high read / write performance, meeting the basic data storage requirements of the business system.

[0039] The backend disk 15 is a storage medium for backup data, used to store target data backed up from the system disk 14. Once the target data is successfully written to the system disk 14, the processor 13 stores the target data in the second memory module 12 and writes the target data to the backend disk 15 via the second write path. The backend disk 15 can utilize a different storage technology or storage location than the system disk 14 to ensure the security and reliability of the backup data. For example, the backend disk 15 can be deployed in a different physical location to prevent data loss due to force majeure factors such as natural disasters.

[0040] The processor 13 is the core control unit of the data backup device 10 , and is responsible for receiving, processing, and distributing data.

[0041] Specifically, the processor 13 is used to store the target data in the first memory module 11 in response to receiving the target data, and write the target data to the system disk 14 through the first write path to complete the preliminary storage of the target data; the first memory module 11 is used to communicate with the business system so that the business system reads and writes the target data stored in the first memory module 11, thereby being able to quickly respond to the read and write requests of the business system and reduce the impact on the performance of the business system.

[0042] The target data may be data sent by a business system or data input by a user through an input device. Alternatively, the target data may be user configuration information or some business data. The target data should include information such as the business module number, the module internal number, and the length of the data to facilitate identification and subsequent processing by the processor 13.

[0043] The first write path may be implemented based on a specific data transmission protocol and interface, ensuring that data can be accurately and efficiently transmitted from the first memory module 11 to the system disk 14 .

[0044] Specifically, the processor 13 is further configured to, in response to determining that the target data is written to the system disk 14 , store the target data in the second memory module 12 , and write the target data to the backend disk 15 through the second write path to implement backup of the target data.

[0045] It should be noted that the second memory module 12, as an intermediate storage link during the data backup process, can temporarily cache data to be written to the back-end disk 15, further improving the efficiency and stability of writing the target data. The second write path can be implemented based on a specific data transmission protocol and interface to ensure that the target data is accurately transferred from the second memory module 12 to the back-end disk 15.

[0046] It should be noted that in this embodiment, the target data writing process is divided into two phases and performed through different memory modules and write paths. This reduces conflicts and waiting time during the target data writing process, and improves the overall efficiency and stability of the target data writing process. Furthermore, the data backup process is independent of the data reading and writing process of the business system. After writing the target data to the first memory module 11, the business system can continue to operate. The target data backup operation is completed by the processor 13 in the background through the second memory module 12 and the second write path, without causing a significant performance impact on the normal operation of the business system.

[0047] It should be noted that in this embodiment, a two-tiered storage system, system disk 14 and back-end disk 15, is used. Back-end disk 15 serves as data backup storage. If system disk 14 fails or data is lost, the backup data can be retrieved from back-end disk 15 for recovery. Optionally, during data recovery, processor 13 reads the backup data from back-end disk 15, stores it in second memory module 12, and then writes it directly to system disk 14 via the first write path. This reduces the risk of data loss and ensures data integrity and availability.

[0048] Optionally, in actual applications, the capacity of the first and second memory modules 11, 12 can be appropriately configured based on business needs and data volume, and the storage performance of the system disk 14 and back-end disk 15 can be optimized and adjusted to better facilitate data backup. For example, for business systems with frequent data read and write operations and large data volumes, the capacity of the first memory module 11 can be appropriately increased to improve the business system's data processing speed. For scenarios with high data security requirements, the more reliable back-end disk 15 can be selected, and redundant storage technology can be used to further ensure data security.

[0049] For example, in order to better understand the solution provided by the present application, this embodiment provides a scenario in which the data backup device 10 may be actually applied.

[0050] Assume that the financial system of a certain enterprise applies the data backup device 10 provided in this embodiment. When the financial personnel perform accounting processing operations, the various types of financial data generated are transmitted to the processor 13 as target data. After receiving the target data, the processor 13 immediately stores it in the first memory module 11. At this time, the financial system can quickly read and modify the data to perform accounting audits, data statistics and other operations. At the same time, the processor 13 writes the target data to the system disk 14 through the first write path to complete the storage of the data on the system disk 14. After confirming that the data is successfully written to the system disk 14, the processor 13 stores the data in the second memory module 12, and writes the data to the back-end disk 15 for backup through the second write path. When the system disk 14 has a hardware failure or a software error resulting in data loss, the enterprise can also restore the complete financial data from the back-end disk 15 to ensure the normal progress of financial work.

[0051] It should be noted that the actual application scenarios of the data backup device 10 are not limited to the example scenarios provided above. The data backup device 10 can also be used in industries such as finance and medical care.

[0052] The data backup device 10 provided in the embodiment of the present application, when target data is generated, the processor 13 stores the target data in the first memory module 11, so that the business system can timely obtain and process the target data in the first memory module 11, meeting the real-time requirements of the business. At the same time, the processor 13 writes the target data to the system disk 14 through the first write path to complete the preliminary storage of the target data; after confirming that the target data is successfully written to the system disk 14, in order to realize the backup of the data, the processor 13 stores the target data in the second memory module 12, and then uses the second write path to write the target data to the back-end disk 15. When the target data is written to the back-end disk 15, it will not affect the business system's reading and writing of the data in the first memory module 11. Thus, by asynchronously and through independent write paths, the target data is written to the system disk 14 and the back-end disk 15 respectively, which realizes the timely backup of the target data and can reduce the impact on system performance.

[0053] As an optional implementation manner, based on any of the foregoing embodiments, the processor 13 is further configured to:

[0054] In response to receiving the target data, the historical data stored in the first memory module 11 is obtained, and the historical data is compared with the target data.

[0055] Specifically, after receiving the target data, the processor 13 first obtains the historical data stored in the first memory module 11 and compares the historical data with the target data.

[0056] Optionally, a variety of algorithms can be used in the process of comparing historical data with target data, such as byte-by-byte comparison based on data content, vector comparison based on data features, etc. The specific algorithm can be flexibly selected according to the data type and business needs.

[0057] In this embodiment, the historical data refers to the data already existing in the first memory module 11 .

[0058] In response to determining that the historical data is different from the target data, the target data is stored in the first memory module 11 .

[0059] Specifically, if the processor 13 determines that the historical data is different from the target data, it indicates that the target data is new data or has changed data. In this case, the target data is stored in the first memory module 11. The first memory module 11 communicates with the business system, and the business system can directly read and write the target data stored in the first memory module 11, which can quickly respond to the business system's read and write requests and reduce the impact on the business system's performance.

[0060] Optionally, if the processor 13 determines that the historical data is the same as the target data, it means that the target data is duplicate data and does not need to be stored and backed up again. The target data can be directly discarded or marked according to business needs to avoid unnecessary storage and backup operations.

[0061] Optionally, when it is determined that the historical data is different from the target data, the target data is marked to distinguish it from the data in the historical data, so that the processor 13 knows which data in the target data is updated data.

[0062] In the data backup device 10 provided in the embodiment of the present application, the processor 13 first obtains the historical data in the first memory module 11 and compares it with the target data. If the two are different, the target data is stored in the first memory module 11, ensuring that only the data that really needs to be stored and backed up is processed, avoiding repeated storage of the same data, reducing invalid data writing operations, effectively saving storage space of the system disk 14 and the back-end disk 15, and ensuring the efficient utilization of storage resources.

[0063] Figure 2 A structural diagram of a data backup device provided in another embodiment of the present application; as an optional implementation, based on any one of the above embodiments, refer to Figure 2 As shown in , the data backup device 10 further includes a data buffer 16 .

[0064] Specifically, the data buffer 16 is communicatively connected to the second memory module 12 and the processor 13 .

[0065] The data buffer 16 serves as a buffer between the processor 13, the second memory module 12, and the backend disk 15, temporarily storing dirty data blocks. This buffer can alleviate disk I / O pressure and prevent the impact of frequent disk write operations on system performance. Furthermore, the data buffer 16 can store dirty data blocks, thereby backing up only incremental data and improving data backup efficiency.

[0066] Optionally, the data buffer 16 may be a separate memory module, that is, the data buffer 16 may be a third memory module.

[0067] The processor 13 is specifically configured to: store the target data in the second memory module 12 and write the target data to the backend disk 15 through the second write path;

[0068] Based on the dirty data block tag, the dirty data block in the target data is stored in the data buffer 16; wherein the dirty data block is a portion of the target data that is different from the historical data stored in the first memory module 11;

[0069] Optionally, after receiving the target data, processor 13 first obtains historical data stored in first memory module 11, compares the historical data with the target data, identifies dirty data blocks in the target data (i.e., portions that are different from the historical data stored in first memory module 11), and tags the dirty data blocks to generate dirty data block labels. Based on the dirty data block labels, processor 13 stores the dirty data blocks in the target data in data buffer 16.

[0070] The dirty data block tag is used to identify relevant information of the dirty data block, such as the starting address and length of the data block, for subsequent processing.

[0071] Optionally, multiple dirty data blocks are stored in the data buffer 16 by tail appending. It should also be noted that the data buffer 16 is only used to store data, and the processor 13 or other modules maintain and manage the information of the dirty data blocks.

[0072] In response to receiving the write instruction, the multiple dirty data blocks in the data buffer 16 are stored in the second memory module 12; and the dirty data blocks are written to the back-end disk 15 through the second write path.

[0073] Optionally, after a batch of target data is uploaded, the business system sends a write instruction to the processor 13. After receiving the write instruction, the processor 13 stores multiple dirty data blocks in the data buffer 16 in the second memory module 12 and writes the dirty data blocks to the backend disk 15 through the second write path. This batch write method can effectively reduce the number of disk I / O operations and improve data backup efficiency.

[0074] If the dirty data block is not written to the back-end disk 15 within a preset time, the writing process is terminated and a full backup tag is generated.

[0075] Among them, the full backup tag is used to instruct the processor 13 to obtain the full backup data stored in the first memory module 11 in the next write cycle of the backend disk 15, and write the full backup data to the backend disk 15 to ensure data integrity and consistency.

[0076] The preset time is a preset time for writing dirty data blocks to the back-end disk 15. Optionally, the timing can be performed by setting a timer.

[0077] The full backup data refers to all the data in the first memory module 11 .

[0078] Specifically, within the preset time, the processor 13 continuously monitors the writing status of the dirty data block; if the dirty data block is not written to the back-end disk 15 within the preset time, it indicates that there may be a data transmission failure. At this time, the processor 13 terminates the writing process and generates a full backup label.

[0079] Optionally, if a dirty data block is successfully written to the backend disk 15 within a preset time, the dirty data block tag in the second memory module 12 and the backend disk 15 is cleared, and the next disk write event is sent to the business system or other module. When the business system or other module receives the disk write event, it traverses the data blocks in the second memory module 12. If a dirty data block tag is found, the next round of disk write is performed, that is, the dirty data block in the second memory module is sent to the backend disk 15. In addition, a disk write batch number is generated for each disk write, and the disk write batch number increases with the number of disk write rounds.

[0080] Optionally, the data backup device 10 can flexibly adjust parameters such as the size and preset time of the data buffer 16 according to different business needs and data changes to adapt to different business scenarios and data backup requirements.

[0081] In this embodiment, the second memory module 12 receives dirty data blocks sent from the data buffer 16 and writes the dirty data blocks to the backend disk 15 through the second write path. The presence of the second memory module 12 allows the data backup process to be performed independently of the data reading and writing process of the business system, further reducing the impact on the performance of the business system.

[0082] It should be noted that when the system disk 14 fails or data is lost, it can be restored from the backend disk 15. If the backend disk 15 stores dirty data blocks, the data can be merged and restored based on the dirty data block tags and the historical data on the system disk 14. If the backend disk 15 stores full backup data, the full backup data can be directly restored to the system disk 14.

[0083] It should be noted that, after the dirty data block is stored in the back-end disk 15 , the dirty data block can be merged with the existing data in the back-end disk 15 according to the dirty data block tag.

[0084] The data backup device 10 provided in the embodiment of the present application introduces a data buffer 16 to cache and batch-write dirty data blocks. Based on dirty data block tags, dirty data blocks in the target data are accurately identified and processed, and only changed data in the target data is backed up. This reduces unnecessary data transmission and storage, saving storage space and bandwidth resources. Furthermore, if a dirty data block is not written to the back-end disk 15 within a preset time, a full backup tag is generated to ensure that a full backup is performed during the next write cycle of the back-end disk 15. This avoids data inconsistencies caused by partial data backup failures and improves data integrity and recoverability.

[0085] As an optional implementation, based on any of the above embodiments, the data backup device 10 further includes a backup disk.

[0086] Specifically, the backup disk is an additional data backup storage medium used to store historical data obtained from the system disk 14 when an abnormality occurs on the backend disk 15. The backup disk can use different storage technologies or be deployed in a different physical location than the backend disk 15 to improve data fault tolerance and security.

[0087] The processor 13 is further configured to: in response to determining that an abnormality exists in the backend disk 15 , obtain historical data in the system disk 14 ; and write the historical data in the system disk 14 into the backup disk.

[0088] Specifically, the processor 13 can monitor the working status of the backend disk 15 in real time. When it is determined that there is an abnormality in the backend disk 15, it immediately obtains the historical data in the system disk 14. Afterwards, the historical data in the system disk 14 is written to the backup disk, ensuring that the data still has a reliable backup storage location when the backend disk 15 is not working properly.

[0089] Optionally, the processor 13 may determine whether the backend disk 15 has an abnormality by periodically reading disk status information, checking whether disk read and write operations are successful, etc. For example, when the number of disk read and write errors exceeds a preset threshold, or when a disk health status monitoring indicator is abnormal, it is determined that the backend disk 15 has an abnormality.

[0090] It should be noted that during the abnormality of the back-end disk 15, the data in the backup disk can be used as a temporary backup to ensure that the business system can continue to run during the data recovery process, reduce business interruption time, and ensure business continuity.

[0091] Optionally, when the backend disk 15 returns to normal, the data in the backup disk can be restored to the backend disk 15 according to actual conditions, or the backup disk can continue to be used as a data backup storage medium while the backend disk 15 is repaired and maintained.

[0092] The data backup device 10 provided in the embodiment of the present application, by introducing a backup disk, can promptly write the historical data in the system disk 14 to the backup disk when an abnormality occurs in the back-end disk 15, thereby ensuring the integrity and recoverability of the data, avoiding data loss due to failure of the back-end disk 15, and reducing the probability of the business system being affected by disk failure.

[0093] Figure 3 This is a schematic diagram of the structure of the back-end disk provided in one embodiment of the present application. Specifically, in order to facilitate understanding of subsequent solutions, the data organization format of the back-end disk 15 is briefly introduced and explained here.

[0094] refer to Figure 3 As shown in FIG, the back-end disk 15 includes a header sector, a metadata sector, and a data buffer.

[0095] The header sector is located at the beginning of the back-end disk 15, for example, at sector LBA 0. It can record the write time, the data buffer currently being written, and the batch number currently being written. The metadata sector is a continuous sector immediately following the header sector. The metadata sector can record metadata for each stored data, such as the module identifier, data length, and a checksum for each metadata item. The data cache area is located after the metadata sector, and the data buffer 16 is used to store data.

[0096] For example, Figure 3 There are two metadata sectors and two data cache areas in the memory, and the two metadata sectors and the two data cache areas are recorded and managed in a one-to-one correspondence.

[0097] As an optional implementation, based on any of the above embodiments, the back-end disk 15 includes multiple storage areas.

[0098] It should be noted that the backend disk 15 includes multiple storage areas, namely, multiple data buffers. Each storage area has independent storage space and address range, enabling independent data read and write operations. When multiple data buffers 16 are provided, multiple metadata sectors are also provided, and the multiple metadata sectors are managed in a one-to-one correspondence with the multiple data buffers 16.

[0099] The processor 13 is further configured to write the target data into the multiple storage areas in sequence.

[0100] Optionally, the back-end disk 15 has multiple storage areas, each of which is assigned a unique identifier. The processor 13 writes the target data into the multiple storage areas in sequence. The writing process can be performed in a certain order, for example, writing in sequence according to the storage area identifiers, or selecting an appropriate storage area for writing based on the data priority and backup strategy.

[0101] It should be noted that when writing data to a storage area, if a system crash or write failure occurs, the write process will be terminated and the historical data in other storage areas will be overwritten in the storage area where the write failure occurred, thereby ensuring data consistency in multiple storage areas.

[0102] It should be noted that when data needs to be accessed or recovered, the processor 13 determines the storage area where the data is located based on the data's identification information and reads the data from the corresponding storage area. If a storage area fails or data is corrupted, the processor 13 can retrieve the data from other normal storage areas, improving the fault tolerance and recoverability of the data.

[0103] Optionally, different storage areas can be used to store different types of data or backup data from different time periods, facilitating data classification, management, and maintenance. For example, daily backup data can be stored in one storage area, and full backup data in another, facilitating data cleanup and archiving.

[0104] Optionally, the processor 13 selects an appropriate storage area for writing the target data based on preset rules and policies. The preset rules and policies may be based on factors such as the remaining space in the storage area, the degree of data type compatibility, and backup time requirements. For example, if the target data is daily business data, the processor 13 may select a storage area specifically for storing daily backup data.

[0105] In the data backup device 10 provided in the embodiment of the present application, the backend disk 15 is provided with multiple storage areas. The multiple storage areas are independent of each other. When a storage area fails, it will not affect the normal use of other storage areas. The processor 13 can obtain data from other normal storage areas, ensuring data recoverability and reducing the risk of data loss. In addition, if a system crash occurs during the writing process of any storage area, historical data in other storage areas can be overwritten with the storage area where the write failure occurred, thereby ensuring data consistency among multiple storage areas.

[0106] As an optional implementation, based on any one of the above embodiments, the backend disks 15 are configured with multiple ones; and the processor 13 is further configured to: write the target data into the multiple backend disks 15 in sequence.

[0107] Optionally, the multiple back-end disks 15 can be the same type of storage device, or a combination of storage devices of different types, capacities, and performance. For example, some back-end disks 15 can use high-performance solid-state drives to back up business data that requires high read and write speeds, while others can use large-capacity mechanical hard drives to store cost-sensitive data with low read and write frequency. The multiple back-end disks 15 are connected to the processor 13 via appropriate interfaces to ensure stable and efficient data transmission.

[0108] Optionally, the processor 13 can monitor the working status of multiple backend disks 15 in real time, including the health status, remaining storage space, read and write performance, etc. of the backend disks 15. Based on the monitoring results, the processor 13 can dynamically manage the backend disks 15. For example, when a backend disk 15 experiences an abnormality, it can be promptly excluded from the data writing target.

[0109] Optionally, the target data may be written in a predetermined order, such as sequentially according to the numbers of the back-end disks 15, or written after sorting based on factors such as the remaining space, read / write performance, etc. of the back-end disks 15. Optionally, the processor 13 records the storage location information of each data block on each back-end disk 15 to facilitate subsequent data access and recovery.

[0110] It should be noted that writing the target data to multiple back-end disks 15 in sequence forms multiple copies of the data. When a back-end disk 15 fails, the other back-end disks 15 still store the complete data, reducing the risk of data loss and improving data reliability.

[0111] It should be noted that when data needs to be accessed or restored, the processor 13 reads the data from the corresponding backend disk 15 based on the recorded data storage location information. If a backend disk 15 fails and data cannot be read, the processor 13 can obtain the same data from other normal backend disks 15 to ensure data recoverability.

[0112] The data backup device 10 provided in the embodiment of the present application can effectively avoid data loss due to a single disk failure by configuring multiple back-end disks 15 and controlling the target data to be written to the multiple back-end disks 15 in sequence, thereby ensuring the stability and security of data backup and meeting the requirements for data storage and backup in various complex business scenarios.

[0113] As an optional implementation manner, based on any of the foregoing embodiments, the processor 13 is further configured to:

[0114] The processor 13 obtains the backup data stored in the data cache of the backend disk 15 and the historical checksums recorded in the metadata sectors; calculates the target checksum for each backup data item; compares the target checksum with the historical checksum; and generates a full backup tag in response to an inconsistency between the target checksum and the historical checksum. Specifically, the processor 13 can obtain the currently stored backup data from the data cache of the backend disk 15 and simultaneously read the recorded historical checksums from the metadata sectors. The data cache is used to store written backup data, while the metadata sectors are specifically used to store management information related to the backup data, such as historical checksums, data versions, and backup times.

[0115] Optionally, a preset checksum algorithm may be used to calculate the acquired backup data to generate a target checksum of the current backup data. Optionally, the preset checksum algorithm may be CRC32, MD5, SHA-1, etc.

[0116] The historical checksum refers to the checksum value calculated and stored during the last successful data backup.

[0117] Specifically, the calculated target checksum is compared bit by bit with the read historical checksum. If all bits match, the checksums are considered consistent, indicating that the backup data has not changed abnormally and no further operations are required. If any bit does not match, the checksums are considered inconsistent, indicating that the backup data may have been damaged, tampered with, or stored incorrectly.

[0118] Furthermore, when the target checksum is inconsistent with the historical checksum, the processor 13 automatically generates a full backup tag. The full backup tag can be a Boolean flag, a specific identifier, or a command message, which indicates that the system needs to perform a full backup operation instead of an incremental backup or a differential backup. The system will adjust the subsequent backup strategy based on the tag, giving priority to full backup to ensure data integrity.

[0119] Optionally, after detecting the full backup tag, the system automatically starts the full backup process, completely backs up all current data to the backend disk 15, and updates the historical checksum in the metadata sector to the new target checksum after the backup is completed, and clears the full backup tag.

[0120] It should be noted that a full backup tag is generated only when the target checksum is inconsistent with the historical checksum, avoiding unnecessary full backup operations. This ensures data reliability and reduces the waste of storage resources.

[0121] Optionally, the processor 13 reads the currently stored backup data from the data cache of the backend disk 15 periodically or based on a preset trigger condition. By regularly comparing the target checksum with the historical checksum, anomalies in the backup data can be detected, thereby avoiding business risks caused by data corruption or tampering. Optionally, the preset trigger condition can be a scheduled task or a data update event.

[0122] Optionally, when acquiring the historical checksum of the metadata sector, the processor 13 may search and read the corresponding historical checksum according to the identification information of the backup data. Optionally, the identification information of the backup data may be the encoding of the backup data, the backup timestamp, etc.

[0123] The data backup device 10 provided in the embodiment of the present application obtains the backup data stored in the data cache area of ​​the back-end disk 15 and the historical checksum recorded in the metadata sector, calculates the target checksum of the current backup data and compares it with the historical checksum, and generates a full backup tag when inconsistency is found, so that data anomalies can be discovered in time and the full backup process can be triggered to ensure the accuracy and consistency of the backup data.

[0124] As an optional implementation manner, based on any of the foregoing embodiments, the processor 13 is further configured to:

[0125] In response to determining that the system disk 14 has a fault, the backup data stored in the data cache area of ​​the back-end disk 15 is obtained and the backup data is verified; in response to the backup data passing the verification, the backup data is written to the system disk 14.

[0126] Specifically, upon confirming a system disk 14 failure, the processor 13 triggers a data recovery process, retrieving pre-stored backup data from the data cache of the backend disk 15. The retrieved backup data is then rigorously verified. Only after the backup data passes verification does the processor 13 write the backup data to the restored or replaced system disk 14, ensuring the accuracy of the written data.

[0127] Optionally, the processor 13 or other monitoring tools can continuously monitor the operating status of the system disk 14, and determine whether the system disk 14 is faulty based on indicators such as hardware health status detection, I / O response time, and error counts. Fault detection can be performed using periodic polling or event-driven methods to ensure timely detection of problems.

[0128] Optionally, the verification content of the backup data includes but is not limited to: integrity verification, such as comparison of checksums and hash values; data structure verification, such as file header and tail marks, data block sequence; business logic verification, such as legitimacy check for specific data formats.

[0129] The data backup device 10 provided in this embodiment of the present application initiates a data recovery process after a system disk 14 fails, restoring data on the system disk 14 using the backup data stored on the back-end disk 15, thereby reducing service interruption. Furthermore, backup data is written to the system disk 14 only after verification, preventing the introduction of erroneous data onto the system disk 14 and ensuring data accuracy.

[0130] As an optional implementation, based on any of the above embodiments, multiple back-end disks 15 are configured; and backup data is stored in each of the multiple back-end disks 15 .

[0131] It should be noted that by configuring multiple independent backend disks 15, each backend disk 15 stores complete backup data to form a redundant backup architecture. Each disk is physically isolated to prevent a single point of failure from causing all backups to fail.

[0132] The processor 13, in response to determining that the system disk 14 has a fault, is further configured to:

[0133] Obtain the write batch numbers recorded in the head sectors of multiple back-end disks 15 and compare the multiple write batch numbers; determine the target back-end disk corresponding to the largest write batch number among the multiple write batch numbers; obtain the backup data stored in the data cache area of ​​the target back-end disk and perform data verification on the backup data.

[0134] When the system disk 14 fails, the processor 13 reads the write batch numbers of the head sectors of all the back-end disks 15 in parallel, parses the timestamp and serial number of each write batch number, and selects the backup data in the target back-end disk with the largest write batch number for data recovery by comparing the write batch numbers recorded in the head sectors of each back-end disk 15, ensuring that the latest valid backup data can always be obtained, thereby solving the data consistency selection problem in the multi-backup source scenario, and is suitable for enterprise-level storage systems that require high reliability.

[0135] Optionally, during each backup operation, the processor 13 writes a unique write batch number into the head sector of all back-end disks 15 , and the format may be “YYYYMMDD-HHMMSS-SEQ”.

[0136] Optionally, each back-end disk 15 is configured with an independent power protection circuit to prevent problems from occurring on multiple back-end disks 15 at the same time.

[0137] Optionally, when it is detected that multiple backend disks 15 have the same write batch number, the checksum of each backend disk 15 is verified; the backend disk 15 with a valid checksum is preferentially selected; if all are valid, the backend disk 15 that responds first is selected.

[0138] The data backup device 10 provided in the embodiment of the present application utilizes multiple back-end disks 15, each of which stores complete backup data, to form a redundant backup architecture, thereby preventing a single point of failure from rendering all backup data ineffective. When a system disk 14 fails, the backup device 10 compares the write batch numbers recorded in the header sectors of each back-end disk 15, selecting the backup data on the target back-end disk with the largest write batch number for data recovery. This ensures that the latest valid backup data is always available, thereby resolving the data consistency selection issue in multiple backup source scenarios.

[0139] Figure 4 A flowchart of a data backup method provided in one embodiment of the present application is shown as follows: Figure 4 As shown, the execution subject of this embodiment is a processor, and the data backup method provided by this embodiment specifically includes the following steps:

[0140] S201. In response to receiving target data, the target data is stored in a first memory module, and the target data is written to a system disk through a first write path. The first memory module is used to communicate with a business system so that the business system reads and writes the target data stored in the first memory module.

[0141] S202 : In response to determining that the target data is written to the system disk, the target data is stored in the second memory module, and the target data is written to the backend disk through the second write path.

[0142] Optionally, the data backup method further includes: in response to receiving the target data, obtaining historical data stored in the first memory module, and comparing the historical data with the target data; in response to determining that the historical data is different from the target data, storing the target data in the first memory module.

[0143] Optionally, the target data is stored in the second memory module, and the target data is written to the back-end disk through the second write path, including: storing dirty data blocks in the target data in the data buffer based on the dirty data block tag; wherein the dirty data block is a part of the target data that is different from the historical data stored in the first memory module; in response to receiving a write instruction, storing multiple dirty data blocks in the data buffer to the second memory module; and writing the dirty data blocks to the back-end disk through the second write path; if the dirty data blocks are not written to the back-end disk within a preset time, terminating the write process and generating a full backup tag; wherein the full backup tag is used to instruct the processor to obtain the full backup data stored in the first memory module in the next write cycle of the back-end disk, and write the full backup data to the back-end disk.

[0144] Optionally, the data backup method further includes: in response to determining that an abnormality exists on the back-end disk, acquiring historical data in the system disk; and writing the historical data in the system disk to the backup disk.

[0145] Optionally, the data backup method also includes: obtaining the backup data stored in the data cache area of ​​the back-end disk and the historical checksum recorded in the metadata sector; calculating the target checksum of each backup data; comparing the target checksum with the historical checksum; and generating a full backup label in response to the inconsistency between the target checksum and the historical checksum.

[0146] Optionally, the data backup method further includes: in response to determining that a system disk failure exists, obtaining the backup data stored in the data cache area of ​​the back-end disk and performing data verification on the backup data; in response to the backup data verification passing, writing the backup data to the system disk.

[0147] Optionally, in response to determining that a system disk failure exists, the data backup method further includes: obtaining the write batch numbers recorded in the head sectors of multiple back-end disks, and comparing the multiple write batch numbers; determining the target back-end disk corresponding to the largest write batch number among the multiple write batch numbers; obtaining the backup data stored in the data cache area of ​​the target back-end disk and performing data verification on the backup data.

[0148] Optionally, the data backup method further includes: writing the target data into multiple storage areas in sequence.

[0149] Optionally, the data backup method further includes: writing the target data into a plurality of back-end disks in sequence.

[0150] It should be noted that the technical effects of the data backup method adopted in this embodiment have been explained in the embodiment of the above-mentioned data backup device, and therefore, they will not be repeated in this embodiment.

[0151] Figure 5 A schematic diagram of the structure of an electronic device provided in one embodiment of the present application is shown in FIG. Figure 5 As shown, the electronic device 30 provided in the embodiment of the present application includes: a data storage 31 and a data processor 32.

[0152] The data storage 31 stores a computer program, and the data processor 32 is configured to run the computer program to execute the steps in any of the above-mentioned data backup method embodiments.

[0153] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps of any of the above-mentioned data backup method embodiments when running.

[0154] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0155] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a data processor, the steps of any of the above-mentioned data backup method embodiments are implemented.

[0156] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of any of the above-mentioned data backup method embodiments are implemented.

[0157] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0158] The above is a detailed introduction to a data backup device, method, equipment, and storage medium provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only intended to help understand the method and core ideas of the present application. It should be pointed out that, for those skilled in the art, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A data backup device, characterized in that: include: a first memory module, a second memory module, a processor, a system disk, and a backend disk, wherein the processor is communicatively connected to the first memory module, the second memory module, the system disk, and the backend disk; the first memory module is communicatively connected to the system disk via a first write path, and the second memory module is communicatively connected to the backend disk via a second write path; the first write path and the second write path are independent of each other; the processor being configured to, in response to receiving the target data, obtain historical data stored in the first memory module and compare the historical data with the target data; In response to determining that the historical data is different from the target data, storing the target data in the first memory module, and writing the target data to the system disk through the first write path, the first memory module being used to communicate with the business system so that the business system reads and writes the target data stored in the first memory module; The processor is further configured to, in response to determining that the target data is written to the system disk, store the target data in the second memory module, and write the target data to the back-end disk for backup through the second write path; the second memory module is configured to temporarily store the target data to be written to the back-end disk.

2. The device according to claim 1, characterized in that The device further includes: a data buffer; The processor is configured to, when storing the target data in the second memory module and writing the target data to the back-end disk through the second write path, specifically: storing dirty data blocks in the target data into the data buffer based on dirty data block tags; wherein the dirty data blocks are portions of the target data that are different from historical data stored in the first memory module; In response to receiving a write instruction, storing the plurality of dirty data blocks in the data buffer into the second memory module; and writing the dirty data blocks to the back-end disk through the second write path; If the dirty data block is not written to the back-end disk within a preset time, the write process is terminated and a full backup tag is generated; wherein, the full backup tag is used to instruct the processor to obtain the full backup data stored in the first memory module in the next write cycle of the back-end disk, and write the full backup data to the back-end disk.

3. The device according to claim 1, characterized in that The device further includes a backup disk; and the processor is further configured to: In response to determining that the backend disk is abnormal, acquiring historical data in the system disk; The historical data in the system disk is written to the backup disk.

4. The device according to any one of claims 1 to 3, characterized in that The processor is further configured to: Obtaining the backup data stored in the data cache area of ​​the back-end disk and the historical checksum recorded in the metadata sector; Calculating a target checksum for each of the backup data; comparing the target checksum with the historical checksum; In response to the target checksum being inconsistent with the historical checksum, a full backup tag is generated.

5. The device according to any one of claims 1 to 3, characterized in that: The processor is further configured to: In response to determining that the system disk has a fault, obtaining backup data stored in a data cache area of ​​the back-end disk and performing data verification on the backup data; In response to the backup data passing verification, the backup data is written to the system disk.

6. The device according to claim 5, characterized in that There are multiple backend disks configured; the backup data is stored in each of the multiple backend disks; The processor, after determining in response that the system disk has a fault, is further configured to: Obtaining a plurality of write batch numbers recorded in the head sectors of the back-end disks, and comparing the plurality of write batch numbers; Determine a target backend disk corresponding to the largest write batch number among the plurality of write batch numbers; The backup data stored in the data cache area of ​​the target back-end disk is acquired and data verification is performed on the backup data.

7. A data backup method, characterized in that: include: In response to receiving the target data, obtaining historical data stored in the first memory module, and comparing the historical data with the target data; In response to determining that the historical data is different from the target data, storing the target data in a first memory module and writing the target data to a system disk through a first write path, the first memory module being used to communicate with a business system so that the business system reads and writes the target data stored in the first memory module; In response to determining that the target data is written to the system disk, the target data is stored in a second memory module, and the target data is written to the back-end disk for backup through a second write path. The second memory module is used to temporarily store the target data to be written to the back-end disk; wherein the first write path and the second write path are independent of each other.

8. An electronic device, characterized in that: include: Memory for storing computer programs; A processor, configured to implement the steps of the data backup method according to claim 7 when executing the computer program.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein the computer program implements the steps of the data backup method according to claim 7 when executed by a processor.

Images