Remote data replication method, storage device and storage system

Abstract

A remote data replication method, storage device and storage system. In which, a first controller detects whether there is a replication task locally; when there is no replication task in the first controller, the first controller sends a request message to the second controller. The request message is used to apply for a replication task to the second controller, and the second controller includes at least two replication tasks. According to the request message, the second controller reads the data corresponding to the first replication task and sends it to the first controller. The first controller receives the data corresponding to the first replication task, sends the data corresponding to the first replication task to the disaster recovery array, and the second controller sends the data corresponding to the second replication task to the disaster recovery array. Thereby, the purpose of parallel replication of data in a multi-controller system is achieved.

Description

Technical Field

[0001] Embodiments of the present invention relate to the field of storage technology, and in particular to a remote data replication method, a storage device, and a storage system. Background Art

[0002] Data disaster recovery, also known as remote data replication technology, refers to the establishment of a remote data system that is a usable copy of local data. When a disaster occurs to the local data and the entire application system, the system will at least have a usable copy of the key business data stored in a remote location.

[0003] A typical data disaster recovery system includes a production center and a disaster recovery center. In the production center, hosts and storage arrays are deployed for normal business operations; in the disaster recovery center, hosts and storage arrays are deployed to take over the business of the production center after a disaster occurs. In a massive storage system, the storage arrays of the production center and the storage arrays of the disaster recovery center are usually storage arrays containing multiple controllers. Different controllers can write and modify the same file separately. In order to ensure that the files copied to the disaster recovery center are consistent with the files in the production center, the write operations of each controller on the file need to be serially copied to the disaster recovery center, which affects the replication efficiency. Summary of the invention

[0004] This embodiment provides a remote data replication method and a storage system, which can concurrently execute replication tasks in a multi-control system.

[0005] In the first aspect, a remote data replication method is provided. The method is applied to a storage system, wherein the storage system includes a production array and a disaster recovery array, and the production array includes at least a first controller and a second controller. The first controller detects whether there is a replication task locally, and when there is no replication task, sends a request message to the second controller. The request message is used to apply for a replication task to the second controller, and the second controller includes at least two replication tasks. The second controller reads the data corresponding to the first replication task and sends it to the first controller based on the request message. The first controller receives the data corresponding to the first replication task, sends the data corresponding to the first replication task to the disaster recovery array, and the second controller also sends the data corresponding to the second replication task to the disaster recovery array.

[0006] In this embodiment, the first controller has no replication task and is in an idle state, while the second controller includes at least two replication tasks and is in a busy state. Therefore, the first controller can send a request message to the second controller to apply for a replication task. The second controller assigns one of its at least two replication tasks to the first controller according to the request message, so that the first controller and the second controller can each execute a replication task, thereby achieving the purpose of parallel processing and improving replication efficiency.

[0007] In a first implementation of the first aspect, the second controller maintains a replication queue, and the replication queue includes the at least two replication tasks. Therefore, the second controller specifically obtains the first replication task from the replication queue, and sends the data corresponding to the first replication task to the first controller. In addition, the second controller also obtains the second replication task from the replication queue, and sends the data corresponding to the second replication task to the disaster recovery array.

[0008] In combination with the first aspect and the first implementation of the first aspect, in a second implementation, the first copy task and the second copy task are copy tasks for the same file, thereby achieving parallel copying of the same file.

[0009] In combination with the second implementation of the first aspect, in a third implementation, the file has a unique file name, the data corresponding to the first copy task includes the file name, the initial data of the file, and the writing time of the initial data, and the data corresponding to the second copy task includes the file name, the modified data of the file, and the writing time of the modified data, and the writing time of the modified data is later than the writing time of the initial data.

[0010] In combination with the third implementation manner of the first aspect, in a fourth implementation manner, the disaster recovery array receives the data corresponding to the first replication task, creates a backup file of the file, writes the initial data into the backup file, and the file name of the backup file is the same as the file name of the file. After receiving the data corresponding to the first replication task, the disaster recovery array receives the data corresponding to the second replication task. When the disaster recovery array determines that the file name corresponding to the second replication task is the same as the file name of the backup file, it determines whether the write time of the modified data is later than the write time of the initial data. When the disaster recovery array determines that the write time of the modified data is later than the write time of the initial data, the modified data is written into the backup file. In this implementation manner, if the disaster recovery array receives the initial data first and then receives the modified data, the modified data can be written into the backup file. Even if the modified data overwrites the initial data, it will not cause data inconsistency between the disaster recovery array and the production array.

