Snapshot-free volume real-time backup method, system and device and storage medium

Abstract

The invention relates to a snapshot-free volume real-time backup method, system and device and a storage medium, and belongs to the technical field of disaster recovery backup. The method applied to the client side comprises the steps that a filtering drive program captures IO operation and stores change data into a drive cache; the backup client program then reads the disk data and the change data from the disk and the drive cache respectively, and then sends the data to the backup server program. The method applied to the server side comprises the steps that the backup server side program receives and stores initially synchronized disks and change data, and after the disks are read, the backup server side program merges the data to create a complete recoverable backup set. According to the method, the snapshot operation can not be executed in the initial synchronization stage of the production volume, so that the consistency of data after complete synchronization is finished can be ensured, and the consumption of the backup host in the aspects of memory, CPU and disk I / O resources can be reduced at the same time.

Description

Technical Field

[0001] The invention belongs to the technical field of disaster recovery and backup, and relates to a real-time backup method, system, equipment and storage medium without snapshot volumes. Background Art

[0002] Currently, volume real-time backup technology is generally divided into two main stages: Initial synchronization phase of the production volume: After the task is started, a snapshot is created for the production volume, and the backup client then backs up the snapshot data to the image space on the server through the network; Real-time production volume change data monitoring stage: Once the snapshot is created, the driver module of the backup client will monitor the changes in the production volume and synchronize the real-time change data to the log space of the backup system.

[0003] Since the initial synchronization of production volumes requires the creation of snapshots, the existence of snapshots will affect the performance of the production host, which may cause the backup task to fail, and in extreme cases, even cause serious accidents such as host freezing. Currently, there is almost no existing technology that discloses a real-time volume backup method without snapshots, which can simultaneously reduce the consumption of backup host memory, CPU, and disk I / O resources.

[0004] Therefore, how to avoid creating snapshots during the initial synchronization phase of the production volume while reducing the consumption of backup host memory, CPU, and disk I / O resources is a technical problem that urgently needs to be solved. Summary of the invention

[0005] In order to solve the technical problems in the above-mentioned background technology, the present invention provides a real-time backup method, system, device and storage medium without snapshot volume.

[0006] The technical solution of the present invention to solve the above technical problems is as follows: In a first aspect, a method for real-time backup of a volume without snapshot is provided, the method being applied to a client and comprising the steps of: The filter driver writes the captured change data into the driver cache; According to the backup task, the backup client program continuously reads the changed data from the drive cache and reads the disk data from the production volume; The backup client program continuously sends the changed data and disk data to the backup server program; When all disk data is read, the backup client program stops reading the changed data and disk data, marks the first recovery time point, and then sends the first recovery time point to the backup server program; the backup server program is used to receive and save the changed data and disk data. The backup server program is also used to merge all the changed data and disk data before the first recovery time point when the first recovery time point is obtained.

[0007] In a second aspect, a method for real-time backup of a volume without snapshot is provided, the method being applied to a server and comprising the steps of: The backup server program continuously receives and saves the changed data and disk data, which are sent by the backup client program; The backup server program receives the first recovery time point, and then merges all the change data and disk data in the local end before the first recovery time point to obtain the initial synchronization data. The first recovery time point is sent by the backup client program; the backup client program is used to stop reading the change data and disk data when all disk data is read, and mark the first recovery time point; the backup client program is also used to continuously read the change data from the driver cache and the disk data from the production volume according to the backup task, wherein the change data is captured by the filter driver and placed in the driver cache by the filter driver.

[0008] In a third aspect, a real-time backup system without snapshot volumes is provided, the system being applied to a client and comprising: Capture module, used for filtering the driver to write the captured change data into the driver cache; The continuous reading module is used for the backup client program to continuously read the changed data from the drive cache and the disk data from the production volume according to the backup task; The continuous sending module is used for the backup client program to continuously send the changed data and disk data to the backup server program; The module for sending recovery time points is used to stop the backup client program from reading the changed data and disk data when all disk data is read, and to mark the first recovery time point, and then send the first recovery time point to the backup server program; the backup server program is used to receive and save the changed data and disk data, and the backup server program is also used to merge all the changed data and disk data before the first recovery time point when the first recovery time point is obtained.

