CN106528338B - Remote data copying method, storage device and storage system - Google Patents
Remote data copying method, storage device and storage system Download PDFInfo
- Publication number
- CN106528338B CN106528338B CN201610971200.0A CN201610971200A CN106528338B CN 106528338 B CN106528338 B CN 106528338B CN 201610971200 A CN201610971200 A CN 201610971200A CN 106528338 B CN106528338 B CN 106528338B
- Authority
- CN
- China
- Prior art keywords
- controller
- data
- file
- replication
- replication task
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
- G06F11/1461—Backup scheduling policy
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1448—Management of the data involved in backup or backup restore
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
A remote data copying method, a storage device and a storage system are provided. The first controller detects whether a local copy task exists; 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 for a replication task to the second controller, and the second controller at least comprises two replication tasks. And the second controller reads the data corresponding to the first replication task according to the request message and sends the data to the first controller. And the first controller receives the data corresponding to the first replication task, sends the data corresponding to the first replication task to the disaster backup array, and the second controller sends the data corresponding to the second replication task to the disaster backup array. Therefore, the purpose of parallel data copying in the multi-control system is achieved.
Description
Technical Field
The embodiment of the invention relates to the technical field of storage, in particular to a remote data copying method, a storage device and a storage system.
Background
Data disaster recovery, also known as remote data replication technology, refers to the establishment of a data system in a remote location that is an available replica of local data. When the local data and the whole application system have disasters, the system at least stores a piece of available data of key services in different places.
A typical data disaster recovery system includes a production center and a disaster recovery center. In the production center, a host and a storage array are deployed for normal service operation; in the disaster recovery center, a host and a storage array are deployed and used for taking over the services of the production center after a disaster occurs in the production center. In a mass storage system, both the production center storage array and the disaster recovery center storage array are typically storage arrays that contain multiple controllers. Different controllers can write and modify the same file respectively, in order to ensure that the file copied to the disaster recovery center is consistent with the file of the production center, the writing operation of each controller on the file needs to be copied to the disaster recovery center in series, and the copying efficiency is influenced.
Disclosure of Invention
The embodiment provides a remote data copying method and a storage system, which can execute copying tasks in a multi-control system concurrently.
In a first aspect, a method of remote data replication is provided. The method is applied to a storage system, the storage system comprises a production array and a disaster recovery array, and the production array at least comprises a first controller and a second controller. The first controller detects whether a replication task exists locally, and sends a request message to the second controller when the replication task does not exist. The request message is used for applying for a replication task to the second controller, and the second controller at least comprises two replication tasks. And the second controller reads the data corresponding to the first replication task according to the request message and sends the data 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 the disaster backup array, and the second controller also sends the data corresponding to the second replication task to the disaster backup 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. Thus, the first controller may send a request message to the second controller to apply for a replication task. The second controller allocates at least two replication tasks to the first controller according to the request message, so that the first controller and the second controller can respectively execute one replication task, the purpose of parallel processing is achieved, and the replication efficiency is improved.
In a first implementation form 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 acquires 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 acquires a second replication task from the replication queue and sends data corresponding to the second replication task to the disaster recovery array.
With reference to the first aspect and the first implementation manner of the first aspect, in a second implementation manner, the first replication task and the second replication task are replication tasks for a same file. Thereby enabling parallel replication 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, the data corresponding to the first replication 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 replication task includes the file name, the modified data of the file, and the writing time of the modified data is later than the writing 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 into the backup file, where a file name of the backup file is the same as a file name of the file. And after receiving the data corresponding to the first replication task, the disaster recovery array receives the data corresponding to the second replication task. And 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, and judges whether the writing time of the modified data is later than the writing time of the initial data. And when the disaster recovery array determines that the writing time of the modified data is later than that of the initial data, writing the modified data into the backup file. In such an embodiment, if the disaster recovery array receives the initial data first and then the modified data, the modified data may be written to the backup file. Even if the modified data can cover the initial data, the data of the disaster recovery array and the production array cannot be inconsistent.
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 into the backup file, where a file name of the backup file is the same as a file name of the file. And after receiving the data corresponding to the second replication task, the disaster recovery array receives the data corresponding to the first replication task. And 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, and judges whether the writing time of the initial data is later than the writing time of the modified data. And 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 executed. In such an embodiment, if the disaster recovery array receives the modified data first and then receives the original data, the operation of writing the original 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 invention provides a storage device to perform the method provided by the first aspect.
A third aspect of the 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 required to be used in the embodiments will be briefly described below.
FIG. 1 is a schematic diagram of a system architecture provided by an embodiment of the present invention;
FIG. 2 is a block diagram of a controller provided by an embodiment of the present invention;
fig. 3 is a flowchart illustrating a remote data replication method according to an embodiment of the present invention.
Detailed Description
The embodiment provides a remote data copying method, a storage device and a storage system, which can execute copying tasks in a multi-control system concurrently.
Fig. 1 is a schematic system architecture diagram of a remote data replication method according to an embodiment of the present invention, and 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 the production center, and comprises a disaster recovery host, a connection device and a disaster recovery array 30. In the embodiment of the invention, more than one disaster recovery center can be provided. The production center and the disaster recovery center can transmit data through ip (internet protocol), fc (fiber channel), or other protocols.
The production host and the disaster recovery host can be any computing device, such as a server, a desktop computer, and the like. Inside the host, an operating system and other application programs are installed.
The connection device may be any interface between the storage device and the host, such as a fabric switch, or other switch known in the art.
Both production array 20 and disaster recovery array 30 may be Storage devices, such as one or more interconnected hard disk drives Of redundant arrays Of independent Disks (RAID), Just a Bunch Of Disks (JBOD), Direct Access Storage (DASD), such as a tape library, tape Storage devices Of one or more Storage units.
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 a storage medium is managed and accessed in units of files. A file system is a method of storing and organizing data, which facilitates access and search of data, and uses an abstract logical concept of files and tree directories instead of a concept of data blocks used by physical devices such as a hard disk. After the production array 20 uses the file system to store data, the user does not need to care about how many data blocks the data is actually stored in the hard disk, but only needs to remember the directory and the file name of the file. Also, the user does not have to care that the block address on the hard disk is not used before writing new data, the storage space management (allocation and release) function on the hard disk is done automatically by the file system, and the user only needs to remember in which file the data was written.
The hardware architecture of production array 20 and disaster recovery array 30 is the same. Fig. 2 is a schematic structural diagram 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. The controller 21 may comprise 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 used to perform various operations related to files, such as creating files, creating directories, reading files, writing files, sending data copy requests, and so on. The controller 22 and the controller 21 are similar in structure and function. The production array 20 comprises a number of hard disks 31 for providing storage space for storing 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.
The controller 21 mainly includes a processor (processor)118, a cache (cache)120, a memory (memory)122, a Communication bus (bus) 126, and a Communication Interface (Communication Interface) 128. Processor 118, cache 120, memory 122, and communication interface 128 communicate with each other via a communication bus 126.
And a communication interface 128 for communicating 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.
The memory 122 is used for storing the program 124, and the memory 122 may include a high-speed RAM memory and may further include a non-volatile memory (non-volatile memory), such as at least one hard disk memory. It is 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), a nonvolatile Memory, or various non-transitory machine-readable media capable of storing program code.
Program 124 may include program code that includes the file system described above as well as other program code.
The Cache 120(Cache) is used to Cache data received from the production host or data read from the hard disk. The cache 120 may be various non-transitory (non-transitory) machine-readable media such as a RAM, a ROM, a Flash memory (Flash memory) or a Solid State Disk (SSD), which can store data, and is not limited herein.
In addition, the memory 122 and the cache 120 may be provided together or separately, which is not limited in this embodiment of the present invention.
The processor 118 may be a central processing unit CPU, or an application specific Integrated circuit ASIC (application specific Integrated Circuit), or one or more Integrated circuits configured to implement embodiments of the present invention.
A remote data replication method according to an embodiment of the present invention is described below with reference to fig. 1 and fig. 2. The method is applied in the asynchronous remote replication scenario shown in fig. 1, and is performed by the production array 20 and the disaster recovery array 30. As illustrated in fig. 3, the method may include the steps of:
step 1: the first controller 21 detects whether there is a copy task locally.
The replication task refers to a task of replicating data from production array 20 to disaster recovery array 30. For example, a copy queue is stored in the cache of the first controller, and the copy queue may include a plurality of copy tasks, and each copy task may be described by information such as a file name, a write time of file data, and the like. The first controller may determine whether there is currently a replication task by examining information contained in the replication queue. In addition, the queue is only an example of the embodiment of the present invention, and the embodiment may also use other data structures, such as a heap, a stack, and the like, to store the copy task.
Step 2: when the first controller 21 has no replication task, a request message is sent to the second controller 22.
The request message is used to apply for a replication task to the second controller 22. It will be appreciated that other controllers may be included in the production array 20, some controllers may be idle (no replication tasks) and some controllers may be busy (including multiple pending replication tasks), and the controller in the idle state may apply for a replication task to the controller in the busy state. For convenience of description, in this embodiment, the second controller 22 is taken as an example of a controller in a busy state, and the second controller 22 includes at least two copy tasks.
In practical applications, the first controller 21 may send a query message to each controller in the production array 20 to obtain the replication task to be processed by each controller. And then a controller in a busy state is selected from the controllers and sends a request message to the controller. Alternatively, a controller is determined in the production array 20 for collecting the number of replication tasks to be processed by each controller and informing the first controller 21 of the controller currently in a busy state.
And 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, the buffer of the second controller also stores a replication queue, which may include a plurality of replication tasks. The second controller may assign one or more of the replicated tasks to the first controller 21 to ensure task balance between the various controllers. In particular, the second controller 22 may assign the one or more replication tasks that entered the queue earliest to the first controller 21 on a first-in-first-out basis. The assigning of the copy task to the first controller 21 may specifically be sending data corresponding to the copy task to the first controller 21. The data corresponding to the replication task includes data to be replicated to the disaster recovery array 30, and in the embodiment of the present invention, the data to be replicated to the disaster recovery array 30 is referred to as file data, that is, a data block corresponding to a file. Since the replication task can be described by a file name, file data can be acquired by the file name and corresponding metadata and sent to the first controller 21. In addition, the data corresponding to the copy task includes, in addition to the file data, a file name of a file to which the file data belongs and a write time of the file data. The writing time of the file data refers to the time when the file data is written into the production array, and may be a specific time point, a time interval for representing a time range, or a version number for representing version information of the file. The meaning and form of the writing time are not limited in this embodiment, as long as the sequence of writing the file data into the production array can be obtained by comparing the writing times.
The multiple replication tasks in a queue may be replication tasks for the same file (the file names of the replication tasks are the same), or replication tasks for different files. Taking a plurality of copy tasks for the same file as an example, the plurality of copy tasks correspond to a plurality of write operations for the file. Embodiments of the present invention may use a sequence number to record multiple write operations to a file. For example, when a file is just created, i.e., when a first write operation is performed, its sequence number is 1; when the file is modified, i.e. a second write operation is performed, its sequence number is 2. Executing multiple copy tasks for a file means synchronizing multiple write operations corresponding to the file to the disaster recovery array. Thus, each replication task may correspond to a unique serial number.
For convenience of description, the present embodiment refers to the replication task assigned by the second controller 22 to the first controller 21 as a first replication task, and refers to the replication tasks remaining in the queue other than the replication task assigned by the second controller 22 to the first controller 21 as second replication tasks. For example, the first replication task and the second replication task may include the following information, respectively:
| filename | Serial number | Write time of file data |
| 0X100 | 001 | 2016.1.1 |
| 0X100 | 002 | 2016.1.2 |
As shown in the above table, the data corresponding to the first replication task belongs to a file name with a file name of 0X100, the writing time of the data is 2016.1.1, and the sequence number of the first replication task is 001; the data corresponding to the second copy job belongs to a file name having a file name of 0X100, the writing time of the data is 2016.1.2, and the sequence number of the second copy job is 002.
And 4, step 4: first controller 21 receives data corresponding to the first replication task and sends the data to disaster recovery array 30.
Specifically, the second controller 22 may 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 write time of the file data to the first controller 21. The replication task is performed by the first controller 21, that is, the file data, the file name, the serial number, and the write time of the file data are transmitted to the disaster recovery array 30.
And 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 obtains file data according to the file name recorded by the second replication task and the corresponding metadata, and sends the file data, the file name, and the write time of the file data to the disaster recovery array 30.
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, so that each controller can process the replication tasks in parallel, and the replication efficiency is improved.
The following describes how to ensure consistency between the files of the disaster recovery array and the files of the production array when the respective controllers process the replication tasks in parallel.
As shown in fig. 3, the first controller 21 executes a first copy task, and copies the file data corresponding to the first copy task to the disaster recovery array 30; second controller 22 executes a second copy task, and copies the file data corresponding to the second copy task to disaster recovery array 30. For convenience of description, the file data corresponding to the first copy job is simply referred to as data a, and the file data corresponding to the second copy job is simply referred to as data B. Although the first controller 21 and the second controller 22 perform the two copying tasks in parallel, the disaster recovery array 30 is often not time to receive data a and data B simultaneously.
Case 1: the disaster recovery array 30 receives data a first and then data B.
When receiving the data a, the disaster recovery array 30 also receives and stores the file name of the file to which the data a belongs, the sequence number of the first replication task, and the write time of the data a. The disaster recovery array can traverse the file names of the local files and determine that the data A does not belong to any local file. Thus, a new file is created that is a backup file of the file to which data A belongs in the production array. The file name of the backup file may be consistent with the source file (the file to which data a belongs in the production array). Subsequently, the disaster recovery array 30 writes the data a into the backup data, and records the write time of the data a, which is the same as the write time of the data a sent by the production array 20.
After disaster recovery array 30 receives data a, 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, and the write time is the same as the write time of the 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 to determine that the write time of data B is later than the write time of data a, so that data a is the original data of the backup file and data B is the modified data of the backup file. The modified data can cover the initial data, and the disaster recovery array executes the operation of writing the data B into the backup file.
Case 2: the disaster recovery array 30 receives data B first and then data a.
When receiving the data B, the disaster recovery array 30 traverses the file name of the local file, and determines that the data B does not belong to any local file. Thus, a new file is created that is a backup file of the file to which data B belongs in the production array. The file name of the backup file may be consistent with the source file (the file to which data B belongs in the production array). Subsequently, the disaster recovery array 30 writes the data B into the backup data, and records the write time of the data B, which is the same as the write time of the data B sent by the production array 20.
After disaster recovery array 30 receives data B, 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, and the write time is the same as the write time of the data a sent by the production array 20. Disaster recovery array 30 compares the write time of data a with the write time of data B to determine that the write time of data a is earlier than the write time of data B, and thus data a is the original data of the backup file and data B is the modified data of the backup file. The initial data can not cover the modified data, and the disaster recovery array does not execute the operation of writing the data A into the backup file.
Therefore, when receiving a plurality of 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, and the principle is that only data with a later write time can be used to cover data with an earlier write time, thereby ensuring the consistency of the files.
In addition, when a file in production array 20 is deleted, the backup file in disaster recovery array 30 also needs to be deleted in order to maintain consistency. Specifically, the production array 20 may send an instruction to delete a file to the disaster recovery array, where the instruction includes a file name of the file and a latest serial number (a 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 the backup files are the same, the disaster recovery array 30 executes the operation of deleting the backup files; otherwise, the operation of deleting the backup file is not executed.
Finally, it should be noted that: the above embodiments are only used to illustrate the technical solution of the present invention, and not to limit the same.
Claims (10)
1. A remote data replication method is applied to a storage system, the storage system comprises a production array and a disaster recovery array, the production array at least comprises a first controller and a second controller,
the method comprises the following steps:
the first controller detects whether a local copy task exists; the production array and the disaster recovery array are both storage devices with file systems, and data stored in the storage devices are managed and accessed by taking files as units; when the first controller does not have a replication task, the first controller sends a request message to the second controller, wherein the request message is used for applying for the replication task to the second controller, and the second controller at least comprises 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 the data corresponding to the first replication task to the disaster recovery array;
the second controller sends the data corresponding to the second replication task to the disaster recovery array;
wherein the first replication task and the second replication task are replication tasks for the same file;
wherein the content of the first and second substances,
the file has a unique file name, the data corresponding to the first replication task comprises the file name, the initial data of the file and the writing time of the initial data, the data corresponding to the second replication task comprises 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.
2. The method of claim 1, wherein the second controller maintains a replication queue comprising the at least two replication tasks;
the second controller reads the data corresponding to the first replication task according to the request message and sends the data to the first controller, and the method comprises the following steps: the second controller acquires the first replication task from the replication queue and sends data corresponding to the first replication 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:
and the second controller acquires a second replication task from the replication queue and sends data corresponding to the second replication task to the disaster recovery array.
3. The method according to claim 1 or 2, characterized in that the method further comprises:
the disaster recovery array receives data corresponding to the first replication task, creates a backup file of the file, and writes the initial data into the backup file, wherein the file name of the backup file is the same as that 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;
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, and judges whether the writing time of the modified data is later than the writing time of the initial data;
and when the disaster recovery array determines that the writing time of the modified data is later than that of the initial data, writing the modified data into the backup file.
4. The method according to claim 1 or 2, characterized in that the method further comprises:
the disaster recovery array receives the data corresponding to the second replication task, creates a backup file of the file, and writes the modified data into the backup file, wherein the file name of the backup file is the same as that 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;
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, and judges whether the writing time of the initial data is later than the writing time of the modified data;
and 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 executed.
5. A storage device, wherein the storage device at least includes 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, the request message is used to apply for a replication task to the second controller, and the second controller at least includes two replication tasks;
the second controller is used for reading data corresponding to the first replication task according to the request message and sending the data to the first controller;
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 data corresponding to the second replication task to the other storage devices;
the first replication task and the second replication task are replication tasks for the same file, and data stored in the storage device is managed and accessed in a file unit;
the file has a unique file name, the data corresponding to the first replication task comprises the file name, initial data of the file and writing time of the initial data, the data corresponding to the second replication task comprises the file name, modified data of the file and writing time of the modified data, and the writing time of the modified data is later than the writing time of the initial data;
wherein the other storage devices comprise disaster recovery arrays.
6. The storage device of claim 5, wherein the second controller maintains a replication queue comprising the at least two replication tasks;
the second controller is specifically configured to obtain the first replication task from the replication queue, and send data corresponding to the first replication task to the first controller; and acquiring a second replication task from the replication queue, and sending data corresponding to the second replication task to the other storage devices.
7. A storage system is characterized by comprising a production array and a disaster recovery array, wherein the production array at least comprises a first controller and a second controller, the production array and the disaster recovery array are both storage devices with file systems, and data stored in the storage devices are managed and accessed in a file unit;
the first controller is used for detecting whether a replication task exists locally; when the first controller does not have a replication task, the first controller sends a request message to the second controller, wherein the request message is used for applying for the replication task to the second controller, and the second controller at least comprises two replication tasks;
the second controller is used for reading data corresponding to the first replication task according to the request message and sending the data to the first controller;
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 array;
the second controller is further configured to send data corresponding to the second replication task to the disaster recovery array;
wherein the first replication task and the second replication task are replication tasks for the same file;
wherein the content of the first and second substances,
the file has a unique file name, the data corresponding to the first replication task comprises the file name, the initial data of the file and the writing time of the initial data, the data corresponding to the second replication task comprises 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.
8. The storage system of claim 7, wherein the second controller maintains a replication queue comprising the at least two replication tasks;
the second controller is specifically configured to obtain the first replication task from the replication queue, and send data corresponding to the first replication task to the first controller; and acquiring a second replication task from the replication queue, and sending data corresponding to the second replication task to the disaster recovery array.
9. The storage system according to claim 7 or 8,
the disaster recovery array is further configured to receive data corresponding to the first replication task, create a backup file of the file, and write the initial data into the backup file, where a file name of the backup file is the same as a file name of the file; after receiving the data corresponding to the first replication task, receiving the data corresponding to the second replication task; determining that the file name corresponding to the second replication task is the same as the file name of the backup file, and judging whether the writing time of the modified data is later than the writing time of the initial data; and when the disaster recovery array determines that the writing time of the modified data is later than that of the initial data, writing the modified data into the backup file.
10. The storage system according to claim 7 or 8,
the disaster recovery array is further configured to receive data corresponding to the second replication task, create a backup file of the file, and write the modified data into the backup file, where a file name of the backup file is the same as a file name of the file; after receiving the data corresponding to the second replication task, receiving the data corresponding to the first replication task; determining that the file name corresponding to the first replication task is the same as the file name of the backup file, and judging whether the writing time of the initial data is later than the writing time of the modified data; and 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 executed.
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010780943.6A CN112068992A (en) | 2016-10-28 | 2016-10-28 | Remote data copying method, storage device and storage system |
| CN201610971200.0A CN106528338B (en) | 2016-10-28 | 2016-10-28 | Remote data copying method, storage device and storage system |
| PCT/CN2017/081341 WO2018076633A1 (en) | 2016-10-28 | 2017-04-21 | Remote data replication method, storage device and storage system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610971200.0A CN106528338B (en) | 2016-10-28 | 2016-10-28 | Remote data copying method, storage device and storage system |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010780943.6A Division CN112068992A (en) | 2016-10-28 | 2016-10-28 | Remote data copying method, storage device and storage system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN106528338A CN106528338A (en) | 2017-03-22 |
| CN106528338B true CN106528338B (en) | 2020-08-14 |
Family
ID=58325810
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201610971200.0A Active CN106528338B (en) | 2016-10-28 | 2016-10-28 | Remote data copying method, storage device and storage system |
| CN202010780943.6A Pending CN112068992A (en) | 2016-10-28 | 2016-10-28 | Remote data copying method, storage device and storage system |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010780943.6A Pending CN112068992A (en) | 2016-10-28 | 2016-10-28 | Remote data copying method, storage device and storage system |
Country Status (2)
| Country | Link |
|---|---|
| CN (2) | CN106528338B (en) |
| WO (1) | WO2018076633A1 (en) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106528338B (en) * | 2016-10-28 | 2020-08-14 | 华为技术有限公司 | Remote data copying method, storage device and storage system |
| CN109164985B (en) * | 2018-08-27 | 2020-07-07 | 华为技术有限公司 | Method for copying data, master device and slave device |
| CN109491980A (en) * | 2018-11-02 | 2019-03-19 | 郑州云海信息技术有限公司 | A kind of remote replication method of file system, device, equipment and storage medium |
| CN109960613B (en) * | 2019-03-11 | 2023-05-12 | 中国银联股份有限公司 | Data batch processing method and device |
| CN112395135A (en) * | 2020-11-30 | 2021-02-23 | 福建安正智能科技有限公司 | Data backup method and device for computer room server |
| CN115277376B (en) * | 2022-09-29 | 2022-12-23 | 深圳华锐分布式技术股份有限公司 | Disaster recovery switching method, device, equipment and medium |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7624134B2 (en) * | 2006-06-12 | 2009-11-24 | International Business Machines Corporation | Enabling access to remote storage for use with a backup program |
| CN102799475A (en) * | 2012-06-29 | 2012-11-28 | 东南大学 | Multi-replication fault-tolerant parallel task scheduling method based on task replication |
| CN103617098A (en) * | 2013-12-03 | 2014-03-05 | 上海爱数软件有限公司 | Intelligent backup method and system based on data changes |
| CN105988901A (en) * | 2013-12-12 | 2016-10-05 | 华为技术有限公司 | Data copying method and storage system |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8548944B2 (en) * | 2010-07-15 | 2013-10-01 | Delphix Corp. | De-duplication based backup of file systems |
| CN104520802B (en) * | 2013-07-26 | 2017-04-19 | 华为技术有限公司 | Data sending method, data receiving method and storage device |
| WO2015010327A1 (en) * | 2013-07-26 | 2015-01-29 | 华为技术有限公司 | Data sending method, data receiving method and storage device |
| CN105550367A (en) * | 2015-06-30 | 2016-05-04 | 巫立斌 | Asynchronous remote copy method for memory |
| CN105404564A (en) * | 2015-12-16 | 2016-03-16 | 浪潮(北京)电子信息产业有限公司 | Data remote disaster tolerance method and apparatus |
| CN106528338B (en) * | 2016-10-28 | 2020-08-14 | 华为技术有限公司 | Remote data copying method, storage device and storage system |
-
2016
- 2016-10-28 CN CN201610971200.0A patent/CN106528338B/en active Active
- 2016-10-28 CN CN202010780943.6A patent/CN112068992A/en active Pending
-
2017
- 2017-04-21 WO PCT/CN2017/081341 patent/WO2018076633A1/en active Application Filing
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7624134B2 (en) * | 2006-06-12 | 2009-11-24 | International Business Machines Corporation | Enabling access to remote storage for use with a backup program |
| CN102799475A (en) * | 2012-06-29 | 2012-11-28 | 东南大学 | Multi-replication fault-tolerant parallel task scheduling method based on task replication |
| CN103617098A (en) * | 2013-12-03 | 2014-03-05 | 上海爱数软件有限公司 | Intelligent backup method and system based on data changes |
| CN105988901A (en) * | 2013-12-12 | 2016-10-05 | 华为技术有限公司 | Data copying method and storage system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112068992A (en) | 2020-12-11 |
| WO2018076633A1 (en) | 2018-05-03 |
| CN106528338A (en) | 2017-03-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11550675B2 (en) | Remote data replication method and system | |
| CN106528338B (en) | Remote data copying method, storage device and storage system | |
| US9703803B2 (en) | Replica identification and collision avoidance in file system replication | |
| US9996421B2 (en) | Data storage method, data storage apparatus, and storage device | |
| JP4741371B2 (en) | System, server apparatus, and snapshot format conversion method | |
| JP4615344B2 (en) | Data processing system and database management method | |
| JP5984151B2 (en) | Data recovery method, program, and data processing system | |
| JP4419884B2 (en) | Data replication apparatus, method, program, and storage system | |
| US20080320258A1 (en) | Snapshot reset method and apparatus | |
| CN106776147B (en) | Differential data backup method and differential data backup device | |
| US11030048B2 (en) | Method a source storage device to send a source file and a clone file of the source file to a backup storage device, a source storage device and a backup storage device | |
| US10437682B1 (en) | Efficient resource utilization for cross-site deduplication | |
| US10977143B2 (en) | Mirrored write ahead logs for data storage system | |
| US11442894B2 (en) | Methods for scalable file backup catalogs and devices thereof | |
| CN110825559A (en) | Data processing method and equipment | |
| JPWO2007099636A1 (en) | File system migration method, file system migration program, and file system migration apparatus | |
| JP2005215940A (en) | Storage system, server apparatus, and preceding copy data preparation method | |
| JP2017208113A (en) | Data storage method, data storage apparatus, and storage device | |
| JP2014059760A (en) | Storage device, control method of storage device, and control program of storage device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |