WO2018076633A1

WO2018076633A1 - Remote data replication method, storage device and storage system

Info

Publication number: WO2018076633A1
Application number: PCT/CN2017/081341
Authority: WO
Inventors: 孔晓龙
Original assignee: 华为技术有限公司
Priority date: 2016-10-28
Filing date: 2017-04-21
Publication date: 2018-05-03
Also published as: CN106528338A; CN106528338B; CN112068992A

Abstract

A remote data replication method, a storage device and a storage system. A first controller detects whether there is a replication task at the locality; 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 for applying to the second controller for an application task, and the second controller comprises at least two replication tasks; the second controller reads data corresponding to a first replication task according to the request message and sends same to the first controller; and the first controller receives the data corresponding to the first replication task and sends the data corresponding to the first replication task to a disaster backup array, and the second controller sends the data corresponding to the second replication task to the disaster backup array. Accordingly, the purpose of parallel data replication in a multi-variable control system is achieved.

Description

Remote data replication method, storage device and storage system

Technical field

Embodiments of the present invention relate to the field of storage technologies, and in particular, to a remote data replication method, a storage device, and a storage system.

Background technique

Data disaster recovery, also known as remote data replication technology, refers to the establishment of an off-site data system, which is an available copy of local data. In the event of a disaster in local data and the entire application system, the system maintains at least one copy of the critical business data available in the field.

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 service operations. In the disaster recovery center, hosts and storage arrays are deployed to take over the services after a disaster occurs in the production center. In a mass storage system, the storage arrays in the production center and the storage arrays in 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 the files by each controller need to be serially copied to the disaster. The backup center affects the efficiency of replication.

Summary of the invention

The embodiment provides a remote data replication method and a storage system, which are capable of concurrently executing a replication task in a multi-control system.

In a first aspect, a remote data replication method is provided. The method is applied to a storage system including a production array and a disaster recovery array, the production array including at least a first controller and a second controller. The first controller detects whether there is a copy task locally, and when there is no copy task, sends a request message to the second controller. The request message is used to apply for a copy task to the second controller, and the second controller includes at least two copy tasks. The second controller reads the data corresponding to the first copy task according to the request message and sends the data to the first controller. The first controller receives the data corresponding to the first replication task, and 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 Describe the disaster recovery array.

In this embodiment, the first controller has no replication task and is in an idle state, and 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 request a copy task. The second controller allocates one of its two at least two copy tasks to the first controller according to the request message, so that the first controller and the second controller can each perform a copy task, and the parallel processing is achieved. The purpose is to improve the efficiency of replication.

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

In conjunction with the first aspect, and the first embodiment of the first aspect, in the second embodiment, the first replication task and the second replication task are replication tasks for the same file. This enables parallel copying of the same file.

With reference to the second implementation manner of the first aspect, in a third implementation manner, the file has a unique file name, and the data corresponding to the first copy task includes the file name, and initial data of the file. And the initial Data write time, the data corresponding to the second copy task includes the file name, the modified data of the file, and the write time of the modified data, and the write time of the modified data is later than The write time of the initial data.

With reference to the third implementation manner of the first aspect, in a fourth implementation manner, the disaster recovery array receives data corresponding to the first replication task, creates a backup file of the file, and writes the initial data. Entering the backup file, 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 data corresponding to the second replication task. When the disaster recovery array determines that the file name corresponding to the second copy task is the same as the file name of the backup file, it is determined whether the write time of the modified data is later than the write time of the initial data. And 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 and then receives the modified data, the modified data can be written into the backup file. Even if the modified data will overwrite the initial data, it will not cause data inconsistency between the disaster recovery array and the production array.

With reference to the third implementation manner of the first aspect, in a fifth implementation manner, the disaster recovery array receives data corresponding to the second replication task, creates a backup file of the file, and writes the modified data. Entering the backup file, 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 data corresponding to the first replication task. When the disaster recovery array determines that the file name corresponding to the first copy task is the same as the file name of the backup file, it is determined whether the write time of the initial data is later than the write time of the modified data. When the disaster recovery array determines that the write time of the initial data is earlier than the write 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 and then receives the initial data, the operation of writing the initial data to the backup file is not performed to prevent the data of the disaster recovery array and the production array from being inconsistent.

A second aspect of the present invention provides a storage device to perform the method provided by the first aspect.