[0009] In a fourth aspect, a real-time backup system without snapshot volumes is provided, the system being applied to a server and comprising: The receiving and saving module is used for the backup server program to continuously receive and save the changed data and disk data, which are sent by the backup client program; The merging module is used for the backup server program to receive the first recovery time point, and then merge all the change data and disk data in the local end before the first recovery time point to obtain the initial synchronization data. The first recovery time point is sent by the backup client program; the backup client program is used to stop reading the change data and disk data when all the disk data is read, and mark the first recovery time point; the backup client program is also used to continuously read the change data from the driver cache and the disk data from the production volume according to the backup task, wherein the change data is captured by the filter driver and placed in the driver cache by the filter driver.

[0010] In a fifth aspect, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the steps of the method for real-time backup of a volume without snapshot as described in any one of the above items are implemented.

[0011] In a sixth aspect, a computer-readable storage medium is provided, on which a computer program is stored, and when the program is executed by a processor, the real-time backup method without snapshot volume is implemented as described above.

[0012] The beneficial effects of the present invention are: The present invention does not perform snapshot operations in the initial synchronization stage of the production volume, which can reduce the consumption of system resources by snapshots. Instead, the data of the original disk is directly read and transmitted, and all the changed data generated during the reading of the original disk is also sent to the original image of the backup server program for merging. This not only ensures the consistency of data after the full synchronization is completed, but also reduces the consumption of memory, CPU and disk I / O resources of the backup host. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0014] Figure 1 A schematic flow chart of a method for real-time backup of a client without snapshot volumes provided by an embodiment of the present invention.

[0015] Figure 2 The figure is a flow chart of the interaction process between the client and the server according to an embodiment of the present invention.

[0016] Figure 3 A schematic flow chart of a method for real-time backup of a server without snapshot volumes provided in an embodiment of the present invention.

[0017] Figure 4 The figure is a schematic diagram of merging changed data and disk data in a server according to an embodiment of the present invention.

[0018] Figure 5 A schematic diagram of the structure of a real-time backup system without snapshot volumes in a client provided by an embodiment of the present invention.

[0019] Figure 6 A schematic diagram of the structure of a real-time backup system without snapshot volumes in a server provided by an embodiment of the present invention.

[0020] Figure 7 This is a schematic diagram of the structure of the receiving and saving modules according to an embodiment of the present invention.

[0021] Figure 8 This is a schematic diagram of the structure of the merging module according to an embodiment of the present invention.

[0022] Fig. 9 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention.

[0023] In the accompanying drawings, the components represented by the reference numerals are listed as follows: 3001, capture module; 3002, continuous reading module; 3003, continuous sending module; 3004, sending recovery time point module; 4001, receiving and saving module; 4002, merging module; 40011, first receiving unit; 40012, partition storage unit; 40021, second receiving unit; 40022, initial merging unit; 40023, recording marking unit; 40024, designated time interval data synchronization unit; 40025, secondary merging unit; 510, processor; 520, communication interface; 530, memory; 540, communication bus. DETAILED DESCRIPTION

[0024] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0025] When performing the initial synchronization phase of the production volume, the impact of creating snapshots on the performance of the production host is obvious. As a data protection technology, snapshots can provide instant data backup, but their existence will also consume system resources. Snapshot technologies, such as mirror separation and copy-on-write (COW), require additional storage space and processing power when creating, which will cause the performance of the production host to degrade. Especially in the case of huge data volume or insufficient system resources, the backup client may occupy too many system resources, OOM (Out of Memory) problems may occur, and the backup task will fail. In addition, although snapshot technology can complete data replication in an instant and reduce the impact of backup on application and host performance, its impact on performance cannot be ignored in scenarios where data changes frequently. In existing technologies, although technologies such as CDP (continuous data protection) can provide more fine-grained data recovery capabilities, the application and popularization of these technologies are still limited, and resource consumption is also a consideration. Therefore, the impact of snapshots on the performance of production hosts, as well as possible serious accidents such as backup task failure or host freezing, are urgent issues to be solved in the current data backup field, especially in seeking a real-time volume backup method without snapshots to reduce the consumption of backup host memory, CPU and disk I / O resources.

[0026] In view of the above problems, an embodiment of the present invention provides a real-time backup method without snapshot volumes. Figure 1 A flow chart of a method for real-time backup of volumes without snapshots provided by an embodiment of the present invention is shown in FIG. Figure 1 As shown, the method is applied to the client and includes the steps of: Step S101: The filter driver writes the captured change data into the driver cache.

