A real-time backup method, system, device and storage medium without snapshot volume

Abstract

The present invention relates to a real-time backup method, system, device and storage medium for snapshot-free volumes, and belongs to the field of disaster recovery backup technology. The method applied to the client is as follows: a filter driver captures IO operations and stores the changed data in a driver cache; the backup client program then reads the disk data and the changed data from the disk and the driver cache respectively, and then sends these data to the backup server program. The method applied to the server is as follows: the backup server program receives and stores the initially synchronized disk and changed data, and after reading the disk, the backup server program merges these data to create a complete recoverable backup set. The present invention can avoid performing a snapshot operation during the initial synchronization phase of the production volume, can ensure data consistency after the full synchronization is completed, and can also simultaneously reduce the backup host's consumption of memory, CPU and disk I / O resources.

Description

Technical Field

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

[0002] Currently, volume real-time backup technology is generally divided into two main stages:

[0003] Initial synchronization of the production volume: After the task is started, a snapshot is created for the production volume. The backup client then backs up the snapshot data to the server's mirror space over the network.

[0004] Real-time production volume change data monitoring phase: Once the snapshot is created, the backup client's driver module will monitor changes in the production volume and synchronize the real-time change data to the log space of the backup system.

[0005] Because the initial synchronization of production volumes requires creating snapshots, the presence of snapshots can impact the performance of the production host, potentially causing backup task failures or, in extreme cases, even serious incidents such as host freezes. Currently, there are few existing methods for real-time volume backup without snapshots that can simultaneously reduce the backup host's memory, CPU, and disk I / O resource consumption.

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

[0007] 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 volumes.

[0008] The technical solution of the present invention to solve the above technical problems is as follows:

[0009] In a first aspect, a method for real-time backup of a volume without snapshot is provided. The method is applied to a client and comprises the following steps:

[0010] The filter driver writes the captured change data into the driver cache;

[0011] Based on 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;

[0012] The backup client program continuously sends the changed data and disk data to the backup server program;

[0013] 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.

[0014] In a second aspect, a method for real-time backup of a volume without snapshots is provided. The method is applied to a server and includes the following steps:

[0015] The backup server program continuously receives and saves the changed data and disk data, which are sent by the backup client program;

[0016] The backup server program receives the first recovery time point, and then merges all the changed 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 the 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, where the changed data is captured by the filter driver and placed in the driver cache by the filter driver.

[0017] In a third aspect, a real-time backup system for volumes without snapshots is provided. The system is applied to a client and includes:

[0018] The capture module is used to filter the driver and write the captured change data into the driver cache;

[0019] The continuous reading module is used to enable the backup client program to continuously read the changed data from the drive cache and read the disk data from the production volume according to the backup task;

[0020] The continuous sending module is used by the backup client program to continuously send the changed data and disk data to the backup server program;

[0021] The sending recovery time point module is used to stop the backup client program from reading the change data and disk data when all the disk data is read, 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. 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.

[0022] A fourth aspect provides a real-time backup system for volumes without snapshots, the system being applied to a server and comprising:

[0023] The receiving and saving module is used by the backup server program to continuously receive and save the changed data and disk data sent by the backup client program;

[0024] The merging module is used for the backup server program to receive the first recovery time point, and then merge all the changed 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 the 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.

[0025] 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 snapshots as described in any one of the above items are implemented.

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

[0027] The beneficial effects of the present invention are:

[0028] The present invention does not perform snapshot operations during the initial synchronization phase 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

[0029] 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.

[0030] Figure 1 The present invention provides a flowchart of a method for real-time backup of volumes without snapshots in a client.

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

[0032] Figure 3 The present invention provides a flow chart of a method for real-time backup of snapshot-free volumes on a server side.

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

[0034] 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.

[0035] 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.

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

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

[0038] Figure 9 A schematic structural diagram of an electronic device provided by an embodiment of the present invention.