A third aspect of the present invention provides a storage device to perform the method provided by the first aspect.

DRAWINGS

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings to be used in the embodiments will be briefly described below.

1 is a schematic structural diagram of a system according to an embodiment of the present invention;

2 is a structural diagram of a controller according to an embodiment of the present invention;

FIG. 3 is a schematic flowchart of a remote data replication method according to an embodiment of the present invention.

detailed description

The embodiment provides a remote data replication method, a storage device, and a storage system, which are capable of concurrently executing a replication task in a multi-control system.

1 is a schematic structural diagram of a system for remote data replication according to an embodiment of the present invention. As shown in FIG. 1 , a production center includes a production host, a connection device, and a production array 20; the system architecture of the disaster recovery center is similar to that of a production center, including a disaster. The standby host, the connected device, and the disaster recovery array 30. In the embodiment of the present invention, there may be more than one disaster recovery center. The production center and the disaster recovery center can transmit data through IP (Internet Protocol) or FC (Fiber Chanel) or other protocols.

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

The connected device can be any interface between the storage device and the host, such as a fiber switch, or other switch known in the art.

Both the production array 20 and the disaster recovery array 30 can be storage devices, such as Redundant Arrays of Inexpensive Disks (RAID), Just a Bunch Of Disks (JBOD), and Direct Access Storage. Device, DASD) One or more interconnected hard drives, such as tape libraries, one or more storage units of tape storage devices.

Both the production array 20 and the disaster recovery array 30 in this embodiment are storage devices having a file system, that is, data stored in the storage medium is managed and accessed in units of files. A 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 concept 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 have to care about the data block whose data is actually stored in the hard disk address, and only needs to remember the directory and file name of the file. Similarly, before writing new data, the user does not have to care that the block address on the hard disk is not being used. The storage space management (allocation and release) function on the hard disk is automatically completed by the file system, and the user only needs to remember that the data is written. Which file is in the file.

The hardware structure of the production array 20 and the disaster recovery array 30 is the same. 2 is a schematic structural view of a production array 20 according to an embodiment of the present invention, and FIG. 3 is a schematic structural diagram of a disaster recovery array 30 according to an embodiment of the present invention.

As shown in FIG. 2, the production array 20 includes at least a controller 21, a controller 22, and a plurality of hard disks 31. Controller 21 can include any computing device such as a server, desktop computer, or the like. Inside the controller, a file system and other applications are installed. The controller 21 is operative to perform various operations related to files, such as creating a file, creating a directory, reading a file operation, writing a file operation, transmitting a data copy request, and the like. The controller 22 and the controller 21 are similar in structure and have the same function. The production array 20 includes a plurality of hard disks 31 for providing storage space to save files. It should be noted that the controller 21 and the controller 22 are only examples of the embodiment of the present invention, and other controllers may be included in the embodiment of the present invention. This embodiment does not limit the number of controllers.

The controller 21 mainly includes a processor 118, a cache 120, a memory 122, a communication bus (abbreviated as bus) 126, and a communication interface 128. The processor 118, the cache 120, the memory 122, and the communication interface 128 complete communication with one another via the communication bus 126.

The communication interface 128 is configured to communicate with the production host, the disaster recovery array, and the hard disk 31. Additionally, communication interface 128 is also used to communicate with controller 22.

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 can be understood that the memory 122 can be a random access memory (RAM), a magnetic disk, a hard disk, an optical disk, a solid state disk (SSD), or a nonvolatile memory, and can store program codes. Non-transitory machine readable medium.

Program 124 can include program code, including the file system described above, as well as other program code.

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

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

The processor 118 may be a central processing unit CPU or a specific integrated circuit ASIC (Application) Specific Integrated Circuit), or one or more integrated circuits configured to implement embodiments of the present invention.

The disaster recovery array 30 has the same structure as the production array 20, and functions to take over the production array 20 to continue processing the business when the production array 20 fails.

A remote data copying method according to an embodiment of the present invention will be described below with reference to FIGS. 1 and 2. The method is applied in the scenario of asynchronous remote replication shown in FIG. 1 and is performed by the production array 20 and the disaster recovery array 30. As described in FIG. 3, the method can include the following steps:

Step 1: The first controller 21 detects whether there is a copy task locally.

