Reverse snapshot data storage method, device and equipment for disaster recovery system and computer storage medium

Abstract

The invention discloses a reverse snapshot data storage method, device and equipment for a disaster recovery system and a computer storage medium. The method comprises the following steps: generating a full copy of a protected volume according to a first snapshot creation instruction, wherein the full copy is a reference version of a snapshot sequence; according to a write-in request for the protected volume, acquiring data of a target data block of the write-in request before writing, storing the data as a historical incremental data block in a historical storage area, and writing new data of the write-in request into a corresponding position in the full copy, so that the full copy is a complete mapping of latest data; updating a metadata index, and establishing a mapping relationship between the historical incremental data block and the corresponding snapshot version; wherein after the write-in request is processed and the metadata index is updated each time, a new snapshot version is generated.

Description

Technical Field

[0001] This application relates to the field of data protection and disaster recovery technology, and in particular to a method, apparatus, device and computer storage medium for saving reverse snapshot data for a disaster recovery system. Background Technology

[0002] In the field of data protection and disaster recovery, in order to ensure business continuity, systems typically need to generate multiple point-in-time copies (snapshots) of production data. Traditional methods of organizing snapshot data are mainly divided into two categories: scheduled backups and continuous data protection (CDP), but their underlying structures are mostly based on a "forward snapshot chain".

[0003] In scheduled backup systems, a "first full copy + subsequent scheduled incremental copies" approach is typically used, with new full copies periodically synthesized to improve recovery efficiency. Scheduled backup systems rely on merging and restoring historical copies, and recovery speed is limited by copy synthesis efficiency, link performance, and data extraction capabilities. Real-time protection systems (such as CDP) employ a "first full copy + subsequent continuous incremental copies" data capture mechanism, optimizing storage and transmission efficiency through technologies such as Change Block Tracking (CBT) and compressed transmission. However, their core remains a forward snapshot chain structure of "increment first, synthesis later," meaning the head of the backup chain is the first full copy, with subsequent blocks recording differences at each point in time sequentially. During recovery, it is necessary to start from the full copy origin and merge subsequent incremental copies level by level to obtain a complete data image of the target time point.

[0004] The data protection methods described above have systemic defects in terms of replica structure organization, recovery link path, virtual disk compatibility, cross-platform mounting capability, and minute-level takeover performance. There is an urgent need for a brand-new replica organization structure to support the application of disaster recovery systems, backup platforms, and high-availability clusters in different business scenarios. Summary of the Invention

[0005] This application addresses the shortcomings of the prior art by providing a method for saving reverse snapshot data in a disaster recovery system, comprising: generating a full copy of a protected volume according to an initial snapshot creation instruction, wherein the full copy is a baseline version of the snapshot sequence; obtaining the data of the target data block of the write request before writing according to a write request to the protected volume, saving it as a historical incremental data block in the historical storage area, and writing the new data of the write request to the corresponding position in the full copy, so that the full copy is a complete mapping of the latest data; updating the metadata index to establish a mapping relationship between the historical incremental data block and the corresponding snapshot version; wherein, after each processing of the write request and updating the metadata index, a new snapshot version is generated.

[0006] Optionally, in this embodiment of the application, the reverse snapshot data saving method further includes: a preset snapshot version retention window and a preset capacity; determining whether the current snapshot version capacity has reached the preset capacity, and if it has reached the preset capacity, then discarding the earliest generated snapshot version.

[0007] Optionally, in this embodiment of the application, the process of eliminating the earliest generated historical snapshot version includes: removing the association between the snapshot version in the metadata index and the historical incremental data block; and releasing the physical storage space of the historical incremental data block through the reference count table.

[0008] Optionally, in this embodiment of the application, the metadata index includes: a block mapping table, which records the latest mapping relationship between logical block addresses and physical storage locations; and a history mapping table, which records the correspondence between old data blocks in the history storage area and their respective snapshot versions.

[0009] Optionally, in this embodiment of the application, the reverse snapshot data saving method further includes: accessing a historical snapshot version, wherein accessing a historical snapshot version includes: receiving a data read request for a logical block address in a target historical version; querying the metadata index, wherein if the metadata index indicates that the data at the logical block address has not been modified after the target historical version, then the data is read from the current full copy; if the metadata index indicates that the data at the logical block address has been modified after the target historical version, then the corresponding data block is read from the historical storage area.