[0039] In the accompanying drawings, the components represented by the reference numerals are as follows:

[0040] 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

[0041] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention will be further described in detail below with reference to 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.

[0042] During the initial synchronization of production volumes, creating snapshots significantly impacts production host performance. While snapshots, as a data protection technology, provide instantaneous data backups, they also consume system resources. Snapshot technologies, such as mirror splitting and copy-on-write (COW), require additional storage space and processing power to create snapshots, which can degrade production host performance. Especially when data volumes are large or system resources are insufficient, the backup client may consume excessive system resources, causing out-of-memory (OOM) errors and resulting in backup failures. Furthermore, while snapshots can instantly complete data replication, minimizing the impact of backups on application and host performance, their performance impact remains significant in scenarios with frequent data changes. While existing technologies such as CDP (Continuous Data Protection) offer more granular data recovery capabilities, their application and adoption remain limited, and resource consumption is also a concern. Therefore, the impact of snapshots on the performance of production hosts, as well as the possible serious accidents such as backup task failure or host freeze, 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.

[0043] In view of the above problems, an embodiment of the present invention provides a real-time backup method for volumes without snapshots. Figure 1 A flowchart of a method for real-time backup of volumes without snapshots provided by an embodiment of the present invention is shown as follows: Figure 1 As shown, the method is applied to the client and includes the steps of:

[0044] In step S101 , the filter driver writes the captured change data into the driver cache.

[0045] As you can understand, a filter driver, as a low-level software component, operates at the volume layer—below the file system and above the operating system—to intercept I / O operations on storage volumes. Its primary functions include monitoring, tracking, and managing data changes on disks, as well as manipulating or controlling I / O requests when necessary, such as allowing or denying specific write operations. Filter drivers can capture real-time data changes.

[0046] It's also understandable that the driver cache is a cache within the filter driver that operates at the operating system's volume management level, which is lower than the file system level. As data is written to disk, the filter driver captures the changes in real time and stores them in the driver cache, allowing the backup client program to quickly access the data.

[0047] The driver cache type can be either a memory cache or a disk cache. A memory cache is a cache stored in memory, providing extremely fast data access speeds and suitable for fast backup and recovery operations. A disk cache is a cache stored on a disk and is suitable for storing larger data sets. Although the access speed is not as fast as memory, it can store more data. This is not specifically limited in the embodiments of the present invention.

[0048] 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 improving 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 status 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 in the event of a system crash or other failure, because the data has been stored in the driver cache before being sent, providing an additional layer of data protection.

[0049] 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.

[0050] It is understandable that the two operations continuously performed by the backup client program: reading changed data from the drive cache and reading disk data from the production volume, can be performed simultaneously or sequentially as needed. This embodiment does not impose any specific restrictions on this.

[0051] Step S103: The backup client program continuously sends the changed data and disk data to the backup server program.

[0052] 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.

[0053] It's worth noting that the above reading process is continuous because data changes continuously. 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.

[0054] It is also worth noting that the continuous monitoring and processing of data changes ensures that the backup process does not generate resource consumption peaks due to snapshot creation, thereby reducing the impact on the production environment. By capturing and driving cached 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 environments with frequent data changes, this continuous and progressive backup method is more efficient and can continuously protect data while minimizing the use of production resources.

[0055] In 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. 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.

[0056] 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 the state at this point in time can be restored when needed.

[0057] In order to understand the interaction process between the client and the server, Figure 2 As shown, the details are as follows:

[0058] The production application (production app) writes data to disk. The filter driver then detects the disk I / O operation and writes the detected changes to the backup client's driver cache. The backup system client (application layer) reads data from disk and sends the initial synchronized disk data to the backup server. The backup system client (application layer) reads the changed data from the driver cache and sends the initial synchronized changed data to the backup server.

[0059] The backup server receives and saves the disk data and changes during the initial synchronization process. Once the initial synchronization is complete, the backup server merges the disk data with the changes to form a complete, initial, recoverable data set. The backup source is the production environment data volume to be backed up, such as the C: drive in Windows.