[0027] It is understandable that the filter driver, as a low-level software component, works at the volume layer, that is, below the file system and above the operating system, to intercept I / O operations on storage volumes. The main functions of the filter driver include monitoring, tracking, and managing data changes on the disk, and operating or controlling I / O requests when necessary, such as allowing or denying specific write operations. The filter driver can capture real-time change data.

[0028] It can also be understood that the driver cache is a cache inside the filter driver, which works at the volume management level of the operating system, which is lower than the file system level. When data is written to the disk, the filter driver captures the changed data in real time and stores it in the driver cache so that the backup client program can quickly access the data.

[0029] The driver cache type can be a memory cache or a disk cache. The memory cache is a cache stored in the memory, which can provide extremely fast data access speed and is suitable for fast backup and recovery operations. The disk cache is a cache stored on the disk, which is suitable for storing larger data sets. Although the access speed is not as fast as the memory, it can store more data. The embodiments of the present invention do not specifically limit this.

[0030] The changed data is first placed in the driver cache, and then the data is directly extracted from the driver cache and sent to the server. The driver cache is located in a faster storage medium (such as memory, disk), which reduces the number of direct accesses to slower physical disks and reduces disk I / O operations, thereby increasing data access speed and data transmission speed, thereby speeding up data processing and transmission efficiency. In addition, the driver cache serves as a temporary storage area to ensure that all changed data has been updated to the latest state before the data is sent to the server, which helps maintain data consistency. At the same time, the data in the driver cache can reduce the risk of data loss when the system crashes or other failures occur, because the data has been stored in the driver cache before being sent, providing an additional layer of data protection.

[0031] Step S102: According to the backup task, the backup client program continuously reads the changed data from the drive cache and reads the disk data from the production volume.

[0032] It is understandable that the two operations continuously performed by the backup client program: reading the changed data from the drive cache and reading the disk data from the production volume, can be performed simultaneously or sequentially as required. This embodiment does not specifically limit this.

[0033] Step S103: the backup client program continues to send the changed data and disk data to the backup server program.

[0034] The backup client program can implement this step by creating two threads: one thread is used to read / send disk data, and the other thread is used to read / send changed data. If the system resources are sufficient and the data changes frequently, the two threads can be executed in parallel. The thread that reads / sends disk data is responsible for obtaining / sending data from the original storage medium, while the thread that reads / sends changed data handles new changes generated during the backup process. This can reduce the backup window, that is, the time required to complete the backup, thereby reducing the impact on the production environment; if resources are limited, or data changes are not very frequent, or other optimization methods can be used to improve efficiency, the thread priority can also be adjusted. The embodiments of the present invention do not specifically limit this.

[0035] It is worth noting that the above reading process is continuous because data changes are continuous. The backup client needs to constantly monitor and capture data changes to ensure that the backed up data is up to date. This continuous monitoring and data transmission ensures the real-time and integrity of the backup data.

[0036] It is also worth noting that the continuity of continuously monitoring and processing data changes ensures that the backup process will not generate a peak in resource consumption due to the creation of snapshots, thereby reducing the impact on the production environment. By capturing and driving cache data changes in real time, the method of this embodiment allows data backup to be performed in parallel with production activities without waiting for the completion of snapshot creation. This not only reduces the instantaneous demand for CPU, memory, and disk I / O, but also avoids performance bottlenecks caused by snapshot creation. Especially in an environment where data changes frequently, this continuous and progressive backup method is more efficient and can continuously protect data while minimizing the occupation of production resources.

[0037] Step S104, when all disk data is read, the backup client program stops reading the changed data and disk data, marks the first recovery time point, and then sends the first recovery time point to the backup server program; the backup server program is used to receive and save the changed data and disk data, and the backup server program is also used to merge all the changed data and disk data before the first recovery time point when the first recovery time point is obtained.

[0038] It is worth noting that the determination of the first recoverable time point ensures the consistency of the backup data. Before this point, all data changes (including disk data and real-time data) need to be captured and backed up so that they can be restored to the state at this time point when needed.

[0039] In order to facilitate the understanding of the interaction process between the client and the server, such as Figure 2 As shown, the details are as follows: The production application (production APP) writes data on the disk, and the filter driver immediately detects the IO operation on the disk and writes the detected change data to the driver cache of the backup client program. The backup system client program (application layer) reads data from the disk and sends the initial synchronization disk data to the backup server program. The backup system client program (application layer) reads the change data from the driver cache and sends the initial synchronization change data to the backup server program.

[0040] The backup server program receives and saves the disk data during the initial synchronization process, and receives and saves the changed data during the initial synchronization process. Once the initial synchronization is completed, the backup server program merges the disk data with the changed data to form a complete initial recoverable data set. The backup source is the production environment data volume that needs to be backed up, such as the C drive of the Windows system.

[0041] This embodiment does not perform a snapshot operation during the initial synchronization phase of the production volume, which can reduce the consumption of system resources by the snapshot. Instead, the data of the original disk is directly read and transmitted, and all the changed data generated during the reading of the original disk is also sent to the original image of the backup server program for merging. This not only ensures the consistency of the data after the full synchronization is completed, but also reduces the consumption of memory, CPU and disk I / O resources of the backup host.

[0042] Based on the above embodiment, in the method, step S104 includes: Step S1041, when all disk data is read, the backup client program refreshes the driver cache; Step S1042, the backup client program checks whether all the changed data in the driver cache are sent to the production volume disk. If all are sent, the backup client program stops reading the changed data and disk data, and marks the first recovery time point, and then executes the next step; if not, refresh the driver cache, and repeat the current checking step; Step S1043: the backup client program sends the first recovery time point to the backup server program.

[0043] In this embodiment, in the absence of a snapshot initial backup, the backup client will completely read all data on the disk. After this process is completed, a refresh operation is performed on the backup host to ensure that the driver cache data in the backup client program is completely written to the disk. This ensures the integrity and consistency of the backup data and avoids data loss or obsolescence due to failure to write the driver cache in a timely manner.

[0044] like Figure 3 As shown, this embodiment provides a method for real-time backup of volumes without snapshots, which is applied to a server and includes the following steps: Step S201, the backup server program continuously receives and saves the change data and disk data, which are sent by the backup client program; In step S202, the backup server program receives the first recovery time point, and then merges all the change data and disk data in the local end before the first recovery time point to obtain initial synchronization data. The first recovery time point is sent by the backup client program; the backup client program is used to stop reading the change data and disk data when all disk data is read, and mark the first recovery time point; the backup client program is also used to continuously read the change data from the driver cache and the disk data from the production volume according to the backup task, wherein the change data is captured by the filter driver and placed in the driver cache by the filter driver.

[0045] To facilitate understanding of the merging process, Figure 4 As shown, we provide an operation example: Figure 4 It contains four parts, each of which is a 4x4 matrix representing the data status on the disk.

[0046] (1) Disk initial status The matrix in the upper left corner shows the initial state of the disk, where the second to fourth positions in the first row are 1, 2, and 3 respectively, and the rest are 0; (2) Data obtained by reading the original disk data The matrix in the lower left corner shows the original disk data read during the initial synchronization. This data reflects the disk status at the beginning of the initial synchronization. It is the same as the starting status. The second position to the fourth position of the first row are 1, 2, and 3 respectively. At the same time, the first position of the second row becomes 1, the first position and the second position of the third row become 2, and the first position to the third position of the fourth row become 3. The rest are 0; (3) Monitored disk change data The matrix in the lower right corner shows the disk change data monitored during the initial synchronization. These changes include: the second to fourth positions of the second row change from 0 to 1, the third and fourth positions of the third row change from 0 to 2, and the fourth position of the fourth row change from 0 to 3; (4) Initial synchronization ends disk status The matrix in the upper right corner shows the disk status at the end of the initial synchronization, that is, the disk status after the merge is completed. Compared with the initial status, the first to fourth positions of the second row change from 0 to 1, the first to fourth positions of the third row change from 0 to 2, and the first to fourth positions of the fourth row change from 0 to 3.

[0047] In order to obtain the final consistent data state, the monitored disk change data needs to be merged into the original disk data read. For the data at each location, if there is an update in the change data (that is, a non-zero value), the value in the original disk data is replaced with the value in the change data. If there is no update in the change data (that is, the value is 0), the value in the original disk data is retained.

[0048] In this embodiment, during the disk synchronization process, directly reading the original disk data may cause data inconsistency because the I / O operations occurring at the same time may update the data on the disk. To solve this problem, the change data captured during the initial synchronization is merged into the disk data that has been read, which can ensure that the backup data set reflects a consistent time point, thereby avoiding the difference between the backup data and the actual data state, ensuring the integrity and consistency of the backup data, which can effectively reduce the consumption of production resources caused by snapshot creation, while improving the accuracy and reliability of data backup.

[0049] Based on the above embodiment, in the method, step S201 includes: Step S2011, the backup server program continues to receive the changed data and disk data; Step S2012, partition and store the changed data and disk data according to the time series, wherein a time index is set for each changed data point, and the time index records the specific moment of the data change; the disk data is partitioned according to the creation or modification time of the data.

[0050] In order to improve the efficiency and query performance of the backup system, this embodiment uses time series partition storage. By setting an accurate time index for each change data point, data can be retrieved quickly and the latency of large-scale data queries can be reduced. Disk data is also partitioned by creation or modification time to optimize storage and facilitate recovery and analysis.

[0051] In addition, according to the frequency and importance of data access, this embodiment can adopt a differentiated management strategy, using high-performance storage for recent data and migrating old data to a low-cost solution, which can enhance the flexibility and scalability of the system and reduce operation and maintenance costs.

[0052] Based on the above embodiment, in the method, step S202 includes: Step S2021, the backup server program receives a first recovery time point; Step S2022, the backup server program merges all the change data and disk data in the local end before the first recovery time point, and notifies the backup client program to stop sending the change data; Step S2023, the backup server program records the time when the merge is executed, and marks the second recovery time point; Step S2024, the backup server program sends the second recovery time point to the backup client program, and notifies the backup client program to send the change data between the first recovery time point and the second recovery time point; Step S2025: The backup server program receives the change data between the first recovery time point and the second recovery time point, and updates the initial synchronization data according to the change data.

[0053] The backup server program receives the timestamp of the end of the initial synchronization, i.e., the first recovery time point. At this time, all data changes and disk data before this time are merged, defining the end of the initial synchronization phase. Subsequently, the backup server program notifies the client to stop sending change data because the initial synchronization has been completed. Next, the backup server program records the time when the merge is completed as the second recovery time point. The second recovery time point is determined after the merging process is completed. It represents the new state of the backup data and requests the client to send the change data between the two time points. Finally, the backup server program receives and updates this data to ensure that the backup data contains all changes between the two recovery time points. In this way, this embodiment ensures the consistency and integrity of the backup data through precise time point control and data merging.

[0054] At the same time, the backup server can check the timestamps of data changes after the merge to ensure that no data changes are earlier than the first recovery time point. If an earlier data change is found, this indicates that there may be a data synchronization problem and a new merge is required. In this way, data integrity can be ensured, and potential data consistency issues can be quickly identified and resolved, that is, by introducing a second recovery time point, the correctness of the merge can be more easily verified.

[0055] like Figure 5 As shown, in one embodiment, a real-time backup system without snapshot volume is provided, and the system is applied to a client, comprising: Capture module 3001, used for filtering the driver to write the captured change data into the driver cache; The continuous reading module 3002 is used for the backup client program to continuously read the changed data from the drive cache and the disk data from the production volume according to the backup task; The continuous sending module 3003 is used for the backup client program to continuously send the changed data and disk data to the backup server program; The module 3004 for sending recovery time point is used to stop the backup client program from reading the change data and disk data when all disk data is read, and to mark the first recovery time point, and then send the first recovery time point to the backup server program; the backup server program is used to receive and save the change data and disk data, and the backup server program is also used to merge all the change data and disk data before the first recovery time point when the first recovery time point is obtained.

[0056] This embodiment can capture the write operations of production applications on the disk in real time, and send these change data to the server in a timely manner through the backup system client program installed on the production host, thereby ensuring real-time backup and continuous protection of data.

[0057] like Figure 6 As shown, in one embodiment, a real-time backup system without snapshot volumes is provided, and the system is applied to a server, including: Receiving and saving module 4001, used for the backup server program to continuously receive and save the change data and disk data, which are sent by the backup client program; The merge module 4002 is used for the backup server program to receive the first recovery time point, and then merge all the change data and disk data in the local end before the first recovery time point to obtain the initial synchronization data. The first recovery time point is sent by the backup client program; the backup client program is used to stop reading the change data and disk data when all the disk data is read, and mark the first recovery time point; the backup client program is also used to continuously read the change data from the driver cache and the disk data from the production volume according to the backup task, wherein the change data is captured by the filter driver and placed in the driver cache by the filter driver.