[0011] In combination with the third implementation manner of the first aspect, in a fifth implementation manner, the disaster recovery array receives the data corresponding to the second replication task, creates a backup file of the file, writes the modified data into the backup file, and the file name of the backup file is the same as the file name of the file. After receiving the data corresponding to the second replication task, the disaster recovery array receives the data corresponding to the first replication task. When the disaster recovery array determines that the file name corresponding to the first replication task is the same as the file name of the backup file, it determines whether the writing time of the initial data is later than the writing time of the modified data. When the disaster recovery array determines that the writing time of the initial data is earlier than the writing time of the modified data, the operation of writing the initial data into the backup file is not performed. In this implementation manner, if the disaster recovery array receives the modified data first and then receives the initial data, the operation of writing the initial data into the backup file is not performed to prevent the data of the disaster recovery array and the production array from being inconsistent.

[0012] A second aspect of the present invention provides a storage device to execute the method provided in the first aspect.

[0013] A third aspect of the present invention provides a storage device to execute the method provided in the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for use in the embodiments are briefly introduced below.

[0015] Figure 1 is a schematic diagram of a system architecture provided by an embodiment of the present invention;

[0016] Figure 2 is a structural diagram of a controller provided by an embodiment of the present invention;

[0017] Figure 3 It is a flowchart of a remote data replication method provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0018] This embodiment provides a remote data replication method, a storage device, and a storage system, which can concurrently execute replication tasks in a multi-control system.

[0019] Figure 1 A schematic diagram of the system architecture of the remote data replication method provided by an embodiment of the present invention is shown in FIG. Figure 1As shown, the production center includes a production host, connection equipment and a production array 20; the system architecture of the disaster recovery center is similar to that of the production center, including a disaster recovery host, connection equipment and a disaster recovery array 30. In an embodiment of the present invention, there may be more than one disaster recovery center. The production center and the disaster recovery center may transmit data via IP (Internet Protocol) or FC (Fiber Chanel) or other protocols.

[0020] Both the production host and the disaster recovery host can be any computing device, such as a server, a desktop computer, etc. Inside the host, an operating system and other applications are installed.

[0021] The connection device may be any interface between the storage device and the host, such as a fiber optic switch, or other switches known in the current technology.

[0022] Both the production array 20 and the disaster recovery array 30 can be storage devices, such as redundant arrays of independent hard disks (RAID), just a bunch of disks (JBOD), one or more interconnected hard disk drives of direct access storage device (DASD), such as a tape library, a tape storage device of one or more storage units.

[0023] The production array 20 and the disaster recovery array 30 in this embodiment are both storage devices with a file system, that is, the data stored in the storage medium is managed and accessed in units of files. The file system is a method of storing and organizing data, which makes it easy to access and find data. The file system uses the abstract logical concepts of files and tree directories instead of the concept of data blocks used by physical devices such as hard disks. After the production array 20 uses the file system to save data, the user does not need to care about the data block at which the data is actually saved on the hard disk. He only needs to remember the directory and file name of the file. Similarly, before writing new data, the user does not need to care about which block address on the hard disk is not used. The storage space management (allocation and release) function on the hard disk is automatically completed by the file system. The user only needs to remember which file the data is written to.

[0024] The hardware structures of the production array 20 and the disaster recovery array 30 are the same. Figure 2 is a schematic diagram of the structure of a production array 20 according to an embodiment of the present invention, Figure 3 Schematic diagram of the structure of the disaster recovery array 30 according to an embodiment of the present invention.

[0025] like Figure 2As shown, the production array 20 at least includes a controller 21, a controller 22 and several hard disks 31. The controller 21 may include any computing device, such as a server, a desktop computer, etc. A file system and other applications are installed inside the controller. The controller 21 is used to perform various operations related to files, such as creating files, creating directories, reading file operations, writing file operations, sending data copy requests, etc. The controller 22 and the controller 21 have similar structures and the same functions. The several hard disks 31 included in the production array 20 are used to provide storage space for saving files. It should be noted that the controller 21 and the controller 22 are only examples of the embodiments of the present invention. Other controllers may also be included in the embodiments of the present invention, and this embodiment does not limit the number of controllers.

[0026] The controller 21 mainly includes a processor 118, a cache 120, a memory 122, a communication bus (referred to as bus) 126, and a communication interface 128. The processor 118, the cache 120, the memory 122, and the communication interface 128 communicate with each other via the communication bus 126.