[0010] Optionally, in this embodiment of the application, the reverse snapshot data saving method further includes: calculating fingerprint information for the data block to be saved; comparing it with a global fingerprint database before writing it to physical storage; if the fingerprint information already exists in the global fingerprint database, then no duplicate data blocks are stored, and only the metadata index is updated to point to the existing physical data block.

[0011] Optionally, in this embodiment of the application, the reverse snapshot data saving method further includes: recording metadata and data update operations through the log recording area; aggregating multiple write requests into batch operations for submission; and establishing a secondary index structure for the block mapping table and the reference count table.

[0012] On another aspect of this application, a reverse snapshot data storage device for a disaster recovery system is also provided, comprising: The initial full copy generation unit is used to generate a full copy of the protected volume according to the first snapshot creation instruction, wherein the full copy is a base version of the snapshot sequence; The target full copy generation unit is used to obtain the data of the target data block of the write request before writing according to the write request to the protected volume, save it as a historical incremental data block to the historical storage area, and write the new data of the write request to the corresponding position in the full copy, so that the full copy is a complete mapping of the latest data. The metadata index update unit is used to update the metadata index and establish a mapping relationship between the historical incremental data block and the corresponding snapshot version; Each time a write request is processed and the metadata index is updated, a new snapshot version is generated.

[0013] In another aspect of the embodiments of this application, a reverse snapshot data storage device for a disaster recovery system is also provided, comprising: Memory, used to store computer programs; A processor for invoking and executing the computer program to implement the steps of the reverse snapshot data saving method for a disaster recovery system as described in any of the preceding claims.

[0014] In another aspect of the embodiments of this application, a storage medium is also provided, including a software program adapted by a processor to perform the steps of the reverse snapshot data saving method for a disaster recovery system as described in any of the preceding claims.

[0015] The reverse snapshot data storage device for the disaster recovery system includes a computer program stored on a storage medium. The computer program includes program instructions that, when executed by a computer, cause the computer to perform the methods described in the above aspects and achieve the same technical effect.

[0016] The embodiments described in this application have the following beneficial effects: This application provides a method for saving reverse snapshot data in disaster recovery systems. After each write operation, the full copy always maintains a complete mapping of the latest data, and the full copy is immediately available without any data merging or reorganization process. Furthermore, by creating independent historical incremental data blocks for each write and updating the metadata index, the integrity of each snapshot version no longer depends on a series of consecutive incremental files, avoiding the problem of the entire recovery chain failing due to the corruption of a single incremental file in the traditional forward snapshot chain. The historical incremental data block only saves the old data before the write and is associated with a specific version through metadata. When an old version is eliminated according to a policy, the system can accurately locate and release redundant data blocks that belong only to that version. By establishing and managing the mapping relationship between historical incremental data blocks and snapshot versions through the metadata index, data from any historical version can be quickly located and read.

[0017] Furthermore, the reverse snapshot data saving method for disaster recovery systems in this application generates a full copy that can be used directly. This full copy can be pre-packaged or converted in real-time to a standard virtual disk format (such as VMDK, VHD). This allows the generated snapshot copy to be natively recognized and mounted by the virtualization platform without format conversion, realizing cross-platform and cross-environment disaster recovery takeover and migration. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. The accompanying drawings in the following description are merely exemplary embodiments of this application.

[0019] Figure 1 A schematic diagram illustrating the reverse snapshot data saving method for disaster recovery systems provided in this application is shown. Figure 2 This paper illustrates a flowchart of the reverse snapshot data saving method provided in this application during a write request. Figure 3 This application illustrates a process diagram for the elimination of snapshot versions. Figure 4 A flowchart illustrating the process of accessing the history snapshot version provided in this application is shown; Figure 5 This application provides a schematic diagram of the structure of a reverse snapshot data storage device for a disaster recovery system. Figure 6 This paper presents a schematic diagram of the device for saving reverse snapshot data in a disaster recovery system, as provided in this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Example 1