The replication task refers to the task of copying data from the production array 20 to the disaster recovery array 30. Exemplarily, a copy queue is saved in the cache of the first controller, and the copy queue may include multiple copy tasks, and each copy task may be described by using a file name, a write time of file data, and the like. The first controller can determine whether there is currently a replication task by examining the information contained in the replication queue. In addition, the queue is only an example of the embodiment of the present invention, and other data structures, such as a heap, a stack, and the like, may be used in this embodiment to save the replication task.

Step 2: When the first controller 21 does not copy the task, the request message is sent to the second controller 22.

The request message is used to request a copy task from the second controller 22. It can be understood that the production array 20 may contain other controllers, some controllers are idle (no replication tasks), and some controllers may be busy (including multiple pending replication tasks), then An idle state controller can request a copy task from a controller that is in a busy state. For convenience of description, the present embodiment takes the second controller 22 as a controller in a busy state, and the second controller 22 includes at least two replication tasks.

In a practical application, the first controller 21 can respectively send a query message to each controller in the production array 20 to obtain a copy task to be processed by each controller. Then select a controller that is busy and send a request message to it. Alternatively, a controller is determined in the production array 20 for collecting the number of copy tasks to be processed by the respective controllers and notifying the first controller 21 that the controller is currently in a busy state.

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

Similar to the first controller 21, a copy queue is also stored in the cache of the second controller, and the copy queue may include a plurality of copy tasks. The second controller may assign one or more of the copy tasks to the first controller 21 to ensure task balancing between the various controllers. Specifically, the second controller 22 may assign one or more copy tasks that first enter the queue to the first controller 21 according to the principle of first in first out. The assigning the copy task to the first controller 21 may specifically send the data corresponding to the copy task to the first controller 21. The data corresponding to the replication task includes the data to be copied to the disaster recovery array 30. 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 acquired by 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 further includes a file name of a file to which the file data belongs and a write time of the file data. The write time of the file data refers to the time when the file data is written into the production array, which may be a specific time point, or may be a time interval for indicating a range of time, and may also be representation The version number of the version information of the file. This embodiment does not limit the meaning and form of the write time anyway, as long as the order in which the file data is written into the production array can be obtained by comparison of the respective write times.

Multiple replication tasks in a queue, possibly replication tasks for the same file (these replication tasks) The file name is the same), or it may be a copy task 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. Embodiments of the present invention may utilize a serial number to record multiple write operations to 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 copy tasks for one file is to synchronize the multiple write operations corresponding to the file to the disaster recovery array. Therefore, each copy task can correspond to a unique serial number.

For convenience of description, the copy task assigned to the first controller 21 by the second controller 22 in this embodiment is referred to as a first copy task, and the second controller 22 is assigned to the copy task other than the first controller 21, the queue The remaining replication tasks are called second replication tasks. For example, the first copy task and the second copy task can each include the following information:

文件名file name	序列号serial number	文件数据的写入时间File data write time
0X1000X100	001001	2016.1.12016.1.1
0X1000X100	002002	2016.1.22016.1.2

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

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

Specifically, the second controller 22 may acquire 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 copying task is executed by the first controller 21, that is, the file data, the file name, the serial number, and the writing time of the file data are sent to the disaster recovery array 30.

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

Specifically, the second controller 22 acquires file data according to the file name recorded by the second copy task and the corresponding metadata, and sends the file data, the file name, and the write time of the file data to the disaster. The array 30 is prepared.

Through the embodiment shown in FIG. 3, the controller in the idle state can apply for the replication task to the controller in the busy state, and the controller in the busy state allocates a part of the replication task to the controller in the idle state, thereby Each controller can process the replication task in parallel, improving the replication efficiency.

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

As shown in FIG. 3, the first controller 21 performs the first copy task, and copies the file data corresponding to the first copy task to the disaster recovery array 30. The second controller 22 performs the second copy task. The file data corresponding to the two replication tasks is copied to the disaster recovery array 30. For convenience of description, the file data corresponding to the first copy task is simply referred to as data A, and the file data corresponding to the second copy task is simply referred to as data B. Although the first controller 21 and the second controller 22 perform the two copy tasks in parallel, the disaster recovery array 30 often does not receive the data A and the data B at the same time.

Case 1: The disaster recovery array 30 receives the data A first and then receives the data B.