[0027] The communication interface 128 is used to communicate with the production host, the disaster recovery array and the hard disk 31. In addition, the communication interface 128 is also used to communicate with the controller 22.

[0028] The memory 122 is used to store the program 124. The memory 122 may include a high-speed RAM memory, and may also include a non-volatile memory, such as at least one hard disk memory. It is understandable that the memory 122 can be a random access memory (RAM), a disk, a hard disk, an optical disk, a solid state disk (SSD) or a non-volatile memory, etc., which can store program codes. Non-transitory machine-readable media.

[0029] Program 124 may include program code including the file system described above as well as other program code.

[0030] The cache 120 (Cache) is used to cache data received from the production host or data read from the hard disk. The cache 120 can be a non-transitory machine-readable medium that can store data, such as RAM, ROM, flash memory, or solid state disk (SSD), which is not limited here.

[0031] In addition, the memory 122 and the cache 120 may be provided together or separately, which is not limited in the embodiment of the present invention.

[0032] The processor 118 may be a central processing unit (CPU), or an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present invention.

[0033] The structure of the disaster recovery array 30 is the same as that of the production array 20. Its function is to take over the production array 20 and continue to process services when a failure occurs in the production array 20.

[0034] Combine the following Figure 1 and Figure 2 , describes a remote data replication method according to an embodiment of the present invention. The method is applied in Figure 1 In the asynchronous remote replication scenario shown in FIG. 1 , the production array 20 and the disaster recovery array 30 perform the operation. Figure 3 Said method may include the following steps:

[0035] Step 1: The first controller 21 detects whether there is a replication task locally.

[0036] A replication task refers to a task of replicating data from the production array 20 to the disaster recovery array 30. Exemplarily, a replication queue is stored in the cache of the first controller, and the replication queue may include multiple replication tasks, each replication task may be described by information such as a file name and a write time of file data. The first controller may determine whether there is a replication task currently by checking the information contained in the replication queue. In addition, the queue is only an example of an embodiment of the present invention, and this embodiment may also use other data structures, such as a heap, a stack, etc., to store replication tasks.

[0037] Step 2: When the first controller 21 has no replication task, it sends a request message to the second controller 22 .

[0038] The request message is used to apply for a replication task to the second controller 22. It is understandable that the production array 20 may include other controllers, some of which are in an idle state (no replication task), while some of which may be in a busy state (including multiple replication tasks to be processed), so the controller in the idle state can apply for a replication task to the controller in the busy state. For the convenience of description, this embodiment takes the second controller 22 as an example of a controller in a busy state, and the second controller 22 includes at least two replication tasks.

[0039] In actual applications, the first controller 21 may send query messages to each controller in the production array 20 to obtain the replication tasks to be processed by each controller. Then, a controller in a busy state is selected and a request message is sent to it. Alternatively, a controller is determined in the production array 20 to collect the number of replication tasks to be processed by each controller and notify the first controller 21 of the controller currently in a busy state.

[0040] Step 3: The second controller 22 allocates one or more replication tasks to the first controller 21 according to the request message.

[0041] Similar to the first controller 21, the cache of the second controller also stores a copy queue, which may include multiple copy tasks. The second controller may assign one or more of the copy tasks to the first controller 21 to ensure task balance among the controllers. Specifically, the second controller 22 may assign one or more copy tasks that enter the queue earliest to the first controller 21 according to the first-in-first-out principle. The so-called assigning the copy task to the first controller 21 may specifically be sending the data corresponding to the copy task to the first controller 21. The data corresponding to the copy task includes the data to be copied to the disaster recovery array 30. In the embodiment of the present invention, the data to be copied to the disaster recovery array 30 is referred to as file data, that is, the data block corresponding to the file. Since the copy task can be described by a file name, the file data can be obtained through the file name and the corresponding metadata and sent to the first controller 21. In addition, in addition to the file data, the data corresponding to the copy task also includes the file name of the file to which the file data belongs and the write time of the file data. The write time of the file data refers to the time when the file data is written to the production array. It may be a specific time point, or it may be a time interval used to represent a time range, or it may be a version number representing the version information of the file. This embodiment does not impose any limitation on the meaning and form of the write time, as long as the order in which the file data is written into the production array can be obtained by comparing the various write times.

[0042] Multiple replication tasks in a queue may be replication tasks for the same file (these replication tasks have the same file name), or they may be replication tasks for different files. Taking multiple replication tasks for the same file as an example, the multiple replication tasks correspond to multiple write operations for the file. The embodiment of the present invention can use a serial number to record multiple write operations on a file. For example, when a file is just created, that is, when the first write operation is performed, its serial number is 1; when the file is modified, that is, when the second write operation is performed, its serial number is 2. The so-called execution of multiple replication tasks for a file is to synchronize the multiple write operations corresponding to the file to the disaster recovery array. Therefore, each replication task can correspond to a unique serial number.

[0043] For the convenience of description, in this embodiment, the replication task assigned by the second controller 22 to the first controller 21 is called the first replication task, and the remaining replication tasks in the queue other than the replication task assigned by the second controller 22 to the first controller 21 are called the second replication tasks. For example, the first replication task and the second replication task may include the following information respectively:

[0044] file name Serial Number The time when the file data is written 0X100 001 2016.1.1 0X100 002 2016.1.2

[0045] As shown in the above table, the data corresponding to the first copy task belongs to the file name 0X100, the writing time of the data is 2016.1.1, and the serial number of the first copy task is 001; the data corresponding to the second copy task belongs to the file name 0X100, the writing time of the data is 2016.1.2, and the serial number of the second copy task is 002.

[0046] Step 4: the first controller 21 receives data corresponding to the first replication task, and sends the data to the disaster recovery array 30 .

[0047] Specifically, the second controller 22 can obtain the file data according to the file name and the corresponding metadata, and send the file data, the file name, the serial number, and the writing time of the file data to the first controller 21. The first controller 21 executes the replication task, that is, sends the file data, the file name, the serial number, and the writing time of the file data to the disaster recovery array 30.

[0048] Step 5: The second controller 22 sends the data corresponding to the second replication task to the disaster recovery array 30 .

[0049] Specifically, the second controller 22 obtains file data according to the file name and corresponding metadata recorded in the second replication task, and sends the file data, the file name, and the writing time of the file data to the disaster recovery array 30 .

[0050] pass Figure 3 In the illustrated implementation, a controller in an idle state may apply for a replication task from a controller in a busy state, and the controller in a busy state may allocate a portion of its own replication task to the controller in an idle state. Thus, each controller may process replication tasks in parallel, thereby improving replication efficiency.

[0051] The following describes how to ensure the consistency of files in the disaster recovery array and the production array when each controller processes replication tasks in parallel.

[0052] Depend on Figure 3 As shown, the first controller 21 executes the first replication task, and copies the file data corresponding to the first replication task to the disaster recovery array 30; the second controller 22 executes the second replication task, and copies the file data corresponding to the second replication task to the disaster recovery array 30. For the convenience of description, the file data corresponding to the first replication task is referred to as data A, and the file data corresponding to the second replication task is referred to as data B. Although the first controller 21 and the second controller 22 execute the two replication tasks in parallel, the disaster recovery array 30 often does not receive data A and data B at the same time.

[0053] Case 1: The disaster recovery array 30 receives data A first, and then receives data B.

[0054] When receiving data A, the disaster recovery array 30 will also receive and save the file name of the file to which data A belongs, the serial number of the first replication task, and the write time of data A. The disaster recovery array can traverse the file names of local files and determine that data A does not belong to any local file. Thus, a new file is created, which is a backup file of the file to which data A belongs in the production array. The file name of the backup file can be consistent with the source file (the file to which data A belongs in the production array). Subsequently, the disaster recovery array 30 writes data A into the backup data and records the write time of data A, which is the same as the write time of data A sent by the production array 20.

[0055] After the disaster recovery array 30 receives data A, it receives data B. Since the file name of the file to which data B belongs is the same as the file name of the backup file, the disaster recovery array 30 does not need to create a new file. Next, the disaster recovery array 30 records the write time corresponding to data B, which is the same as the write time of data B sent by the production array 20. The disaster recovery array 30 compares the write time of data B with the write time of data A, and determines that the write time of data B is later than the write time of data A, so data A is the initial data of the backup file, and data B is the modified data of the backup file. The modified data can overwrite the initial data, and the disaster recovery array executes the operation of writing data B into the backup file.

[0056] Case 2: The disaster recovery array 30 receives data B first, and then receives data A.

[0057] When receiving data B, the disaster recovery array 30 traverses the file names of local files and determines that data B does not belong to any local file. Thus, a new file is created, which is a backup file of the file to which data B belongs in the production array. The file name of the backup file can be consistent with the source file (the file to which data B belongs in the production array). Subsequently, the disaster recovery array 30 writes data B into the backup data and records the writing time of data B, which is the same as the writing time of data B sent by the production array 20.