[0021] The following is combined Figures 1 to 4 The reverse snapshot data saving method 100 for disaster recovery systems described in this application is explained in detail. Figure 1 This diagram illustrates the reverse snapshot data saving method for disaster recovery systems provided in this application. Figure 2 This diagram illustrates the flowchart of the reverse snapshot data saving method provided in this application during a write request. Figure 3 This diagram illustrates the process of phasing out the snapshot version provided in this application. Figure 4This diagram illustrates the process for accessing the history snapshot version provided in this application. First, refer to... Figure 1 The reverse snapshot data saving method 100 for disaster recovery system includes steps S101 to S103.

[0022] In step S101, a full copy of the protected volume is generated according to the first snapshot creation instruction, wherein the full copy is a base version of the snapshot sequence.

[0023] In this embodiment, upon receiving the initial snapshot creation instruction, a series of operations are triggered to generate a full copy of the protected volume. Specifically, the system completely reads all disk block data in the protected volume and copies it to a dedicated storage area, forming a full copy. This full copy contains all data of the protected volume at the time of snapshot creation and is saved in a directly mountable format, ensuring complete recovery capabilities. This full copy serves as the baseline for all subsequent snapshot versions, providing the foundation for subsequent incremental and recovery operations.

[0024] In step S102, based on the write request to the protected volume, the data of the target data block of the write request before writing is obtained, and saved as a historical incremental data block to the historical storage area. The new data of the write request is written to the corresponding position in the full copy, so that the full copy is a complete mapping of the latest data.

[0025] Figure 2 This diagram illustrates the flowchart of the reverse snapshot data saving method provided in this application during a write request. (Refer to...) Figure 2 When the system detects a write request to the protected volume, it identifies old data blocks that are about to be overwritten by new data. Before the new data is written, the state of these old data blocks is captured and saved as historical incremental data blocks to the historical storage area, thus supporting potential data recovery needs. Then, the new data is written to the corresponding location on the full copy, updating the full copy to reflect the latest state of the data. This not only ensures that the full copy is always a complete mapping of the latest data, but also improves the efficiency of data recovery by directly updating the full copy.

[0026] In step S103, the metadata index is updated to establish a mapping relationship between the historical incremental data blocks and the corresponding snapshot versions. Specifically, a new snapshot version is generated after each write request is processed and the metadata index is updated.

[0027] Continue to refer to Figure 2Updating the metadata index is a crucial step, ensuring an accurate mapping between historical incremental data blocks and their corresponding snapshot versions. Whenever the system processes a write request and successfully updates the full copy, it updates the metadata index and generates a new snapshot version. Specifically, updating the metadata index may include, for example, the block mapping table (BM), the version description table (VD), and the reference count table (RCT). The block mapping table updates the mapping information, recording the new location of the data block in the historical storage area; the version description table is updated to reflect the newly generated snapshot version, including the version number and timestamp; and the reference count table is updated to reflect the reference status of the data block in both old and new snapshot versions. All these update operations are logged in the operation log to ensure a consistent state can be restored in the event of a system failure.

[0028] After the metadata index is updated, a new snapshot version is generated, containing a complete record of all data changes since the previous snapshot version. The new snapshot version is added to the snapshot chain, maintaining the order and integrity of the snapshot versions while ensuring traceability during data recovery.

[0029] For example, the metadata index may include: a block mapping table, which records the latest mapping relationship between logical block addresses and physical storage locations; and a history mapping table, which records the correspondence between old data blocks in the history storage area and their respective snapshot versions.

[0030] The Block Mapping Table (BM) is a core component of the metadata index, used to record the latest mapping between Logical Block Addresses (LBAs) and their physical storage locations. For each data block in the full replica, the Block Mapping Table provides a pointer to its exact location in physical storage.

[0031] The History Map (HM) records the correspondence between old data blocks in the history storage area and their respective snapshot versions. When a data block changes, the old data block is saved to the history storage area, and its location and the corresponding snapshot version are recorded in the History Map. This way, even if a data block is updated or overwritten in subsequent write operations, the system can still track the storage location of the old data block through the History Map, thus supporting access to and recovery of historical data.

[0032] Furthermore, the reverse snapshot data saving method may also include: a preset snapshot version retention window and a preset capacity; when determining whether the current snapshot version capacity has reached the preset capacity, if the preset capacity has been reached, the earliest generated snapshot version is discarded.