[0058] like Figure 7 As shown, the receiving and saving module 4001 includes: The first receiving unit 40011 is used for the backup server program to continuously receive the change data and disk data; The partition storage unit 40012 is used to partition and store the change data and disk data according to the time series, wherein a time index is set for each change data point, and the time index records the specific moment of the data change; the partition of the disk data is partitioned according to the creation or modification time of the data.

[0059] like Figure 8 As shown, the merging module 4002 includes: The second receiving unit 40021 is used for the backup server program to receive the first recovery time point; The first merging unit 40022 is used for the backup server program to merge all the change data and disk data in the local end before the first recovery time point, and to notify the backup client program to stop sending the change data; Record marking unit 40023, used for backing up the server program to record the time of executing the merge, and marking the second recovery time point; The designated time interval data synchronization unit 40024 is used for the backup server program to send the second recovery time point to the backup client program, and to notify the backup client program to send the change data between the first recovery time point and the second recovery time point; The secondary merging unit 40025 is used for the backup server program to receive the change data between the first recovery time point and the second recovery time point, and to update the initial synchronization data according to the change data.

[0060] The backup server program of this embodiment receives the change data sent by the client and merges it with the initial synchronization data to achieve a complete backup set, so that there is no need to generate snapshots on the production side. Through strategies such as time series partition storage, the server optimizes data storage and access, ensures rapid recovery capabilities, and effectively reduces operation and maintenance costs.

[0061] exist Fig. 9 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention, such as Fig. 9 As shown, the electronic device may include: a processor 510, a communication interface 520, a memory 530 and a communication bus 540, wherein the processor 510, the communication interface 520 and the memory 530 communicate with each other via the communication bus 540. The processor 510 may call the logic instructions in the memory 530 to execute the real-time backup method without snapshot volume described in the above embodiment.

[0062] In addition, the logic instructions in the above-mentioned memory 530 can be implemented in the form of a software functional unit and can be stored in a computer-readable storage medium when it is sold or used as an independent product. Based on such an understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc. Various media that can store program codes.

[0063] In this embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the program is executed by a processor, the method for real-time backup of volumes without snapshots described in the above embodiment is implemented.

[0064] The computer storage medium of the embodiment of the present invention can adopt any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium can be, for example, but not limited to, a system, device or device of electricity, magnetism, light, electromagnetic, infrared, or semiconductor, or any combination of the above. More specific examples (non-exhaustive list) of computer-readable storage media include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this document, a computer-readable storage medium can be any tangible medium containing or storing a program, which can be used by an instruction execution system, a device or a device or used in combination with it.

[0065] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, which carry computer-readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0066] The program code embodied on the computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0067] Computer program code for performing the operations of the present invention may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, Ruby, Go, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0068] The above-mentioned embodiments only express several implementation methods of the present invention, and the description thereof is relatively specific and detailed, but it cannot be understood as limiting the scope of the patent of the present invention. It should be pointed out that, for ordinary technicians in this field, several variations and improvements can be made without departing from the concept of the present invention, which all belong to the protection scope of the present invention. Therefore, the protection scope of the patent of the present invention shall be subject to the attached claims.

Claims

1. A method for real-time backup of volumes without snapshots, characterized in that: The method is applied to a client and comprises the steps of: The filter driver writes the captured change data into the driver cache; According to the backup task, the backup client program continuously reads the changed data from the drive cache and reads the disk data from the production volume; The backup client program continuously sends the changed data and disk data to the backup server program; When all disk data is read, the backup client program stops reading the changed data and disk data, marks the first recovery time point, and then sends the first recovery time point to the backup server program; The backup server program is used to receive and save the changed data and disk data. The backup server program is also used to merge all the changed data and disk data before the first recovery time point when the first recovery time point is obtained.

2. The method for real-time backup without snapshot volume according to claim 1, characterized in that: When all disk data is read, the backup client program stops reading the changed data and disk data, marks the first recovery time point, and sends the first recovery time point to the backup server program, and also includes: When all disk data is read, the backup client program refreshes the driver cache; The backup client program checks whether all the changed data in the driver cache are sent to the production volume disk. If all are sent, the backup client program stops reading the changed data and disk data, marks the first recovery time point, and then executes the next step; if not, refresh the driver cache and repeat the check step; The backup client program sends the first recovery time point to the backup server program.