[0060] 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. At the same time, 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 data consistency after the full synchronization is completed, but also reduces the consumption of memory, CPU and disk I / O resources of the backup host.

[0061] Based on the above embodiment, in the method, step S104 includes:

[0062] Step S1041: When all disk data is read, the backup client program refreshes the driver cache;

[0063] In step S1042, the backup client program checks whether all the changed data in the driver cache has been sent to the production volume disk. If so, the backup client program stops reading the changed data and disk data, marks the first recovery time point, and proceeds to the next step. If not, the driver cache is refreshed and the current check step is repeated.

[0064] Step S1043: The backup client program sends the first recovery time point to the backup server program.

[0065] 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.

[0066] 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:

[0067] Step S201: The backup server program continuously receives and saves the change data and disk data sent by the backup client program;

[0068] In step S202, the backup server program receives the first recovery time point, and then merges all the changed 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 changed 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 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.

[0069] To facilitate understanding of the merging process, Figure 4 As shown, we provide an operation example:

[0070] Figure 4 It contains four parts, each of which is a 4x4 matrix representing the data status on the disk.

[0071] (1) Disk initial status

[0072] 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;

[0073] (2) Data obtained by reading the original disk data

[0074] The matrix in the lower left corner shows the original disk data read during the initial synchronization. This data reflects the disk state at the beginning of the initial synchronization. The second to fourth positions in the first row are 1, 2, and 3 respectively. At the same time, the first position in the second row becomes 1, the first and second positions in the third row become 2, and the first to third positions in the fourth row become 3. The rest are 0.

[0075] (3) Monitored disk change data

[0076] The matrix in the lower right corner shows the disk changes monitored during the initial synchronization. These changes include: the second to fourth positions in the second row change from 0 to 1, the third and fourth positions in the third row change from 0 to 2, and the fourth position in the fourth row change from 0 to 3;

[0077] (4) Initial synchronization ends disk status

[0078] The matrix in the upper right corner shows the disk state at the end of the initial synchronization, that is, the disk state after the merge is completed. Compared to the starting state, the first four positions in the second row change from 0 to 1, the first four positions in the third row change from 0 to 2, and the first four positions in the fourth row change from 0 to 3.

[0079] To achieve an eventual consistent data state, the monitored disk change data must be merged with the original disk data. For each location, if the change data contains an update (i.e., a non-zero value), the value in the original disk data is replaced with the value in the change data. If the change data does not contain an update (i.e., the value is 0), the value in the original disk data is retained.

[0080] In this embodiment, directly reading the original disk data during disk synchronization may result in data inconsistencies because concurrent I / O operations may update the data on the disk. To address this issue, the change data captured during the initial synchronization is merged with the read disk data. This ensures that the backup dataset reflects a consistent point in time, thereby avoiding discrepancies between the backup data and the actual data state and ensuring the integrity and consistency of the backup data. This effectively reduces the production resource consumption caused by snapshot creation while improving the accuracy and reliability of data backup.

[0081] Based on the above embodiment, in this method, step S201 includes:

[0082] Step S2011, the backup server program continuously receives the changed data and disk data;

[0083] Step S2012, partitioning and storing 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 data change; the disk data is partitioned according to the creation or modification time of the data.

[0084] To improve backup system efficiency and query performance, this embodiment uses time-series partitioned storage. By setting a precise time index for each data change point, data can be quickly retrieved, reducing latency for large-scale data queries. Disk data is also partitioned by creation or modification time, optimizing storage and facilitating recovery and analysis.

[0085] In addition, based on 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 low-cost solutions. This can enhance the flexibility and scalability of the system and reduce operation and maintenance costs.

[0086] Based on the above embodiment, in the method, step S202 includes:

[0087] Step S2021: The backup server program receives a first recovery time point;

[0088] Step S2022: The backup server program merges all the changed data and disk data on the local side before the first restoration time point, and notifies the backup client program to stop sending the changed data.

[0089] Step S2023: The backup server program records the time when the merge is executed and marks the second recovery time point;

[0090] Step S2024: The backup server program sends the second restoration time point to the backup client program, and notifies the backup client program to send the change data between the first restoration time point and the second restoration time point.

[0091] In 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.

[0092] 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 point are merged, defining the end of the initial synchronization phase. Subsequently, the backup server program notifies the client to stop sending the changed 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 changed 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.

[0093] At the same time, the backup server can check the timestamps of data changes after the merge to ensure that no data changes occurred before the first recovery point in time. If any earlier data changes are found, this indicates a possible data synchronization issue and requires a new merge. This ensures data integrity and allows for quick identification and resolution of potential data consistency issues. In other words, by introducing a second recovery point in time, it is easier to verify the correctness of the merge.

[0094] like Figure 5 As shown, in one embodiment, a real-time backup system for volumes without snapshots is provided. The system is applied to a client and includes:

[0095] Capture module 3001, used for filtering the driver to write the captured change data into the driver cache;

[0096] The continuous reading module 3002 is used for the backup client program to continuously read the changed data from the drive cache and read the disk data from the production volume according to the backup task;

[0097] Continuous sending module 3003, used for the backup client program to continuously send the changed data and disk data to the backup server program;

[0098] The sending recovery time point module 3004 is used to stop the backup client program from reading the change data and disk data when all the disk data is read, 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. 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.

[0099] 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, ensuring real-time backup and continuous protection of data.

[0100] like Figure 6 As shown, in one embodiment, a real-time backup system for volumes without snapshots is provided. The system is applied to a server and includes:

[0101] 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;

[0102] 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 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.

[0103] like Figure 7 As shown, the receiving and saving module 4001 includes:

[0104] The first receiving unit 40011 is used for the backup server program to continuously receive the change data and disk data;

[0105] The partition storage unit 40012 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 moment when the data changes; the partitioning of the disk data is based on the creation or modification time of the data.

[0106] like Figure 8 As shown, the merging module 4002 includes:

[0107] The second receiving unit 40021 is used for the backup server program to receive the first recovery time point;

[0108] Initial merging unit 40022, used by the backup server program to merge all the changed data and disk data on the local side before the first recovery time point, and to notify the backup client program to stop sending the changed data;

[0109] Record marking unit 40023, used for backing up the server program to record the time when the merge is executed, marking the second recovery time point;

[0110] 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;

[0111] 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.

[0112] In this embodiment, the backup server program receives the change data sent by the client and merges it with the initial synchronization data, creating a complete backup set, eliminating the need to generate snapshots on the production side. By using strategies such as time-series partitioned storage, the server optimizes data storage and access, ensuring rapid recovery capabilities while effectively reducing operational costs.

[0113] exist Figure 9 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention, such as Figure 9 As shown, the electronic device may include: a processor 510, a communication interface 520, a memory 530, and a communication bus 540. 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 logic instructions in the memory 530 to execute the snapshot-free volume real-time backup method described in the above embodiment.

[0114] 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 sold or used as an independent product. Based on this understanding, the technical solution of the present invention, 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. The computer software product is stored in a storage medium and includes several instructions for enabling 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: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0115] 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 a volume without snapshot described in the above embodiment is implemented.

[0116] The computer storage medium of the embodiment of the present invention can adopt any combination of one or more computer-readable media. Computer-readable media can be computer-readable signal media or computer-readable storage media. Computer-readable storage media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or components, or any combination thereof. 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 thereof. In this document, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by an instruction execution system, device or device or used in combination with it.

[0117] A computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0118] Program code embodied on a 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.

[0119] 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 stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving 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).

[0120] The above-described embodiments merely illustrate several implementations of the present invention, and while their descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art would be able to make numerous variations and improvements without departing from the spirit of the present invention, all of which fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be determined by the appended claims.

Claims

1. A real-time backup method for volumes without snapshots, characterized in that: The method is applied to the client and includes the steps of: The filter driver writes the captured change data into the driver cache for temporary storage; According to the backup task, the backup client program continuously reads the changed data from the drive cache and continuously 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 change data and disk data. The backup server program is also used to merge all change data and disk data before the first recovery time point when the first recovery time point is obtained. The merging process is specifically as follows: integrating the received disk data with the change data before the first recovery time point; updating the corresponding position of the disk data according to the position identifier in the change data, and outputting it as the initial recoverable data set.

2. The method for real-time backup of volumes without snapshots according to claim 1, wherein: 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, further comprising: 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 has been sent to the production volume disk. If so, the backup client program stops reading the changed data and disk data, marks the first recovery time point, and then proceeds to the next step. If not, the driver cache is refreshed and the check step is repeated. The backup client program sends the first recovery time point to the backup server program.

3. A real-time backup method for volumes without snapshots, characterized in that: The method is applied to the server and includes the following steps: 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 changed data and disk data in the local terminal 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 further configured to continuously read changed data from the driver cache and continuously read disk data from the production volume according to the backup task, wherein the changed data is captured by the filter driver and temporarily stored in the driver cache by the filter driver; The merging process is specifically as follows: integrating the received disk data with the change data before the first recovery time point; updating the corresponding position of the disk data according to the position identifier in the change data, and outputting it as the initial recoverable data set.

4. The method for real-time backup of a volume without snapshot according to claim 3, wherein: 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 change data and disk data are partitioned and stored 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 data change; the disk data is partitioned according to the creation or modification time of the data.

5. The method for real-time backup of volumes without snapshots according to claim 3, wherein: The backup server program receives the first recovery time point, and then merges all the changed data and disk data in the local terminal before the first recovery time point to obtain the initial synchronization data step, further comprising: The backup server program receives the first recovery time point; The backup server program merges all the changed data and disk data before the first recovery time point on the local side, and notifies the backup client program to stop sending the changed data; The backup server program records the time when the merge is executed and marks 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: The capture module is used to filter the driver to write the captured change data into the driver cache for temporary storage; The continuous reading module is used 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 by the backup client program to continuously send the changed data and disk data to the backup server program; The sending recovery time point module is used to stop the backup client program from reading the change data and disk data when all the disk data is read, 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. 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. The merging process is specifically as follows: integrating the received disk data with the change data before the first recovery time point; updating the corresponding position of the disk data according to the position identifier in the change data, and outputting it as the initial recoverable data set.

7. A real-time backup system without snapshot volume, characterized in that: The system is applied to the server and includes: The receiving and saving module is used by the backup server program to continuously receive and save the changed data and disk data sent by the backup client program; A merging module is configured to receive a first recovery time point from a backup server program and then merge all change data and disk data on the local server before the first recovery time point to obtain initial synchronization data. The first recovery time point is sent by a backup client program. The backup client program is configured to stop reading change data and disk data when all disk data has been read, and mark the first recovery time point as obtained. The backup client program also continuously reads change data from a driver cache and continuously reads disk data from a production volume based on the backup task. The change data is captured by a filter driver and temporarily stored in a driver cache by the filter driver. The merging process specifically includes: integrating the received disk data and the change data before the first recovery time point; updating the corresponding position of the disk data according to the position identifier in the change data, and outputting it as the initial recoverable data set.

8. The real-time backup system without snapshot volumes according to claim 7, wherein: The receiving and storing module further includes: The first receiving unit is 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 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 initial merging unit is used for the backup server program to merge all the changed data and disk data on the local side 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 mark 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, wherein: When the processor executes the program, the steps of the method for real-time backup of a volume without snapshots according to 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 snapshots as claimed in any one of claims 1 to 5 is implemented.

Images