[0058] After the disaster recovery array 30 receives data B, it receives data A. Since the file name of the file to which data A belongs is the same as the file name of the backup file, the disaster recovery array 30 does not need to create a new file. Next, the disaster recovery array 30 records the write time corresponding to data A, which is the same as the write time of data A sent by the production array 20. The disaster recovery array 30 compares the write time of data B with the write time of data A, and determines that the write time of data A is earlier than the write time of data B. Therefore, data A is the initial data of the backup file, and data B is the modified data of the backup file. The initial data cannot overwrite the modified data, and the disaster recovery array does not perform the operation of writing data A into the backup file.

[0059] Therefore, when receiving multiple data for the same file, the disaster recovery array 30 can determine whether to perform a write operation on the backup file according to the write time of each data. The principle is that only data with a later write time can be used to overwrite data with an earlier write time, thereby ensuring file consistency.

[0060] In addition, when a file in the production array 20 is deleted, in order to maintain consistency, the backup file in the disaster recovery array 30 also needs to be deleted. Specifically, the production array 20 can send a command to delete the file to the disaster recovery array, and the command includes the file name of the file and the latest serial number (the serial number corresponding to the last write operation). After receiving the command to delete the file, the disaster recovery array 30 searches for the corresponding backup file according to the file name, and determines whether the latest serial number of the backup file is the same as the serial number sent by the production array 20. If they are the same, the disaster recovery array 30 executes the operation of deleting the backup file; otherwise, the operation of deleting the backup file is not executed.

[0061] Finally, it should be noted that the above embodiments are only used to illustrate the technical solution of the present invention, rather than to limit it.

Claims

1. A remote data replication method, characterized in that: The method is applied to a storage system, the storage system includes a production site and a disaster recovery site, the production site and the disaster recovery site are both storage devices including a file system, and the method includes: The production site detects whether there is a replication task locally; When the first controller in the production site has no replication task, the first controller sends a request message to the second controller in the production site, the request message is used to apply for a replication task from the second controller, the second controller includes at least two replication tasks, each of the replication tasks includes a file name and a write time of file data, the file name is used to determine whether a write operation needs to create a file, and the write time is used to determine whether to perform a write operation on the data; The second controller reads data corresponding to the first replication task according to the request message and sends the data to the first controller; The first controller receives data corresponding to the first replication task, and sends the data corresponding to the first replication task to the disaster recovery site; The second controller sends the data corresponding to the second replication task to the disaster recovery site.

2. The method according to claim 1, characterized in that The second controller maintains a replication queue, wherein the replication queue includes the at least two replication tasks; The second controller reading the data corresponding to the first replication task and sending the data corresponding to the first replication task to the first controller according to the request message includes: the second controller obtaining the first replication task from the replication queue and sending the data corresponding to the first replication task to the first controller; The second controller sending the data corresponding to the second replication task to the disaster recovery site includes: The second controller obtains a second replication task from the replication queue, and sends data corresponding to the second replication task to the disaster recovery site.

3. The method according to claim 1 or 2, characterized in that: The first copy task and the second copy task are copy tasks for the same file.

4. The method according to claim 3, characterized in that The file has a unique file name, the data corresponding to the first copy task includes the file name, the initial data of the file, and the writing time of the initial data, the data corresponding to the second copy task includes the file name, the modified data of the file, and the writing time of the modified data, and the writing time of the modified data is later than the writing time of the initial data.

5. The method according to claim 4, characterized in that The method further comprises: The disaster recovery site receives the data corresponding to the first replication task, creates a backup file of the file, writes the initial data into the backup file, and the file name of the backup file is the same as the file name of the file; After receiving the data corresponding to the first replication task, the disaster recovery site receives the data corresponding to the second replication task; When the disaster recovery site determines that the file name corresponding to the second replication task is the same as the file name of the backup file, determining whether the writing time of the modified data is later than the writing time of the initial data; When the disaster recovery site determines that the writing time of the modified data is later than the writing time of the initial data, the modified data is written into the backup file.

6. The method according to claim 4, characterized in that The method further comprises: The disaster recovery site receives the data corresponding to the second replication task, creates a backup file of the file, writes the modified data into the backup file, and the file name of the backup file is the same as the file name of the file; After receiving the data corresponding to the second replication task, the disaster recovery site receives the data corresponding to the first replication task; When the disaster recovery site determines that the file name corresponding to the first replication task is the same as the file name of the backup file, determining whether the writing time of the initial data is later than the writing time of the modified data; When the disaster recovery site determines that the writing time of the initial data is earlier than the writing time of the modified data, the operation of writing the initial data into the backup file is not performed.