[0033] Figure 2 This diagram illustrates the flowchart of the reverse snapshot data saving method provided in this application during a write request. Figure 3 This diagram illustrates the process for phasing out snapshot versions provided in this application. (Refer to...) Figure 2 and Figure 3 Dynamic management of snapshot versions is achieved by presetting two key parameters: the snapshot version retention window and the preset capacity. Specifically, the snapshot version retention window refers to the maximum number of snapshot versions that the system allows to retain. This window can be flexibly configured according to business needs and the availability of storage resources. The preset capacity is the upper limit of storage space allocated for snapshot data, used to ensure that the system does not exhaust storage resources due to the unlimited growth of snapshot data.

[0034] During snapshot version management, the system continuously monitors the total capacity of the current snapshot version. When the total capacity of the current snapshot version reaches or exceeds the preset capacity, the snapshot version replacement mechanism will be automatically triggered. In the reverse snapshot structure, the earliest snapshot version usually contains a large amount of data that overlaps with subsequent snapshot versions, so replacing them has the least impact on data integrity.

[0035] Furthermore, the process of eliminating the earliest generated historical snapshot version includes: removing the association between the snapshot version in the metadata index and the historical incremental data block; and releasing the physical storage space of the historical incremental data block through the reference count table.

[0036] Continue to refer to Figure 3 The process of phasing out the earliest generated historical snapshot version can include unassociating the snapshot version with historical incremental data blocks in the metadata index, and using the Reference Count Table (RCT) to identify and release physical storage space occupied by historical incremental data blocks that are no longer referenced by any snapshot version. When the reference count of a data block drops to zero, indicating that no other snapshot version needs the data block, the system will release the storage space it occupies, while ensuring that data consistency and integrity are maintained throughout the entire operation. In addition, the system may update the operation log to record changes and notify management of the snapshot version being phased out and the storage space being released, thereby achieving dynamic optimization of storage resources and providing storage space for the creation of new snapshot versions.

[0037] Furthermore, the reverse snapshot data saving method may further include: accessing a historical snapshot version, which may include: receiving a data read request for a logical block address in a target historical version; querying the metadata index, wherein if the metadata index indicates that the data at the logical block address has not been modified since the target historical version, then the data is read from the current full copy; if the metadata index indicates that the data at the logical block address has been modified since the target historical version, then the corresponding data block is read from the historical storage area.

[0038] Figure 4This diagram illustrates the process for accessing the history snapshot version provided in this application. (Refer to...) Figure 4 When accessing a historical snapshot version, a data read request for a logical block address in a specified historical version can be received first. Then, the metadata index is queried to determine whether the data at that logical block address has been modified since the target historical version. If the metadata index indicates that the data has not been modified, the data can be read directly from the current full replica. If the data has been modified, the corresponding historical incremental data blocks can be checked layer by layer in the historical storage area until the block containing the required data is found and read. This ensures that data in the historical snapshot version can be accessed, guaranteeing data consistency and integrity whether directly from the full replica or through historical incremental data blocks.

[0039] Furthermore, the reverse snapshot data saving method may further include: calculating fingerprint information for the data block to be saved; Before writing to physical storage, the fingerprint is compared with the global fingerprint database. If the fingerprint information already exists in the global fingerprint database, duplicate data blocks are not stored, and only the metadata index is updated to point to the existing physical data block.

[0040] In this embodiment, before writing a data block to physical storage, fingerprint information can be calculated for the data block. The calculated fingerprint information is then compared with a global fingerprint database. If no identical fingerprint information exists in the global fingerprint database, it indicates that the data block is new. The new data block is then written to physical storage, and the metadata index is updated to reflect the new physical storage location. If identical fingerprint information already exists in the global fingerprint database, it indicates that the data block to be saved is duplicated, and the duplicate data block is no longer stored. For detected duplicate data blocks, only the metadata index, such as the Block Mapping Table (BM) and Reference Count Table (RCT), is updated to point to the existing physical data block. This allows new snapshot versions to reference the old physical data block through the metadata index without needing to store the same data again. It is understood that fingerprint information is typically generated using a hash function and can uniquely identify the content of a data block; the global fingerprint database is a database that stores the fingerprints of all saved data blocks for quickly finding and identifying duplicate data.

[0041] Furthermore, the reverse snapshot data saving method may also include: recording metadata and data update operations through the log recording area; aggregating multiple write requests into batch operations for submission; and establishing a secondary index structure for the block mapping table and the reference count table.

[0042] In this embodiment, all update operations on metadata and data can be recorded in the journal. Log recording ensures that in the event of a failure or interruption, a consistent state can be restored by replaying the logs. The journal allows the system to roll back to a previous state when problems occur, thereby preventing data corruption or loss.

[0043] To improve write efficiency, multiple write requests can be aggregated into a batch operation for submission. This batch submission strategy reduces the number of disk I / O operations, thereby reducing write latency and improving performance.

[0044] To improve access speed to block maps (BM) and reference count tables (RCT), secondary index structures can be created for these tables. Secondary indexes, such as B+ trees, hash tables, or other data structures, can improve the speed of finding specific data in large datasets. Secondary index structures allow for quick location of specific data blocks or metadata, thereby improving the access and recovery speed of historical versions of data.

[0045] The following section describes the access speed and recovery speed of the reverse snapshot data saving method for disaster recovery systems in this application, using specific application scenarios as examples.

[0046] For example, in typical disaster recovery applications, when a production site experiences service interruption due to hardware failure, network outage, or natural disasters, the standby site needs to take over in the shortest possible time to ensure business continuity. In existing forward snapshot chain-based solutions, the takeover process typically relies on merging multiple incremental snapshots: the latest copy is not the full copy, but rather a combination of the initial full copy and several incremental copies. This mechanism results in a lengthy and time-consuming recovery chain; if any intermediate incremental copy in the chain fails, the takeover process may completely fail. However, the reverse snapshot data saving method provided in this application maintains the latest snapshot as a complete full copy and stores it directly in a virtualized general-purpose disk format (such as QCOW2). Therefore, during disaster recovery failover, the standby site can immediately mount this latest copy without performing any merging or format conversion operations, and can directly use it as a virtual machine disk to start or take over production services.

[0047] Experimental results show that in typical database business scenarios, the recovery time objective (RTO) can be shortened to minutes using the reverse snapshot data saving method provided in this application. Compared with the recovery process that takes several hours using the traditional forward snapshot chain, the efficiency is significantly improved. At the same time, because the takeover process does not rely on intermediate incremental files, the overall reliability and success rate are greatly improved.

[0048] For example, in scenarios such as testing, development, and data verification, business systems often need to frequently roll back to different historical versions to verify functionality or restore data states at specific points in time. In the traditional forward snapshot chain structure, rollback operations often rely on multi-level incremental merging or restoration, which is not only time-consuming but also introduces additional I / O overhead with each operation, making it difficult to support high-frequency, multi-version flexible switching. The reverse snapshot data storage method provided in this application stores data in an organization of the latest full data plus backward incremental data. When accessing historical versions, the difference data blocks can be quickly located through index overlay without triggering the merging process, and the target version view can be generated instantly. At the same time, the platform supports exporting any historical snapshot as a read-only virtual disk (QCOW2 format) for direct mounting and verification.

[0049] Real-world testing results show that when performing multiple cross-version rollback operations on the same business volume, this application can stabilize the single rollback latency at the second level, far exceeding the minute-level or even higher latency of traditional solutions. Simultaneously, the system supports concurrent multi-version mounting, allowing multiple test environments to run simultaneously at different historical points in time, greatly improving development and testing efficiency.

[0050] In summary, this application provides a reverse snapshot data storage method 100 for disaster recovery systems. After each write operation, the full copy always maintains a complete mapping of the latest data, making the full copy immediately available without any data merging or reorganization process. Furthermore, by creating independent historical incremental data blocks for each write and updating the metadata index, the integrity of each snapshot version no longer depends on a series of consecutive incremental files, avoiding the failure of the entire recovery chain caused by the corruption of a single incremental file in the traditional forward snapshot chain. The historical incremental data block only stores the old data before the write and is associated with a specific version through metadata. When an old version is phased out according to a policy, the system can accurately locate and release redundant data blocks that belong only to that version. By establishing and managing the mapping relationship between historical incremental data blocks and snapshot versions through the metadata index, data from any historical version can be quickly located and read.

[0051] Furthermore, the reverse snapshot data saving method 100 for disaster recovery systems in this application generates a full copy that can be used directly. This full copy can be pre-packaged or converted in real-time to a standard virtual disk format (such as VMDK, VHD). This allows the generated snapshot copy to be natively recognized and mounted by the virtualization platform without format conversion, realizing cross-platform and cross-environment disaster recovery takeover and migration. Example 2

[0052] Corresponding to the method embodiments, another aspect of the embodiments of this application also provides a reverse snapshot data storage device for a disaster recovery system. Figure 5This illustration shows a structural schematic diagram of a reverse snapshot data storage device for a disaster recovery system provided in this application. The reverse snapshot data storage device for a disaster recovery system is... Figure 1 The apparatus corresponding to the reverse snapshot data saving method for a disaster recovery system described in the corresponding embodiment is implemented through a virtual system. Figure 1 The corresponding embodiment provides a method for saving reverse snapshot data for a disaster recovery system. The virtual modules constituting the reverse snapshot data saving device for the disaster recovery system can be executed by electronic devices, such as network devices, terminal devices, or servers. Specifically, an embodiment of this application provides a reverse snapshot data saving device for a disaster recovery system, comprising: The initial full copy generation unit 01 is used to generate a full copy of the protected volume according to the first snapshot creation instruction, wherein the full copy is a base version of the snapshot sequence; The target full copy generation unit 02 is used to obtain the data of the target data block of the write request before writing according to the write request to the protected volume, save it as a historical incremental data block to the historical storage area, and write the new data of the write request to the corresponding position in the full copy, so that the full copy is a complete mapping of the latest data. Metadata index update unit 03 is used to update the metadata index and establish a mapping relationship between the historical incremental data block and the corresponding snapshot version; Each time a write request is processed and the metadata index is updated, a new snapshot version is generated.

[0053] It should be noted that the specific implementation and technical effects of the reverse snapshot data storage device for disaster recovery systems in this application embodiment can be found by referring to... Figure 1 The corresponding method for saving reverse snapshot data for disaster recovery systems will not be elaborated here. Example 3

[0054] Corresponding to the method embodiments, this application also provides a reverse snapshot data storage device for a disaster recovery system, such as a terminal or server. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The terminal can be a smartphone, tablet, laptop, desktop computer, etc., but is not limited to these.

[0055] An example diagram of the hardware structure block diagram of the reverse snapshot data storage device for disaster recovery system provided in this application embodiment is shown below. Figure 6As shown, it may include: Processor 1, communication interface 2, memory 3, and communication bus 4; The processor 1, communication interface 2, and memory 3 communicate with each other via communication bus 4. Optionally, communication interface 2 can be an interface of a communication module, such as the interface of a GSM module; Processor 1 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0056] Memory 3 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0057] Specifically, processor 1 is used to execute the computer program stored in memory 3 to perform the following steps: Step S101: Generate a full copy of the protected volume according to the first snapshot creation instruction, wherein the full copy is a base version of the snapshot sequence; Step S102: Based on the write request to the protected volume, obtain the data of the target data block of the write request before writing, save it as a historical incremental data block to the historical storage area, and write the new data of the write request to the corresponding position in the full copy, so that the full copy is a complete mapping of the latest data. Step S103: Update the metadata index and establish a mapping relationship between the historical incremental data blocks and the corresponding snapshot versions. Specifically, a new snapshot version is generated after each write request is processed and the metadata index is updated.

[0058] The above-mentioned products can execute the methods provided in the embodiments of this application, and have the corresponding functional modules and beneficial effects for executing the methods. Technical details that are not described in detail in this embodiment can be found in the reverse snapshot data saving method for disaster recovery systems provided in the embodiments of this application. Example 4

[0059] In this embodiment of the application, a storage medium is also provided, which can store a program suitable for execution by a processor, the program being used for: Step S101: Generate a full copy of the protected volume according to the first snapshot creation instruction, wherein the full copy is a base version of the snapshot sequence; Step S102: Based on the write request to the protected volume, obtain the data of the target data block of the write request before writing, save it as a historical incremental data block to the historical storage area, and write the new data of the write request to the corresponding position in the full copy, so that the full copy is a complete mapping of the latest data. Step S103: Update the metadata index and establish a mapping relationship between the historical incremental data blocks and the corresponding snapshot versions. Specifically, a new snapshot version is generated after each write request is processed and the metadata index is updated.

[0060] The above-mentioned products can execute the methods provided in the embodiments of this application, and have the corresponding functional modules and beneficial effects for executing the methods. Technical details that are not described in detail in this embodiment can be found in the reverse snapshot data saving method for disaster recovery systems provided in the embodiments of this application.

[0061] Optionally, the refined and extended functions of the program can be found in the description above.

[0062] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0063] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0064] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of those different embodiments or examples.

[0065] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0066] The above description is merely an exemplary embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various variations or substitutions within the technical scope described in this application, and these should all be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A reverse snapshot data saving method for a disaster recovery system, characterized by, Comprising: generating a full copy of the protected volume according to the first snapshot creation instruction, the full copy being a baseline version of the snapshot sequence; according to a write request to the protected volume, obtaining the data of the target data block of the write request before writing as a historical incremental data block saved to a historical storage area, and writing the new data of the write request to the corresponding position in the full copy, so that the full copy is a complete mapping of the latest data; updating the metadata index to establish the mapping relationship between the historical incremental data block and the corresponding snapshot version; wherein, after processing the write request and updating the metadata index each time, a new snapshot version is generated.

2. The reverse snapshot data save method of claim 1, wherein, The reverse snapshot data saving method further comprises: a preset snapshot version retention window and a preset capacity; determining whether the current snapshot version capacity reaches the preset capacity, if the preset capacity is reached, the earliest generated snapshot version is eliminated.

3. The reverse snapshot data save method of claim 2, wherein, The elimination of the earliest generated historical snapshot version comprises: dissociating the snapshot version in the metadata index from the historical incremental data block; releasing the physical storage space of the historical incremental data block through the reference count table.

4. The reverse snapshot data save method of claim 3, wherein, The metadata index comprises: a block mapping table for recording the latest mapping relationship between logical block addresses and physical storage locations; a historical mapping table for recording the correspondence between old data blocks in the historical storage area and their snapshot versions.

5. The reverse snapshot data save method of claim 4, wherein, The reverse snapshot data saving method further comprises: accessing historical snapshot versions, the accessing historical snapshot versions comprising: receiving a data read request for a logical block address in a target historical version; querying the metadata index, wherein, if the metadata index indicates that the data of the logical block address has not been modified after the target historical version, reading the data from the current full copy; if the metadata index indicates that the data of the logical block address has been modified after the target historical version, reading the corresponding data block from the historical storage area.

6. The reverse snapshot data save method of claim 5, wherein, The reverse snapshot data saving method further comprises: calculating fingerprint information for the data block to be saved; comparing the global fingerprint library before writing to the physical storage; if the fingerprint information already exists in the global fingerprint library, the duplicate data block is no longer stored, and only the metadata index is updated to point to the existing physical data block.

7. The reverse snapshot data save method of claim 6, wherein, The reverse snapshot data saving method further comprises: recording the update operation of metadata and data through a log recording area; aggregating multiple write requests into batch operations for submission; establishing a two-level index structure for the block mapping table and the reference count table.

8. A reverse snapshot data saving apparatus for a disaster recovery system, characterized by comprising: Comprising: an initial full copy generation unit for generating a full copy of the protected volume according to the first snapshot creation instruction, the full copy being a baseline version of the snapshot sequence; a target full copy generation unit for obtaining the data of the target data block of the write request before writing as a historical incremental data block saved to a historical storage area, and writing the new data of the write request to the corresponding position in the full copy, so that the full copy is a complete mapping of the latest data according to a write request to the protected volume; A metadata index updating unit is configured to update a metadata index and establish a mapping relationship between the historical incremental data block and a corresponding snapshot version. After processing the write request and updating the metadata index each time, a new snapshot version is generated.

9. A reverse snapshot data saving device for a disaster recovery system, characterized by, The method comprises the following steps: a memory configured to store a computer program; a processor configured to invoke and execute the computer program to implement the steps of the reverse snapshot data saving method for a disaster recovery system according to any one of claims 1 to 7.

10. A storage medium, characterized by a software program adapted to be executed by a processor to implement the steps of the reverse snapshot data saving method for a disaster recovery system according to any one of claims 1 to 7.

Images