Data backup device, method and equipment and storage medium

Abstract

The invention discloses a data backup device and method, equipment and a storage medium, and relates to the technical field of data processing. When target data is generated, the target data is stored in the first memory module, so that a service system can obtain and process the target data in the first memory module in time, the target data is written into a system disk through the first write-in path, and preliminary storage of the target data is completed; after it is confirmed that the target data are successfully written into the system disk, the target data are stored in the second memory module, then the target data are written into the rear-end disk through the second write-in path, and when the target data are written into the rear-end disk, reading and writing of the data in the first memory module by the service system are not affected. Therefore, the target data are respectively written into the system disk and the rear-end disk in an asynchronous mode and an independent write-in path, so that the target data are backed up in time, and the influence on the system performance can be reduced.

Description

Technical Field

[0001] This application relates to the technical field of data processing, and particularly to a data backup device, method, equipment, and storage medium. Background Art

[0002] In today's digital age, various systems are widely used in all fields to support the normal operation of businesses. During the actual operation of the systems, many unpredictable problems are faced, such as hardware failures, software vulnerabilities, network attacks, etc. Once these problems occur, it is very likely that the systems cannot operate normally, and even cause data loss or damage.

[0003] Therefore, during the system development stage, it is necessary to fully consider how to achieve effective recovery of the system in various disaster scenarios. When the system encounters a fault that cannot be automatically repaired, the pre-backup data becomes the key to restoring the business. In related technologies, data backup is mainly carried out through two methods: real-time backup or non-real-time backup. However, the data backup methods in related technologies cannot ensure the timeliness of data backup while reducing the impact on system performance. Summary of the Invention

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

[0005] In a first aspect, this application provides a data backup device, including:

[0006] A first memory module, a second memory module, a processor, a system disk, and a backend disk, where 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] The processor is configured to, in response to receiving target data, store the target data in the first memory module and write the target data to the system disk through a first write path. The first memory module is used to communicate with the business system so that the business system can read and write the target data stored in the first memory module;

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

[0009] In a second aspect, this application further provides a data backup method, including:

[0010] In response to receiving the target data, store the target data in the first memory module, and write the target data to the system disk through the first write path. The first memory module is used to communicate with the service system so that the service system can read and write the target data stored in the first memory module;

[0011] After 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.

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

[0013] A memory for storing a computer program;

[0014] A processor for implementing the steps of the data backup method as in the second aspect when executing the computer program.

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

[0016] In a fifth aspect, the present application further provides a computer program product, including a computer program. When the computer program is executed by a processor, the steps of the data backup method as described in the second aspect above are implemented.

[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 backend disk. When target data is generated, the processor stores the target data in the first memory module, enabling the service system to timely obtain and process the target data in the first memory module to meet the real-time requirements of the service. 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 implement data backup, 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 backend disk. And when the target data is written to the backend disk, it will not affect the service system's reading and writing of the data in the first memory module. Thus, through an asynchronous manner and independent write paths, the target data is written to the system disk and the backend disk respectively, realizing timely backup of the target data and being able to reduce the impact on system performance. Description of the Drawings

[0018] To more clearly illustrate the embodiments of the present application, the following will briefly introduce the accompanying drawings required in the embodiments. Obviously, the accompanying drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other accompanying drawings can be obtained based on these drawings.

[0019] Figure 1 It is a schematic structural diagram of a data backup device provided by an embodiment of the present application;

[0020] Figure 2 It is a schematic structural diagram of a data backup device provided by another embodiment of the present application;

[0021] Figure 3 It is a schematic structural diagram of a backend disk provided by an embodiment of the present application;

[0022] Figure 4 It is a schematic flowchart of a data backup method provided by an embodiment of the present application;

[0023] Figure 5 It is a schematic structural diagram of an electronic device provided by an embodiment of the present application. Detailed implementation manners

[0024] The following will clearly and completely describe the technical solutions in the embodiments of the present application in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only some embodiments of the present application, rather than all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the protection scope of the present application.

[0025] To enable those skilled in the art of the present technology to better understand the solutions of the present application, the following will further describe the present application in detail in conjunction with the accompanying drawings and specific implementation manners.

[0026] In today's digital age, various systems are widely used in various fields to support the normal operation of businesses. During the actual operation of the system, many unpredictable problems are faced, such as hardware failures, software vulnerabilities, network attacks, etc. Once these problems occur, it is very likely that the system cannot operate normally, and even data loss or damage may occur. Therefore, during the system development stage, it is necessary to fully consider how to achieve the effective recovery of the system in various disaster scenarios. When the system encounters a failure that cannot be automatically repaired, the pre-backup data becomes the key to restoring the business.

[0027] In the related art, data backup is mainly carried out through two methods: 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 at the same time, it will also cause a significant extension of write latency.

[0029] Among them, non-real-time backup mainly includes two forms: scheduled backup and manual execution of command backup. The non-real-time backup method is relatively simple to implement, but there are obvious time window vulnerabilities. That is to say, the data generated between the last backup time and the system failure time cannot be recovered, and it is difficult to meet the requirements of application scenarios with extremely high real-time requirements.

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

[0031] So, in the face of the above technical problems, in order to ensure the timeliness of data backup while reducing the impact on system performance. It can be achieved by distinguishing the storage locations and write paths of business storage and backup storage. After the business data is directly written to the system disk through the first memory module, an immediate response confirmation is made, while the backup data is asynchronously and batch-written to the backend disk through an independent second memory module. During the process of writing the backup data to the backend disk, it will not affect the business system's reading and writing of the data in the first memory module.

[0032] The following uses specific embodiments to elaborate in detail on the technical solutions of the present application and how the technical solutions of the present application solve the above technical problems. These 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 with reference to the drawings.

[0033] Figure 1 It is a schematic structural diagram of a data backup device provided by an embodiment of the present application; refer to Figure 1 As shown in, 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 backend 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 backend 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 backend disk 15.

[0034] Among them, the first memory module 11 is mainly used for data interaction with the business system. As a data cache between the business system and the system disk 14, the first memory module 11 can quickly respond to the read and write requests of the business system, improving the data read and write efficiency. 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 data access efficiency of the business system and meet the real-time requirements of the business system for data read and write. When the business system needs to read data, it can directly obtain it 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 into the first memory module 11 and then coordinated by the processor 13 to be written into the system disk 14, ensuring the real-time and smooth operation of the business system.

[0035] Among them, the business system is a system that can interact and communicate with the data backup device. The business system can change with the change of the application scenario of the data backup device.

[0036] For example, in an e-commerce system, the data generated by user operations such as placing orders and making payments can be quickly stored in the first memory module 11, and at the same time, the business system can also quickly read this data for subsequent processing, ensuring the smooth progress of the business process.

[0037] Among them, the second memory module 12 is mainly used as a temporary storage area during the data backup process after the target data is written into 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 into the backend disk 15 through the second write path. By setting the second memory module 12, the data backup process can be independent of the data read and write process of the business system, thereby reducing the impact on the performance of the business system.

[0038] Among them, the system disk 14 is the main storage medium for data, used to store the daily operation data of the business system. The processor 13 writes the target data into the system disk 14 through the first write path to ensure the persistent storage of the data. The system disk 14 usually has a large storage capacity and high read and write performance, which can meet the basic data storage needs of the business system.

[0039] Among them, the backend disk 15 is the storage medium for backup data, used to store the target data backed up from the system disk 14. After the target data is successfully written into the system disk 14, the processor 13 stores the target data in the second memory module 12 and writes the target data into the backend disk 15 through the second write path. The backend disk 15 can adopt different storage technologies or storage locations from the system disk 14, thereby ensuring the security and reliability of the backup data. For example, the backend disk 15 can be deployed in different physical locations to prevent data loss caused by force majeure factors such as natural disasters.

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

[0041] Specifically, the processor 13 is configured 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 service system so that the service system can read and write the target data stored in the first memory module 11, thereby being able to quickly respond to the read and write requests of the service system and reducing the impact on the performance of the service system.

[0042] Among them, the target data can be data sent by the service system or data input by the user through the input device. Optionally, the target data can be user configuration information or some service data. Among them, the target data should include information such as the service module number, the internal module number, and the length of the data, so as to facilitate the processor 13 to identify and perform subsequent processing.

[0043] Among them, the first write path can be implemented based on a specific data transmission protocol and interface to ensure that the 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 store the target data in the second memory module 12 after determining that the target data has been written to the system disk 14, and write the target data to the backend disk 15 through the second write path to implement the backup of the target data.

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

[0046] It should be noted that in this embodiment, the process of writing the target data is divided into two stages and is carried out through different memory modules and write paths, reducing the conflicts and waiting time in the process of writing the target data and improving the overall efficiency and stability of writing the target data. Further, the data backup process is independent of the data read and write process of the service system. After the service system writes the target data to the first memory module 11, it can continue to run, and the backup operation of the target data is completed by the processor 13 in the background through the second memory module 12 and the second write path, without significantly affecting the normal operation of the service system.

[0047] It should be noted that in this embodiment, through the two - level storage method of the system disk 14 and the backend disk 15, the backend disk 15 serves as the backup storage of data. When the system disk 14 fails or data is lost, the backup data can be obtained from the backend disk 15 for recovery. Optionally, during data recovery, the processor 13 reads the backup data from the backend disk 15, stores it in the second memory module 12, and then writes it to the system disk 14 through the first write path or directly. Thus, the risk of data loss is reduced, and the integrity and availability of data are guaranteed.

[0048] Optionally, in actual applications, the capacities of the first memory module 11 and the second memory module 12 can also be reasonably configured according to business requirements and the size of the data volume, and the storage performance of the system disk 14 and the backend disk 15 can be optimized and adjusted to better perform data backup. For example, for a business system with frequent data reading and writing and a large data volume, the capacity of the first memory module 11 can be appropriately increased to improve the data processing speed of the business system; for scenarios with high requirements for data security, a more reliable backend disk 15 can be selected, and redundant storage technology can be adopted to further ensure data security.

[0049] Exemplarily, to better understand the solution provided by this application, a possible actual application scenario of a data backup device 10 is provided in this embodiment.

[0050] Suppose the financial system of an enterprise applies the data backup device 10 provided in this embodiment. When financial personnel perform accounting processing operations, various types of financial data generated are transmitted as target data to the processor 13. 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 this data for operations such as accounting review and data statistics. 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 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 backend disk 15 for backup through the second write path. When the system disk 14 has a hardware failure or software error resulting in data loss, the enterprise can also recover the complete financial data from the backend disk 15 to ensure the normal operation of financial work.

[0051] It should be noted that the actual application scenario of the data backup device 10 is not limited to the example scenario provided above. The data backup device 10 can also be applied in industries such as finance and healthcare.

[0052] The data backup device 10 provided by the embodiment of the present application, when target data is generated, the processor 13 stores the target data in the first memory module 11, enabling the service system to timely obtain and process the target data in the first memory module 11, meeting the real-time requirements of the service. 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 implement data backup, the processor 13 stores the target data in the second memory module 12, and then writes the target data to the backend disk 15 using the second write path, and when the target data is written to the backend disk 15, it will not affect the service system's reading and writing of the data in the first memory module 11. Thus, through an asynchronous manner and independent write paths, the target data is written to the system disk 14 and the backend disk 15 respectively, realizing the timely backup of the target data and being able to reduce the impact on system performance.

[0053] As an alternative embodiment, based on any of the above embodiments, the processor 13 is further configured to:

[0054] After receiving the target data, obtain the historical data stored in the first memory module 11, and compare the historical data with the target data.

[0055] Specifically, after the processor 13 receives the target data, first, obtain the historical data stored in the first memory module 11, and compare the historical data with the target data.

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

[0057] Among them, in this embodiment, the historical data refers to the data that already exists in the first memory module 11.

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

[0059] Specifically, if the processor 13 determines that the historical data is different from the target data, it means that the target data is new data or data that has changed. At this time, store the target data in the first memory module 11. The first memory module 11 communicates with the service system, and the service system can directly read and write the target data stored in the first memory module 11, being able to quickly respond to the reading and writing requests of the service system and reducing the impact on the performance of the service system.

[0060] Optionally, if the processor 13 determines that the historical data is the same as the target data, it indicates that the target data is duplicate data and there is no need to store and back up it again. The target data can be directly discarded or marked according to business requirements, avoiding 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 differently from the data in the historical data, so that the processor 13 can know which data in the target data is the updated data.

[0062] In the data backup device 10 provided by 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 truly needs to be stored and backed up will be processed, avoiding duplicate storage of the same data, reducing invalid data write operations, effectively saving the storage space of the system disk 14 and the backend disk 15, and ensuring the utilization efficiency of the storage resources.

[0063] Figure 2 It is a schematic structural diagram of a data backup device provided by another embodiment of the present application; as an optional implementation manner, on the basis of any of the above embodiments, as shown in Figure 2 the data backup device 10 further includes: a data buffer 16.

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

[0065] Among them, the data buffer 16 serves as a buffer area between the processor 13, the second memory module 12, and the backend disk 15, and is used to temporarily store dirty data blocks. The data buffer 16 can relieve the disk I / O pressure and avoid the impact of frequent disk write operations on the system performance. At the same time, the data buffer 16 can also store the dirty data blocks, so as to achieve the purpose of backing up only the incremental data and improve the data backup efficiency.

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

[0067] When the processor 13 stores the target data in the second memory module 12 and writes the target data to the backend disk 15 through the second write path, it is specifically used for:

[0068] storing the dirty data blocks in the target data in the data buffer 16 based on the dirty data block tags; where the dirty data blocks are the parts of the target data that are different from the historical data stored in the first memory module 11;

[0069] Optionally, after the processor 13 receives the target data, it first obtains the historical data stored in the first memory module 11, compares the historical data with the target data to determine the dirty data blocks in the target data, that is, the part different from the historical data stored in the first memory module 11, and tags the dirty data blocks to generate dirty data block tags. The processor 13 stores the dirty data blocks in the target data in the data buffer 16 based on the dirty data block tags.

[0070] Among them, the dirty data block tags are used to identify the relevant information of the dirty data blocks, such as the starting address and length of the data blocks, for subsequent processing.

[0071] Optionally, multiple dirty data blocks in the data buffer 16 are saved in a tail - append manner. It should also be noted that the data buffer 16 is only used to save data, and the information of the dirty data blocks is maintained and managed by the processor 13 or other modules.

[0072] In response to receiving the write instruction, 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 backend disk 15 through the second write path.

[0073] Optionally, after the upload of a batch of target data is completed, the business system sends a write instruction to the processor 13. When the processor 13 receives the write instruction, it 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 - writing method can effectively reduce the number of disk I / O operations and improve the data backup efficiency.

[0074] In the case where the dirty data blocks are not written to the backend disk 15 within the preset time, the write process is terminated and a full - volume backup tag is generated.

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

[0076] Among them, the preset time is the time preset for writing the dirty data blocks to the backend disk 15. Optionally, a timer can be set for timing.

[0077] Among them, the full - volume backup data refers to all the data in the first memory module 11.

[0078] Specifically, within a preset time, the processor 13 continuously monitors the writing situation of the dirty data blocks; if the dirty data blocks are not written to the backend 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, in the case where the dirty data blocks are successfully written to the backend disk 15 within the preset time, the dirty data block labels in the second memory module 12 and the backend disk 15 are cleared, and the next disk writing event is sent to the business system or other modules. When the business system or other modules receive the disk writing event, they will traverse the data blocks in the second memory module 12. If there are dirty data block labels found, the next round of disk writing will be performed, that is, the dirty data blocks in the memory module are sent to the backend disk 15. In addition, a disk writing batch number is generated each time disk writing is performed, and the disk writing batch number increases as the disk writing rounds increase.

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

[0081] In this embodiment, the second memory module 12 receives the dirty data blocks sent from the data buffer 16 and writes the dirty data blocks to the backend disk 15 through the second writing path. The existence of the second memory module 12 enables the data backup process to be independent 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 recovered from the backend disk 15. If the dirty data blocks are stored in the backend disk 15, data merging and recovery can be performed according to the dirty data block labels and the historical data in the system disk 14; if the full backup data is stored in the backend disk 15, the full backup data is directly restored to the system disk 14.

[0083] It should be noted that after the dirty data blocks are stored in the backend disk 15, the dirty data blocks can be merged with the existing data in the backend disk 15 according to the dirty data block labels.

[0084] The data backup device 10 provided by the embodiment of the present application caches and batches the write of dirty data blocks by introducing a data buffer 16, accurately identifies and processes the dirty data blocks in the target data based on the dirty data block tags, and only backs up the changed data in the target data, reducing unnecessary data transmission and storage, and saving storage space and bandwidth resources. In addition, when the dirty data blocks are not written to the backend disk 15 within the preset time, a full backup tag is generated to ensure a full backup in the next write cycle of the backend disk 15, avoiding data inconsistency problems caused by partial data backup failures and improving the integrity and recoverability of the data.

[0085] As an optional implementation manner, on the basis of 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 the backend disk 15 fails. The backup disk can adopt different storage technologies or be deployed in different physical locations from the backend disk 15 to improve data fault tolerance and security.

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

[0088] Specifically, the processor 13 can monitor the working state of the backend disk 15 in real time. When it is determined that the backend disk 15 is abnormal, it immediately obtains the historical data in the system disk 14. Then, the historical data in the system disk 14 is written to the backup disk to ensure that there is still a reliable backup storage location for the data when the backend disk 15 cannot be used normally.

[0089] Optionally, the processor 13 can determine whether the backend disk 15 is abnormal by regularly 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 the disk health status monitoring index is abnormal, it is determined that the backend disk 15 is abnormal.

[0090] It should be noted that during the abnormal period of the backend 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 the 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 the actual situation, or the backup disk can continue to be used as the data backup storage medium while repairing and maintaining the backend disk 15.

[0092] The data backup device 10 provided by the embodiment of the present application can, by introducing a backup disk, write the historical data in the system disk 14 into the backup disk in a timely manner when the backend disk 15 fails, ensuring the integrity and recoverability of the data, avoiding data loss caused by the failure of the backend disk 15, and reducing the probability of the impact on the business system due to disk failure.

[0093] Figure 3 It is a schematic structural diagram of the backend disk provided by an embodiment of the present application. Specifically, for the convenience of understanding the subsequent solutions, the data organization format of the backend disk 15 is briefly introduced and explained herein.

[0094] Refer to Figure 3 As shown in

[0095] The backend disk 15 includes a header sector, a metadata sector, and a data buffer. The header sector is located at the starting position of the backend disk 15, such as the LBA 0 sector. The header sector can record the disk writing time, record the current data buffer being written, and record the current writing batch number, etc. The metadata sector is the consecutive sectors immediately following the header sector. The metadata sector can record the metadata of each piece of stored data, such as the module identification, data length, and checksum of each metadata. The data buffer is located after the metadata sector, and the data buffer 16 is used to store data.

[0096] Exemplarily, Figure 3 There are two metadata sectors and two data buffers in

[0097] As an optional implementation manner, on the basis of any of the above embodiments, the backend disk 15 includes multiple storage areas.

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

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

[0100] Optionally, the backend disk 15 has multiple storage areas, and each storage area is assigned a unique identifier. The processor 13 sequentially writes the target data into the multiple storage areas. The writing process can be carried out in a certain order, for example, writing in sequence according to the identifiers of the storage areas, or selecting a suitable storage area for writing according to the priority of the data and the backup policy.

[0101] It should be noted that when writing data to a certain storage area, if a system crash or a writing failure occurs, the writing process is terminated, and the historical data in other storage areas is overwritten on the storage area with the writing failure, so as to ensure the data consistency of the multiple storage areas.

[0102] It should be noted that when accessing or restoring data, the processor 13 determines the storage area where the data is located according to the identification information of the data, and reads the data from the corresponding storage area. If a certain storage area fails or the data is damaged, the processor 13 can obtain 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 for different time periods, which is convenient for classifying and managing data. For example, daily backup data can be stored in one storage area, and full backup data can be stored in another storage area, which is convenient for data cleaning and archiving operations.

[0104] Optionally, the processor 13 selects a suitable storage area for writing the target data according to preset rules and policies. The preset rules and policies can be based on factors such as the remaining space of the storage area, the data type matching degree, and the backup time requirement. For example, if the target data is the business data of the day, the processor 13 can select the storage area specifically used for storing daily backup data.

[0105] In the data backup device 10 provided by the embodiment of the present application, the backend disk 15 is provided with multiple storage areas, and the multiple storage areas are independent of each other. When a certain 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 to ensure the recoverability of the data and reduce the risk of data loss. In addition, when there are problems such as system crashes during the writing process of any storage area, the historical data in other storage areas can be overwritten on the storage area with the writing failure, so as to ensure the data consistency of the multiple storage areas.

[0106] As an alternative embodiment, on the basis of any of the above embodiments, the backend disk 15 is configured with multiple; the processor 13 is further configured to: sequentially write the target data into the multiple backend disks 15.

[0107] Optionally, the multiple backend disks 15 can be storage devices of the same type, or a combination of storage devices of different types, different capacities, and different performances. For example, some of the backend disks 15 can use high-performance solid-state drives to meet the backup requirements of business data with high read and write speed requirements, and some of the backend disks 15 use large-capacity mechanical hard drives to store data that is more sensitive to cost and has a lower read and write frequency. The multiple backend disks 15 are connected to the processor 13 through a suitable interface to ensure the stability and efficiency of data transmission.

[0108] Optionally, the processor 13 is capable of real-time monitoring of the working status of the multiple backend disks 15, including the health status, remaining storage space, read and write performance, etc. of the backend disks 15. According to the monitoring results, the processor 13 can perform dynamic management on the backend disks 15. For example, when an abnormality occurs in a certain backend disk 15, it is excluded from the data write target in a timely manner.

[0109] Optionally, the writing order of the target data can be carried out according to a preset rule. For example, it is written in sequence according to the numbers of the backend disks 15, or sorted according to factors such as the remaining space size and read and write performance of the backend disks 15 and then written. Optionally, the processor 13 records the storage location information of each data block in each of the backend disks 15 for subsequent data access and recovery.

[0110] It should be noted that writing the target data to the multiple backend disks 15 in sequence forms a multi-copy storage of the data. When a certain backend disk 15 fails, the complete data is still saved in the other backend disks 15, reducing the risk of data loss and improving the reliability of the data.

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

[0112] The data backup device 10 provided by the embodiment of the present application can effectively avoid the situation of data loss caused by a single disk failure by configuring multiple backend disks 15 and controlling the target data to be written to the multiple backend disks 15 in sequence, 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, on the basis of any of the above embodiments, the processor 13 is further configured to:

[0114] Obtain the backup data stored in the data buffer of the backend disk 15 and the historical checksum recorded in the metadata sector; calculate the target checksum for each backup data; compare the target checksum with the historical checksum; in response to the inconsistency between the target checksum and the historical checksum, generate a full backup label. Specifically, the processor 13 can obtain the currently stored backup data from the data buffer of the backend disk 15, and at the same time read the recorded historical checksum from the metadata sector. The data buffer is used to store the written backup data, and the metadata sector is specifically used to store management information related to the backup data, such as historical checksum, data version, backup time, etc.

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

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

[0117] Specifically, compare the calculated target checksum with the read historical checksum bit by bit. If all bits match, it is determined that the checksums are consistent, indicating that the backup data has not changed abnormally, and no other operations need to be performed; if any bit does not match, it is determined that the checksums are inconsistent, indicating that there may be problems such as damage, tampering, or storage errors in the backup data.

[0118] Furthermore, when the target checksum is inconsistent with the historical checksum, the processor 13 automatically generates a full backup label. Among them, the full backup label can be a boolean flag bit, a specific identifier, or an instruction message, used to indicate that the system needs to perform a full backup operation instead of an incremental backup or differential backup. The system will adjust the subsequent backup strategy according to this label and give priority to full backup to ensure data integrity.

[0119] Optionally, after detecting the full backup label, 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 at the same time clears the full backup label.

[0120] It should be noted that the full backup label is generated only when the target checksum is inconsistent with the historical checksum, avoiding unnecessary full backup operations, which not only ensures the reliability of the data but also reduces the waste of storage resources.

[0121] Optionally, the processor 13 reads the currently stored backup data from the data cache area of the backend disk 15 regularly or according to a preset trigger condition. By regularly comparing the target checksum with the historical checksum, abnormal situations of the backup data can be detected, avoiding business risks caused by data corruption or tampering. Optionally, the preset trigger condition can be a scheduled task or a data update event, etc.

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

[0123] The data backup device 10 provided by the embodiments of the present application calculates the target checksum of the current backup data by obtaining the backup data stored in the data cache area of the backend disk 15 and the historical checksum recorded in its metadata sector, and compares it with the historical checksum. When inconsistency is found, a full backup label is generated, so that abnormal data situations can be detected in time, and the full backup process is triggered to ensure the accuracy and consistency of the backup data.

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

[0125] After determining that the system disk 14 has a fault, obtain the backup data stored in the data cache area of the backend disk 15 and perform data verification on the backup data; after the backup data passes the verification, write the backup data into the system disk 14.

[0126] Specifically, after confirming the fault of the system disk 14, the processor 13 triggers a data recovery process to obtain the pre-stored backup data from the data cache area of the backend disk 15. Then, strict verification is performed on the obtained backup data. Only when the backup data passes the verification, the processor 13 writes the backup data into the restored or replaced system disk 14 to ensure the correctness of the written data.

[0127] Optionally, the running state of the system disk 14 can be continuously monitored by the processor 13 or other monitoring tools, and it is judged whether the system disk 14 has a fault through indicators such as hardware health status detection, I / O response time, and error count. Fault detection can adopt a regular polling or event-driven method to ensure that problems are discovered in time.

[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 head and tail markers, data block order; business logic verification, such as legality check for specific data formats.

[0129] The data backup device 10 provided by the embodiment of the present application starts a data recovery process after the system disk 14 fails, and restores the data of the system disk 14 through the backup data stored in the backend disk 15, reducing the service interruption time. In addition, the backup data is written to the system disk 14 only after passing the verification, avoiding introducing incorrect data into the system disk 14 and ensuring the accuracy of the data.

[0130] As an alternative implementation, based on any of the above embodiments, multiple backend disks 15 are configured; backup data is stored in all of the multiple backend 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 and deployed to prevent all backups from failing due to a single point of failure.

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

[0133] Obtain the write batch numbers recorded in the head sectors of multiple backend disks 15, and compare the multiple write batch numbers; determine the target backend disk corresponding to the largest write batch number among the multiple write batch numbers; obtain the backup data stored in the data buffer of the target backend 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 backend disks 15 in parallel, parses the timestamps and sequence numbers of each write batch number, and selects the backup data in the target backend disk with the largest write batch number for data recovery by comparing the write batch numbers recorded in the head sectors of each backend 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 being applicable to enterprise-level storage systems that require high reliability.

[0135] Optionally, during each backup operation, the processor 13 writes a unique write batch number to the head sectors of all backend disks 15, and the format can be "YYYYMMDD-HHMMSS-SEQ".

[0136] Optionally, each backend disk 15 is configured with an independent power protection circuit to avoid problems with multiple backend disks 15 occurring simultaneously.

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

[0138] The data backup device 10 provided by the embodiment of the present application forms a redundant backup architecture by setting multiple backend disks 15, and each backend disk 15 stores complete backup data, so as to prevent the situation that all backup data becomes invalid due to a single point of failure. When the system disk 14 fails, by comparing the write batch numbers recorded in the head sectors of each backend disk 15, the backup data in the target backend disk with the largest write batch number is selected for data recovery, ensuring that the latest valid backup data can always be obtained, thereby solving the problem of data consistency selection in the multi-backup source scenario.

[0139] Figure 4 It is a schematic flowchart of a data backup method provided by an embodiment of the present application. As Figure 4 shown, the execution subject of this embodiment is a processor. The data backup method provided by this embodiment specifically includes the following steps:

[0140] S201. In response to receiving the target data, store the target data in the first memory module, and write the target data to the system disk through the first write path. The first memory module is used to communicate with the service system so that the service system can read and write the target data stored in the first memory module.

[0141] S202. After 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.

[0142] Optionally, the data backup method further includes: after receiving the target data, obtain the 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, store the target data in the first memory module.

[0143] Optionally, storing the target data in the second memory module and writing the target data to the backend disk through the second write path includes: storing the dirty data blocks in the target data in the data buffer based on the dirty data block tags; where the dirty data blocks are the parts in the target data that are different from the historical data stored in the first memory module; after receiving the write instruction, store multiple dirty data blocks in the data buffer in the second memory module; and write the dirty data blocks to the backend disk through the second write path; in the case that the dirty data blocks are not written to the backend disk within the preset time, terminate the write process and generate a full backup tag; where 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 backend disk and write the full backup data to the backend disk.

[0144] Optionally, the data backup method further includes: in response to determining that an abnormality exists in the backend disk, obtaining historical data in the system disk; and writing the historical data in the system disk into the backup disk.

[0145] Optionally, the data backup method further includes: obtaining backup data stored in a data buffer area of the backend disk and historical checksums recorded in a metadata sector; calculating target checksums for each piece of backup data; comparing the target checksums with the historical checksums; and in response to the target checksums being inconsistent with the historical checksums, generating a full backup label.

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

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

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

[0149] Optionally, the data backup method further includes: sequentially writing target data into multiple backend disks.

[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 data backup apparatus above. Therefore, they will not be elaborated in this embodiment.

[0151] Figure 5 The following is a schematic structural diagram of an electronic device provided by an embodiment of the present application. As Figure 5 shown, the electronic device 30 provided by the embodiment of the present application includes a data memory 31 and a data processor 32.

[0152] A computer program is stored in the data memory 31, and the data processor 32 is configured to run the computer program to execute the steps in any of the above embodiments of the data backup method.

[0153] The 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 in any of the above embodiments of the data backup method when running.

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

[0155] The embodiments of the present application also provide a computer program product. The computer program product includes a computer program, and when the computer program is executed by a data processor, it implements the steps in any of the above-described embodiments of the data backup method.

[0156] The embodiments of the present application also provide another computer program product, including a non-volatile computer-readable storage medium. The non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, it implements the steps in any of the above-described embodiments of the data backup method.

[0157] Those skilled in the art can further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Skilled professionals can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present application.

[0158] The above has introduced in detail a data backup device, method, device, and storage medium provided by the present application. Specific examples are used herein to elaborate on the principles and implementation manners of the present application. The description of the above embodiments is only used to help understand the method and its core idea of the present application. It should be noted that for those of ordinary skill in the art in the technical field, without departing from the principle of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the protection scope of the claims of the present application.

Claims

1. A data backup device, characterized in that, Including: A first memory module, a second memory module, a processor, a system disk, and a backend disk, where 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; The processor is configured to, in response to receiving target data, store the target data in the first memory module and write the target data to the system disk through a first write path. The first memory module is used to communicate with a service system so that the service system can read and write the target data stored in the first memory module; The processor is further configured to, in response to determining that the target data has been written to the system disk, store the target data in the second memory module and write the target data to the backend disk through a second write path.

2. The device according to claim 1, wherein The processor is further 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, store the target data in the first memory module.

3. The device according to claim 1, characterized in that, The apparatus further includes: a data buffer; When the processor stores the target data in the second memory module and writes the target data to the backend disk through the second write path, the processor is specifically configured to: Store the dirty data blocks in the target data in the data buffer based on dirty data block tags; where the dirty data blocks are the parts of the target data that are different from the historical data stored in the first memory module; In response to receiving a write instruction, store multiple dirty data blocks in the data buffer in the second memory module; and write the dirty data blocks to the backend disk through the second write path; In the case where the dirty data blocks have not been written to the backend disk within a preset time, terminate the write process and generate a full backup tag; where the full backup tag is used to instruct the processor to obtain full backup data stored in the first memory module and write the full backup data to the backend disk in the next write cycle of the backend disk.

4. The device according to claim 1, characterized in that, The apparatus further includes a backup disk; the processor is further configured to: In response to determining that the backend disk is abnormal, obtain historical data in the system disk; Write the historical data in the system disk to the backup disk.

5. The device according to any one of claims 1-4, characterized in that, The processor is further configured to: Obtain backup data stored in a data buffer area of the backend disk and historical checksums recorded in a metadata sector; Calculate target checksums for each of the backup data; Compare the target checksums with the historical checksums; In response to the target checksums being inconsistent with the historical checksums, generate a full backup tag.

6. The device according to any one of claims 1-4, characterized in that The processor is further configured to: In response to determining that the system disk has failed, obtain backup data stored in a data buffer area of the backend disk and perform data verification on the backup data; After the backup data passes the verification, write the backup data to the system disk.

7. The device according to claim 6, characterized in that A plurality of the backend disks are configured; the backup data is stored in all of the plurality of backend disks; The processor, after determining that the system disk has a fault in response thereto, is further configured to: Obtain the write batch numbers recorded in the head sectors of the plurality of backend disks, and compare the plurality of write batch numbers; Determine the target backend disk corresponding to the largest write batch number among the plurality of write batch numbers; Obtain the backup data stored in the data buffer of the target backend disk and perform data verification on the backup data.

8. A data backup method, characterized in that, Includes: In response to receiving target data, store the target data in a first memory module, and write the target data to the system disk through a first write path, where the first memory module is used to communicate with a service system so that the service system reads and writes the target data stored in the first memory module; After determining that the target data is written to the system disk in response thereto, store the target data in a second memory module, and write the target data to the backend disk through a second write path.

9. An electronic device, characterized in that, Includes: A memory for storing a computer program; A processor for implementing the steps of the data backup method as claimed in claim 8 when executing the computer program.

10. A computer-readable storage medium, characterized in that, A computer program is stored in the computer-readable storage medium, wherein the computer program, when executed by a processor, implements the steps of the data backup method as claimed in claim 8.

Images