7. A storage device, characterized in that: The storage device has a file system, and the storage device includes at least a first controller and a second controller. The first controller is used to detect whether there is a replication task locally. When there is no replication task in the first controller, the first controller sends a request message to the second controller, and the request message is used to apply for a replication task from the second controller. The second controller includes at least two replication tasks, and each replication task includes a file name and a write time of file data. The file name is used to determine whether a write operation needs to create a file, and the write time is used to determine whether to perform a write operation on the data; The second controller is used to read the data corresponding to the first replication task and send it to the first controller according to the request message; The first controller is further configured to receive data corresponding to the first replication task, and send the data corresponding to the first replication task to other storage devices; The second controller is further configured to send the data corresponding to the second replication task to the other storage device.

8. The storage device according to claim 7, characterized in that: The second controller maintains a replication queue, wherein the replication queue includes the at least two replication tasks; The second controller is specifically used to obtain the first replication task from the replication queue and send the data corresponding to the first replication task to the first controller; and obtain the second replication task from the replication queue and send the data corresponding to the second replication task to the other storage devices.

9. The storage device according to claim 7 or 8, characterized in that: The first copy task and the second copy task are copy tasks for the same file.

10. The storage device according to claim 9, characterized in that: The file has a unique file name, the data corresponding to the first copy task includes the file name, the initial data of the file, and the writing time of the initial data, the data corresponding to the second copy task includes the file name, the modified data of the file, and the writing time of the modified data, and the writing time of the modified data is later than the writing time of the initial data.

11. A storage system, characterized in that: It includes a production site and a disaster recovery site, both of which are storage devices containing a file system, and the production site includes at least a first controller and a second controller. The first controller is used to detect whether there is a replication task locally; when there is no replication task in the first controller, the first controller sends a request message to the second controller, the request message is used to apply for a replication task from the second controller, the second controller includes at least two replication tasks, each of the replication tasks includes a file name and a write time of file data, the file name is used to determine whether a write operation needs to create a file, and the write time is used to determine whether to perform a write operation on the data; The second controller is used to read the data corresponding to the first replication task and send it to the first controller according to the request message; The first controller is further configured to receive data corresponding to the first replication task, and send the data corresponding to the first replication task to the disaster recovery site; The second controller is further configured to send data corresponding to the second replication task to the disaster recovery site.

12. The storage system according to claim 11, characterized in that: The second controller maintains a replication queue, wherein the replication queue includes the at least two replication tasks; The second controller is specifically used to obtain the first replication task from the replication queue and send the data corresponding to the first replication task to the first controller; and obtain the second replication task from the replication queue and send the data corresponding to the second replication task to the disaster recovery site.

13. The storage system according to claim 11 or 12, characterized in that: The first copy task and the second copy task are copy tasks for the same file.

14. The storage system according to claim 13, characterized in that: The file has a unique file name, the data corresponding to the first copy task includes the file name, the initial data of the file, and the writing time of the initial data, the data corresponding to the second copy task includes the file name, the modified data of the file, and the writing time of the modified data, and the writing time of the modified data is later than the writing time of the initial data.

15. The storage system according to claim 14, characterized in that: The disaster recovery site is further used to receive the data corresponding to the first replication task, create a backup file of the file, write the initial data into the backup file, and the file name of the backup file is the same as the file name of the file; after receiving the data corresponding to the first replication task, receive the data corresponding to the second replication task; and when determining that the file name corresponding to the second replication task is the same as the file name of the backup file, determine whether the write time of the modified data is later than the write time of the initial data; When the disaster recovery site determines that the writing time of the modified data is later than the writing time of the initial data, the modified data is written into the backup file.

16. The storage system according to claim 14, characterized in that: The disaster recovery site is further used to receive the data corresponding to the second replication task, create a backup file of the file, write the modified data into the backup file, and the file name of the backup file is the same as the file name of the file; After receiving the data corresponding to the second copy task, receiving the data corresponding to the first copy task; when determining that the file name corresponding to the first copy task is the same as the file name of the backup file, determining whether the writing time of the initial data is later than the writing time of the modified data; When the disaster recovery site determines that the writing time of the initial data is earlier than the writing time of the modified data, the operation of writing the initial data into the backup file is not performed.

Images