When receiving the data A, the disaster recovery array 30 also receives and saves the file name of the file to which the data A belongs, the serial number of the first copy task, and the write time of the data A. The disaster recovery array can traverse the file name of the local file to determine that the 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 the data A belongs in the production array. The file name of the backup file may be identical to the source file (data A belongs to the file to which the production array belongs). Subsequently, the disaster recovery array 30 writes the data A to the backup data and records the write time of the data A, which is the same as the write time of the data A transmitted by the production array 20.

After the disaster recovery array 30 receives the data A, the data B is received. Since the file name of the file to which the 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 the data B, which is the same as the write time of the data B transmitted by the production array 20. The disaster recovery array 30 compares the write time of the data B with the write time of the data A, and determines that the write time of the data B is later than the write time of the data A, so the data A is the initial data of the backup file, and the data B Is the modification data of the backup file. The modified data may overwrite the initial data, and the disaster recovery array performs an operation of writing the data B to the backup file.

Case 2: The disaster recovery array 30 receives the data B first and then receives the data A.

When receiving the data B, the disaster recovery array 30 traverses the file name of the local file to determine that the 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 the data B belongs in the production array. The file name of the backup file may be identical to the source file (data B belongs to the file to which the production array belongs). Subsequently, the disaster recovery array 30 writes the data B to the backup data and records the write time of the data B, which is the same as the write time of the data B transmitted by the production array 20.

After the disaster recovery array 30 receives the data B, the data A is received. Since the file name of the file to which the 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 the data A, which is the same as the write time of the data A transmitted by the production array 20. The disaster recovery array 30 compares the write time of the data B with the write time of the data A, and determines that the write time of the data A is earlier than the write time of the data B, so the data A is the initial data of the backup file, and the data B Is the modification data of the backup file. The initial data may not cover the modified data, and the disaster recovery array does not perform the operation of writing the data A to the backup file.

Therefore, when receiving the plurality of data for the same file, the disaster recovery array 30 can determine whether to perform the writing operation on the backup file according to the writing time of each data. The principle is that the writing time can only be used later. The data covers older data written earlier, thus ensuring file consistency.

In addition, when the files in the production array 20 are deleted, in order to maintain consistency, the backup files in the disaster recovery array 30 also need to be deleted. Specifically, the production array 20 may send an instruction to delete the file to the disaster recovery array, the instruction including the file name of the file, and the latest serial number (the serial number corresponding to the last write operation). After receiving the instruction 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 performs an operation of deleting the backup file; otherwise, the operation of deleting the backup file is not performed.

Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and are not limited thereto.

Claims

A remote data replication method, wherein the method is applied to a storage system, where the storage system includes a production array and a disaster recovery array, the production array includes at least a first controller and a second controller, Methods include:

The first controller detects whether there is a copy task locally;

When there is no replication task in the first controller, the first controller sends a request message to the second controller, where the request message is used to apply for a replication task to the second controller, where The second controller includes at least two replication tasks;

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 data corresponding to the first replication task to the disaster recovery array.

The second controller sends data corresponding to the second replication task to the disaster recovery array.
The method according to claim 1, wherein the second controller maintains a copy queue, and the copy queue includes the at least two copy tasks;

The second controller, according to the request message, reading data corresponding to the first copy task and sending the data to the first controller, includes: the second controller acquiring the first one from the copy queue a copy task, sending data corresponding to the first copy task to the first controller;

The sending, by the second controller, the data corresponding to the second replication task to the disaster recovery array 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 array.
The method according to claim 1 or 2, wherein the first copy task and the second copy task are copy tasks for the same file.
The method according to claim 3, wherein said file has a unique file name, and data corresponding to said first copy task includes said file name, initial data of said file, and said initial data Write time, the data corresponding to the second copy task includes the file name, the modified data of the file, and the write time of the modified data, the write time of the modified data is later than the The write time of the initial data.
The method of claim 4, wherein the method further comprises:

The disaster recovery array receives the data corresponding to the first copy task, creates a backup file of the file, and writes the initial data into the backup file, where the file name of the backup file and the file of the file are Same name;

After receiving the data corresponding to the first replication task, the disaster recovery array receives data corresponding to the second replication task;

When the disaster recovery array determines that the file name corresponding to the second copy task is the same as the file name of the backup file, determining whether the write time of the modified data is later than the write time of the initial data;