3. A real-time backup method without snapshot volume, characterized in that: The method is applied to the server and comprises the steps of: The backup server program continuously receives and saves the changed data and disk data, which are sent by the backup client program; The backup server program receives the first recovery time point, and then merges all the change data and disk data in the local end before the first recovery time point to obtain the initial synchronization data. The first recovery time point is sent by the backup client program. The backup client program is used to stop reading the changed data and disk data when all disk data is read, and mark the first recovery time point; The backup client program is also used to continuously read the changed data from the driver cache and the disk data from the production volume according to the backup task, wherein the changed data is captured by the filter driver and placed in the driver cache by the filter driver.

4. The method for real-time backup without snapshot volume according to claim 3, characterized in that: The backup server program continuously receives and saves the changed data and disk data, including: The backup server program continuously receives the changed data and disk data; The changed data and disk data are partitioned and stored according to the time series, wherein a time index is set for each changed data point, and the time index records the specific time when the data changes; the disk data is partitioned according to the creation or modification time of the data.

5. The method for real-time backup without snapshot volume according to claim 3, characterized in that: The backup server program receives the first recovery time point, and then merges all the change data and disk data in the local end before the first recovery time point to obtain the initial synchronization data step, and also includes: The backup server program receives the first recovery time point; The backup server program merges all the changed data and disk data in the local terminal before the first recovery time point, and notifies the backup client program to stop sending the changed data; The backup server program records the time when the merge is executed, marking the second recovery time point; The backup server program sends the second recovery time point to the backup client program, and notifies the backup client program to send the change data between the first recovery time point and the second recovery time point; The backup server program receives the change data between the first recovery time point and the second recovery time point, and updates the initial synchronization data according to the change data.

6. A real-time backup system without snapshot volume, characterized in that: The system is applied to a client and includes: Capture module, used for filtering the driver to write the captured change data into the driver cache; The continuous reading module is used for the backup client program to continuously read the changed data from the drive cache and the disk data from the production volume according to the backup task; The continuous sending module is used for the backup client program to continuously send the changed data and disk data to the backup server program; The module for sending recovery time points is used to stop the backup client program from reading the changed data and disk data when all disk data is read, and to mark the first recovery time point, and then send the first recovery time point to the backup server program; the backup server program is used to receive and save the changed data and disk data, and the backup server program is also used to merge all the changed data and disk data before the first recovery time point when the first recovery time point is obtained.

7. A real-time backup system without snapshot volume, characterized in that: The system is applied to the server, including: The receiving and saving module is used for the backup server program to continuously receive and save the changed data and disk data, which are sent by the backup client program; The merging module is used for the backup server program to receive the first recovery time point, and then merge all the change data and disk data in the local end before the first recovery time point to obtain the initial synchronization data. The first recovery time point is sent by the backup client program; the backup client program is used to stop reading the change data and disk data when all the disk data is read, and mark the first recovery time point; the backup client program is also used to continuously read the change data from the driver cache and the disk data from the production volume according to the backup task, wherein the change data is captured by the filter driver and placed in the driver cache by the filter driver.

8. The real-time backup system without snapshot volume according to claim 7, characterized in that: The receiving and storing module further includes: A first receiving unit, used for the backup server program to continuously receive the changed data and disk data; A partition storage unit is used to partition and store the change data and disk data according to a time series, wherein a time index is set for each change data point, and the time index records the specific time when the data changes; the partition of the disk data is partitioned according to the creation or modification time of the data; The merging module further includes: A second receiving unit, configured to receive a first recovery time point from the backup server program; The first merging unit is used for the backup server program to merge all the changed data and disk data in the local end before the first recovery time point, and to notify the backup client program to stop sending the changed data; A record marking unit, used for backing up the server program to record the time when the merge is executed, and marking the second recovery time point; The designated time interval data synchronization unit is used for the backup server program to send the second recovery time point to the backup client program, and to notify the backup client program to send the change data between the first recovery time point and the second recovery time point; The secondary merging unit is used for the backup server program to receive the change data between the first recovery time point and the second recovery time point, and to update the initial synchronization data according to the change data.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the steps of the method for real-time backup of a volume without snapshot as claimed in any one of claims 1 to 5 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method for real-time backup of a volume without snapshot as claimed in any one of claims 1 to 5 is implemented.

Images