And 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.
The method of claim 4, wherein the method further comprises:

The disaster recovery array receives data corresponding to the second replication task, creates a backup file of the file, and writes the modified data into the backup file, where the file name of the backup file and the file of the file are Same name;

After receiving the data corresponding to the second replication task, the disaster recovery array receives data corresponding to the first replication task;

When the disaster recovery array determines that the file name corresponding to the first copy task is the same as the file name of the backup file, determining whether the write time of the initial data is later than the write time of the modified data;

When the disaster recovery array determines that the write time of the initial data is earlier than the write time of the modified data, the operation of writing the initial data into the backup file is not performed.
A storage device, characterized in that the storage device comprises at least a first controller and a second controller,

The first controller is configured 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, where the request message is sent. And configured to apply for a replication task to the second controller, where the second controller includes at least two replication tasks;

The second controller is configured to: according to the request message, read data corresponding to the first replication task and send the data to the first controller;

The first controller is further configured to receive data corresponding to the first replication task, and send data corresponding to the first replication task to another storage device;

The second controller is further configured to send data corresponding to the second replication task to the other storage device.
The storage device according to claim 7, wherein the second controller maintains a copy queue, and the copy queue includes the at least two copy tasks;

The second controller is specifically configured to acquire the first copy task from the copy queue, send data corresponding to the first copy task to the first controller, and copy from the first A second replication task is obtained in the queue, and data corresponding to the second replication task is sent to the other storage device.
The storage device according to claim 7 or 8, wherein the first copy task and the second copy task are copy tasks for the same file.
The storage device according to claim 9, wherein said file has a unique file name, and said data corresponding to said first copy task includes said file name, initial data of said file, and said initial Data write time, the data corresponding to the second copy task includes the file name, the modified data of the file, and the write time of the modified data, and the write time of the modified data is later than The write time of the initial data.
A storage system, comprising: a production array and a disaster recovery array, the production array including at least a first controller and a second controller,

The first controller is configured to detect whether there is a copy task locally; when there is no copy task in the first controller, the first controller sends a request message to the second controller, the request message And configured to apply for a replication task to the second controller, where the second controller includes at least two replication tasks;

The second controller is configured to: according to the request message, read data corresponding to the first replication task and send the data to the first controller;

The first controller is further configured to receive data corresponding to the first replication task, and send data corresponding to the first replication task to the disaster recovery array;

The second controller is further configured to send data corresponding to the second replication task to the disaster recovery array.
The storage system according to claim 11, wherein the second controller maintains a copy queue, and the copy queue includes the at least two copy tasks;

The second controller is specifically configured to acquire the first copy task from the copy queue, send data corresponding to the first copy task to the first controller, and copy from the first A second replication task is obtained in the queue, and data corresponding to the second replication task is sent to the disaster recovery array.
The storage system according to claim 11 or 12, wherein the first copy task and the second copy task are copy tasks for the same file.
The storage system according to claim 13, wherein said file has a unique file name, and said data corresponding to said first copy task includes said file name, initial data of said file, and said initial Data write time, the data corresponding to the second copy task includes the file name, the modified data of the file, and the write time of the modified data, and the write time of the modified data is later than The write time of the initial data.
A storage system according to claim 14 wherein:

The disaster recovery array is further configured to receive data corresponding to the first copy task, create a backup file of the file, and write the initial data into the backup file, where the file name and the file name of the backup file are The file name of the file is the same; after receiving the data corresponding to the first copy task, receiving data corresponding to the second copy task; determining a file name corresponding to the second copy task and the When the file name of the backup file is the same, determining 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 initial data The modification data is written to the backup file at the time of writing.
A storage system according to claim 14 wherein:

The disaster recovery array is further configured to receive data corresponding to the second copy task, create a backup file of the file, and write the modified data into the backup file, where the file name and the file name of the backup file are The file name of the file is the same; after receiving the data corresponding to the second copy task, receiving data corresponding to the first copy task; determining a file name corresponding to the first copy task and the When the file names of the backup files are the same, determining whether the write time of the initial data is later than the write time of the modified data; when the disaster recovery array determines that the write time of the initial data is earlier than the modified data At the time of writing, the operation of writing the initial data into the backup file is not performed.