Disaster recovery drill method, device, equipment and medium

Abstract

The invention discloses a disaster recovery drill method, device, equipment and medium, and is applied to the technical field of storage, and the method comprises the steps: responding to a disaster recovery drill triggering operation, carrying out the preset operation of an object in a target bucket in a slave site, and forbidding the data synchronization between the slave site and a master site in an object storage multi-site architecture, the preset operation comprises a write operation and a deletion operation; an operation log corresponding to the object in the target bucket is recorded, and the operation log comprises an operation type; and in response to a disaster recovery triggering operation, entering a read-only state, traversing the operation log, determining an operation type corresponding to the operation log, and performing dirty data cleaning and data synchronization with the main site based on the operation type. In this way, the disaster recovery drill function is achieved in the object storage multi-site architecture, and the accuracy of data recovery is guaranteed.

Description

Technical Field

[0001] The present invention relates to the field of storage technology, and in particular to a disaster recovery drill method, device, equipment and medium. Background Art

[0002] A multi-site object storage architecture allows multiple geographically dispersed sites or data centers to jointly participate in data storage, management, and access. This architecture deploys object storage systems across multiple sites within a network and leverages high-speed network connections to synchronize and back up data between sites, providing high availability, data redundancy, and geographically distributed data access. Currently, multi-site object storage architectures generally utilize real-time, bidirectional synchronization mechanisms, resulting in a complete mirroring of data at the slave site with the primary site. This fails to meet the independent operational requirements for slave site data in disaster recovery drills.

[0003] Therefore, how to implement disaster recovery drill functions and ensure the accuracy of data recovery in an object storage multi-site architecture is a problem that technical personnel in this field need to solve. Summary of the Invention

[0004] In view of this, the present invention aims to provide a disaster recovery drill method, apparatus, device, and medium that can implement disaster recovery drill functions and ensure the accuracy of data recovery in an object storage multi-site architecture. The specific solution is as follows:

[0005] In a first aspect, the present invention provides a disaster recovery drill method, which is applied to a slave site in an object storage multi-site architecture, comprising:

[0006] In response to a disaster recovery drill triggering operation, performing a preset operation on an object in a target bucket at the slave site, and prohibiting data synchronization between the slave site and the master site in the object storage multi-site architecture, wherein the preset operation includes a write operation and a delete operation;

[0007] Recording an operation log corresponding to the object in the target bucket, wherein the operation log includes the operation type;

[0008] In response to a disaster recovery trigger operation, the system enters a read-only state, traverses the operation log, determines the operation type corresponding to the operation log, and performs dirty data cleaning and data synchronization with the primary site based on the operation type.

[0009] Optionally, traversing the operation log, determining the operation type corresponding to the operation log, and performing dirty data cleanup and data synchronization with the primary site based on the operation type include:

[0010] Obtain the multi-version status of the target bucket;

[0011] The operation log is traversed to determine the operation type corresponding to the operation log, and dirty data cleaning and data synchronization with the primary site are performed based on the multi-version status and the operation type.

[0012] Optionally, performing dirty data cleanup and data synchronization with the primary site based on the multi-version status and the operation type includes:

[0013] If the multi-version status is that multi-version is not enabled and the slave operation type is a write operation, the object corresponding to the operation log and the metadata of the object are obtained from the master site and written into the target bucket of the slave site. If the object corresponding to the operation log does not exist at the master site, the object in the slave site will be deleted.

[0014] Optionally, performing dirty data cleanup and data synchronization with the primary site based on the multi-version status and the operation type includes:

[0015] If the multi-version status is that multi-version is not enabled and the slave operation type is a deletion operation, the object corresponding to the operation log and the metadata of the object are obtained from the master site and written into the target bucket of the slave site. If the object corresponding to the operation log does not exist at the master site, the next operation log is processed.

[0016] Optionally, performing dirty data cleanup and data synchronization with the primary site based on the multi-version status and the operation type includes:

[0017] If the multi-version state is to enable multi-version, and the slave operation type is a write operation, then the object of the version corresponding to the write operation will be deleted from the site.

[0018] Optionally, performing dirty data cleanup and data synchronization with the primary site based on the multi-version status and the operation type includes:

[0019] If the multi-version status is enabled and the slave operation type is a delete operation of a specified version, the object of the specified version and its metadata are obtained from the master site, written to the target bucket of the slave site, and the last modification time of the object is updated to the last modification time of the object in the master site. If the object does not exist in the bucket of the master site, the object of the index version in the slave site is deleted;

[0020] If the multi-version status is to enable multi-version, and the slave operation type is a deletion operation with no specified version, the object corresponding to the operation log and the metadata of the object are obtained from the bucket of the master site and written into the target bucket of the slave site, the last modification time of the object is updated to the last modification time of the object in the master site, and the object with the deletion mark generated when the object is deleted from the slave site is deleted; if the object does not exist in the bucket of the master site, the object of the slave site and the object with the deletion mark generated when the object is deleted are deleted based on the version.

[0021] Optionally, enter read-only mode, including:

[0022] Intercept all write requests and return a write-forbidden response.

[0023] In a second aspect, the present invention provides a disaster recovery drill device, which is applied to a slave site in an object storage multi-site architecture, comprising:

[0024] A disaster recovery drill module is configured to, in response to a disaster recovery drill trigger operation, perform a preset operation on an object in a target bucket of a slave site, and prohibit data synchronization between the slave site and the master site in the object storage multi-site architecture, wherein the preset operation includes a write operation and a delete operation; and record an operation log corresponding to the object in the target bucket, wherein the operation log includes an operation type;

[0025] The disaster recovery module is used to enter a read-only state in response to a disaster recovery trigger operation, traverse the operation log, determine the operation type corresponding to the operation log, clean up dirty data based on the operation type, and synchronize data with the primary site.

[0026] In a third aspect, the present invention provides an electronic device, comprising:

[0027] memory for storing computer programs;

[0028] A processor is used to execute the computer program to implement the steps of the aforementioned disaster recovery drill method.

[0029] In a fourth aspect, the present invention provides a computer-readable storage medium having a computer program stored thereon, which implements the steps of the aforementioned disaster recovery drill method when executed by a processor.

[0030] In a fifth aspect, the present invention provides a computer program product, comprising a computer program / instruction, which implements the steps of the aforementioned disaster recovery drill method when executed by a processor.

[0031] It can be seen from the above scheme that the present invention provides a disaster recovery drill method, which is applied to the slave site in the object storage multi-site architecture, including: in response to the disaster recovery drill trigger operation, performing preset operations on the objects in the target bucket in the slave site, and prohibiting data synchronization between the slave site and the master site in the object storage multi-site architecture, wherein the preset operations include write operations and delete operations; recording the operation log corresponding to the objects in the target bucket, wherein the operation log includes the operation type; in response to the disaster recovery trigger operation, entering the read-only state, and traversing the operation log, determining the operation type corresponding to the operation log, and performing dirty data cleaning and data synchronization with the master site based on the operation type.

[0032] It can be seen that the beneficial effect of the present invention is that: during the disaster recovery drill, data synchronization between the slave site and the master site in the object storage multi-site architecture is prohibited, the data between the slave site and the master site is isolated, and based on the operation log of the object in the bucket in the slave site, when data recovery is performed, dirty data is cleaned up based on the slave operation log and according to the operation type, and data synchronization with the master site is performed. In this way, the disaster recovery drill function is realized in the object storage multi-site architecture, and the accuracy of data recovery is guaranteed.

[0033] Correspondingly, the disaster recovery drill device, equipment and medium provided by the present invention also have the above technical effects. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] In order to more clearly illustrate the embodiments of the present invention, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0035] Figure 1 A flow chart of a disaster recovery drill method provided by an embodiment of the present invention;

[0036] Figure 2 A flow chart of a specific disaster recovery drill method provided by an embodiment of the present invention;

[0037] Figure 3 A schematic diagram of the structure of a disaster recovery drill device provided by an embodiment of the present invention;

[0038] Figure 4 A structural diagram of an electronic device provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0039] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making any creative efforts shall fall within the scope of protection of the present invention.

[0040] The terms "including" and "having," as used in the present description and accompanying drawings, and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or elements is not limited to the listed steps or elements and may include steps or elements that are not listed.

[0041] Currently, multi-site object storage architectures generally utilize real-time, two-way synchronization mechanisms, resulting in a complete mirroring of slave site data with the primary site. This fails to meet the independent data operation requirements required in disaster recovery drills. For example, the industry standard AWS S3 Cross-Region Replication (CRR) only supports one-way asynchronous replication and lacks a mechanism for isolating data during drills. After the drill, manual intervention is required to restore the synchronization link, which can easily lead to data recovery errors or omissions due to human intervention errors. Traditional multi-site functionality is no longer able to meet the emerging disaster recovery drill needs in the market, and there is an urgent need to implement disaster recovery drill functionality.

[0042] In order to solve the above problems, explore new users and expand new businesses, thereby improving product competitiveness and market share, the invention of multi-site support for disaster recovery drills was specially proposed.

[0043] In order to enable those skilled in the art to better understand the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0044] Next, a disaster recovery drill method provided by an embodiment of the present invention is described in detail. Figure 1 A flow chart of a disaster recovery drill method provided in an embodiment of the present invention is applied to a slave site in an object storage multi-site architecture. The disaster recovery drill method includes:

[0045] Step S11: In response to the disaster recovery drill triggering operation, a preset operation is performed on the objects in the target bucket in the slave site, and data synchronization between the slave site and the master site in the object storage multi-site architecture is prohibited, wherein the preset operation includes a write operation and a delete operation.

[0046] Preset operations can include new uploads, overwrites, appends, deletions, and object metadata modifications. These operations can be categorized as write and delete operations. Target buckets can include those with and / or without multi-versioning enabled. Furthermore, during a disaster recovery drill, write or delete operations from the slave site are not recorded in the binlog (i.e., binary log). Consequently, newly written / deleted data from the slave site during the drill is not synchronized between sites. Disaster recovery drill triggers can be triggered by the user through a graphical interface.

[0047] Step S12: Record the operation log corresponding to the object in the target bucket, wherein the operation log includes the operation type.

[0048] It is understandable that recording the operation log corresponding to the object in the target bucket may occur as a preset operation is performed on the object in the target bucket in the slave site. Performing a preset operation may generate an operation log.

[0049] In an embodiment of the present invention, in response to a disaster recovery drill trigger operation, a disaster recovery drill flag can be added to the metadata of all current buckets of the slave site. The flag indicates that additional operation logs of objects in the bucket need to be recorded, and the operation logs corresponding to the objects in the target bucket are recorded based on the disaster recovery drill flag.

[0050] Furthermore, in this embodiment of the present invention, operation logs from the most recent preset period are not compressed, but historical operation logs are compressed to reduce log space usage. Historical operation logs are operation logs from periods other than the most recent preset period. For example, the most recent preset period is the current day.

[0051] Step S13: In response to the disaster recovery trigger operation, enter the read-only state, traverse the operation log, determine the operation type corresponding to the operation log, and perform dirty data cleaning and data synchronization with the primary site based on the operation type.

[0052] In the embodiment of the present invention, the disaster recovery trigger operation can be triggered by the user based on the graphical interactive interface. The system enters the read-only state, intercepts all write requests, and returns a write-forbidden response message to prompt the user that write is currently prohibited.

[0053] The embodiment of the present invention can obtain the multi-version status of the target bucket; traverse the operation log, determine the operation type corresponding to the operation log, and clean up dirty data and synchronize data with the master site based on the multi-version status and the operation type.

[0054] The embodiment of the present invention can process each bucket shard in sequence, listing the operation logs on the bucket shard, listing a preset number of logs each time, recording the end point of the listing, and continuing to list from the end point until all the operation logs on the shard are listed. Each time an operation log is listed, the operation type corresponding to the operation log is obtained and recovery processing is performed. In addition, when synchronously writing data to the slave site, the written data is checked for consistency.

[0055] In an optional embodiment, if the multi-version status is that multi-version is not enabled and the slave operation type is a write operation, the object corresponding to the operation log and the metadata of the object are obtained from the master site and written into the target bucket of the slave site. If the object corresponding to the operation log does not exist at the master site, the object in the slave site will be deleted.

[0056] Moreover, in an optional embodiment, the embodiment of the present invention can calculate the check value corresponding to the object corresponding to the operation log and the metadata of the object, and write the check value together with the object corresponding to the operation log and the metadata of the object into the target bucket of the slave site. After the writing is completed, the check value, the object corresponding to the operation log and the metadata of the object can be read from the target bucket of the site, and the check value can be recalculated based on the object corresponding to the read operation log and the metadata of the object. The calculated check value and the read check value are compared. If they are consistent, it indicates that the check has passed, otherwise it indicates that the check has failed. That is, in the embodiment of the present invention, a consistency check is performed when the data is written to ensure the accuracy of data writing.

[0057] During a disaster recovery drill, the data corresponding to a write operation may be dirty and need to be deleted. This embodiment of the present invention first obtains the object corresponding to the operation log in the master site and its metadata, and writes them to the target bucket of the slave site. This ensures data synchronization during the drill when the corresponding object is written to the master site. If the object corresponding to the operation log does not exist at the master site, the object is deleted from the slave site, achieving master-slave synchronization. Furthermore, a double hash check using CRC32+MurmurHash can be used to ensure data write consistency.

[0058] In an optional implementation, if the multi-version status is that multi-version is not enabled and the slave operation type is a deletion operation, the object corresponding to the operation log and the metadata of the object are obtained from the master site and written into the target bucket of the slave site. If the object corresponding to the operation log does not exist at the master site, the next operation log is processed.

[0059] During the disaster recovery drill, data deleted from the slave site needs to be restored from the primary site to avoid inconsistency between the master and slave data. If the primary site is also deleted, no further synchronization is required.

[0060] In an optional embodiment, if the multi-version state is enabled and the slave operation type is a write operation, the object of that version will be deleted from the site based on the version corresponding to the write operation. That is, if it is a write operation, the object will be deleted directly based on the specified version.

[0061] In an optional embodiment, if the multi-version status is multi-version enabled, and the slave operation type is a deletion operation of a specified version, the object of the specified version and the metadata of the object are obtained from the master site and written into the target bucket of the slave site, and the last modification time of the object is updated to the last modification time of the object in the master site. If the object does not exist in the bucket of the master site, the object of the indicator version in the slave site is deleted; if the multi-version status is multi-version enabled, and the slave operation type is a deletion operation of an unspecified version, the object corresponding to the operation log and the metadata of the object are obtained from the bucket of the master site, and written into the target bucket of the slave site, and the last modification time of the object is updated to the last modification time of the object in the master site, and the object of the deletion mark generated when the object is deleted from the slave site is deleted; if the object does not exist in the bucket of the master site, the object of the slave site and the object of the deletion mark generated when the object is deleted are deleted based on the version.

[0062] It should be noted that if it is a deletion operation and the deletion is for a specified version (no deletion version object is generated), the version object and its object metadata are obtained from the bucket of the master site and written to the bucket of the slave site. At the same time, the object's last modification time is updated to the last modification time of the master site object. The object's version ID (i.e., identifier) ​​remains consistent with the master site, and data consistency is ensured through CRC32+MurmurHash double hash check. If the object does not exist in the bucket of the master site, the specified version is deleted from the slave site.

[0063] If the deletion is from a non-specified version (a deleted version object is generated), the version object and its object metadata are obtained from the bucket of the master site and written to the bucket of the slave site. At the same time, the object's last modification time is updated to the last modification time of the master site object. The object's version ID is consistent with the master site, and data consistency is guaranteed by CRC32+MurmurHash double hash check. At the same time, the deletion marker object generated when deleting this object from the slave site is deleted. If the object does not exist in the bucket of the master site, the specified version deletes the object from the slave site and the deleted marker object generated when deleting the object. Non-specified versions delete the latest version of an object. When deleting, the latest version of the object is not deleted, but a deletion marker object is generated.

[0064] In this embodiment of the present invention, data synchronization refers to data synchronization of objects within a bucket. The primary site, or main site, supports creating S3 users, buckets, and uploading objects. The secondary site, or backup site, does not support creating S3 users or buckets, but supports uploading objects. Disaster recovery drills are conducted on the secondary site. Disaster recovery recovery involves restoring the secondary site's data after the drill to synchronize it with the primary site. mtime, or modification time, refers to the last time a file's content or metadata was modified, also known as the most recently modified time.

[0065] It can be seen that in the embodiment of the present invention, during the disaster recovery drill, data synchronization between the slave site and the master site in the object storage multi-site architecture is prohibited, the data between the slave site and the master site is isolated, and based on the operation log of the object in the bucket in the slave site, when data recovery is performed, dirty data is cleaned up based on the slave operation log and according to the operation type, and data synchronization with the master site is performed. In this way, the disaster recovery drill function is realized in the object storage multi-site architecture, and the accuracy of data recovery is guaranteed.

[0066] Furthermore, the disaster recovery drill method provided by the embodiment of the present invention is described. Based on the original distributed object storage multi-site, the function of multi-site disaster recovery drill is added. That is, the user can conduct a drill on the slave site. During the drill, the data synchronization between the sites is stopped with the master site to achieve the data isolation effect. After the drill is completed, the data of the slave site is restored to the state before the drill, which solves the problem that the multi-site does not support the disaster recovery drill function. Through this invention, users with disaster recovery drill needs can be satisfied, thereby increasing market share and product competitiveness, and significantly improving customer satisfaction. The following steps may be included:

[0067] Build a multi-site environment with a master site and a slave site; create an s3 user s3user1 on the master site; on the master site, create buckets bucket1 and bucket2 under s3 user s3user1, with bucket bucket1 not enabling multi-versioning and bucket bucket2 enabling it; on the master site, upload objects object1 to object100 to bucket bucket1, and upload, overwrite, and delete objects to bucket bucket2 multiple times; after the data on the master site has been synchronized to the slave site, the master site still maintains continuous read and write services. Click Start Disaster Recovery Drill on the slave site, and the storage system will prompt "Disaster Recovery Drill Start, Multi-site Data Synchronization Will Be Paused, and the Multi-version Status of the Master and Slave Site Buckets Does Not Support Modification." Click OK to enter disaster recovery drill mode. At this point, the data on the master site is no longer synchronized to the slave site, and the multi-version status of the master and slave site buckets does not support modification.

[0068] All data modifications during the disaster recovery drill at the slave site are recorded in the operation log of the bucket shard: After entering the disaster recovery drill state, the metadata of all current buckets at the slave site is marked with a disaster recovery drill flag, which indicates that additional operation logs need to be recorded for the objects in the bucket. Data written or deleted from the slave site during the drill is not recorded in the binlog. The effect is that newly written / deleted data during the slave site drill does not participate in data synchronization between sites. When new uploads, overwrites, appends, deletions, or metadata modifications are performed on data in buckets bucket1 and bucket2 on the slave site, the storage system automatically records the operation logs. The logs for the current day are not compressed, but historical operation logs are compressed to reduce log space usage.

[0069] After the drill at the slave site is complete, perform disaster recovery on the slave site: Click Disaster Recovery on the slave site. The system prompts "Entering the dirty data cleanup phase. This cluster is read-only during the cleanup period." A task is generated to display the progress of the dirty data cleanup. During the disaster recovery period, the slave site intercepts all write requests and returns an HTTP 405 Method Not Allowed response.

[0070] For dirty data cleanup, if multi-versioning is not enabled on a bucket, the following steps are performed: retrieve the bucket metadata from the slave site, obtain the number of bucket shards, and determine the bucket's multi-versioning status. A for loop processes each bucket shard, listing the operation logs for that shard, 1000 at a time. A marker is recorded (i.e., the end of each listing). The next listing continues from the marker until all operation logs for that shard are complete. A for loop processes each operation log entry and determines the operation log type. If the operation is a write operation, the object and its metadata are retrieved from the master bucket and written to the slave bucket. Data consistency is ensured using a CRC32+MurmurHash double check. If the object does not exist in the master bucket, the object is directly deleted from the slave bucket. If the operation is a del operation, the object and its metadata are retrieved from the master bucket and written to the slave bucket. If the object does not exist in the master bucket, the operation log is skipped. After processing all logs, the operation logs are deleted in batches.

[0071] For dirty data cleanup, if multi-versioning is enabled on a bucket, the following steps are performed: retrieve the bucket metadata from the slave site, obtain the number of bucket shards, and determine the multi-version status of the bucket. A for loop processes each bucket shard, listing the operation logs for that shard 1000 times at a time, recording a marker, and continuing to list from the marker until all operation logs for that shard are listed. The for loop processes each operation log entry and retrieves the operation log type. If the value is "write," the object is directly deleted using the specified version. If the value is "del," and the version is deleted (no deleted version object is generated), the object and its metadata are retrieved from the master bucket and written to the slave bucket. The object's mtime (last modified time) is updated to match the master's object's mtime, and the version ID is kept consistent with the master. A CRC32+MurmurHash double hash check is used to ensure data consistency. If the object does not exist in the master bucket, the specified version is deleted from the slave. If the deletion is a del and not a specific version (generating a deleted version object), the version object and its metadata are retrieved from the master's bucket and written to the slave's bucket. The object's mtime is updated to match the master's mtime, and the version ID is kept consistent with the master. A CRC32+MurmurHash double hash check is used to ensure data consistency. The object marked "deleted" generated when deleting the object from the slave is also deleted. If the object does not exist in the master's bucket, the object and the deleted object generated when deleting the object are deleted from the slave using the specified version. After processing all logs in this batch, the operation logs are deleted in batches.

[0072] After all operation logs are processed and the task progress is 100%, the system prompts "Dirty data cleanup completed", and the cluster returns to normal read-write status, and the bucket multi-version of the master site and the slave site returns to the editable status. The user can choose to continue the drill or stop the disaster recovery drill. If the user chooses to continue the drill, a new round of drills will begin; if the user chooses to stop the disaster recovery drill, multi-site synchronization will be restored. Figure 2 As shown, Figure 2 A flowchart of a specific disaster recovery drill method provided by an embodiment of the present invention.

[0073] Based on the existing distributed object storage multi-site, the present invention adds the function of multi-site support for disaster recovery drills. That is, users can conduct disaster recovery drills on the slave site, and after the drill is completed, dirty data cleaning and data recovery can be automatically performed. After the slave site completes data recovery, it automatically recovers to the master-slave site synchronization state. It implements a data isolation mechanism during the drill, automatically performs dirty data cleaning, and disaster recovery drills are compatible with multiple versions. Through this invention, it supports full-process management of independent drills from the slave site + automatic dirty data cleaning, breaking the limitation of only supporting one-way replication. It can meet the needs of users with disaster recovery drill needs and improve market share and product competitiveness.

[0074] See also Figure 3 As shown, Figure 3 A schematic diagram of the structure of a disaster recovery drill device provided in an embodiment of the present invention, wherein the disaster recovery drill device is applied to a slave site in an object storage multi-site architecture, including:

[0075] A disaster recovery drill module 31 is configured to, in response to a disaster recovery drill trigger operation, perform a preset operation on an object in a target bucket at a slave site, and prohibit data synchronization between the slave site and the master site in the object storage multi-site architecture, wherein the preset operation includes a write operation and a delete operation; and record an operation log corresponding to the object in the target bucket, wherein the operation log includes an operation type;

[0076] The disaster recovery module 32 is used to enter a read-only state in response to a disaster recovery trigger operation, traverse the operation log, determine the operation type corresponding to the operation log, clean up dirty data based on the operation type, and synchronize data with the primary site.

[0077] In an optional embodiment, the disaster recovery module 32 may include:

[0078] A version status acquisition submodule, used to obtain the multi-version status of the target bucket;

[0079] The data recovery submodule is configured to traverse the operation log, determine the operation type corresponding to the operation log, clean up dirty data based on the multi-version status and the operation type, and synchronize data with the primary site.

[0080] In an optional embodiment, the data recovery submodule can be specifically used to obtain the object corresponding to the operation log and the metadata of the object from the master site if the multi-version status is that multi-version is not enabled and the slave operation type is a write operation, and write them into the target bucket of the slave site. If the object corresponding to the operation log does not exist at the master site, the object in the slave site will be deleted.

[0081] In an optional embodiment, the data recovery submodule can be specifically used to obtain the object corresponding to the operation log and the metadata of the object from the master site if the multi-version status is that multi-version is not enabled and the slave operation type is a deletion operation, and write them into the target bucket of the slave site. If the object corresponding to the operation log does not exist at the master site, the next operation log is processed.

[0082] In an optional implementation, the data recovery submodule may be specifically configured to delete the object of the version corresponding to the write operation from the site if the multi-version state is to enable multi-version and the slave operation type is a write operation.

[0083] In an optional embodiment, the data recovery submodule can be specifically used to obtain the object of the specified version and the metadata of the object from the master site if the multi-version status is multi-version enabled and the slave operation type is a deletion operation of a specified version, write the object into the target bucket of the slave site, update the last modification time of the object to the last modification time of the object in the master site, and delete the object of the indicator version in the slave site if the object does not exist in the bucket of the master site; if the multi-version status is multi-version enabled and the slave operation type is a deletion operation of an unspecified version, obtain the object corresponding to the operation log and the metadata of the object from the bucket of the master site, write the object into the target bucket of the slave site, update the last modification time of the object to the last modification time of the object in the master site, and delete the object of the deletion mark generated when the slave site is deleted; if the object does not exist in the bucket of the master site, delete the object of the slave site and the object of the deletion mark generated when the object is deleted based on the version.

[0084] In an optional implementation, the disaster recovery module 32 may be specifically configured to intercept all write requests and return a write-prohibited response message.

[0085] It can be seen that in the embodiment of the present invention, during the disaster recovery drill, data synchronization between the slave site and the master site in the object storage multi-site architecture is prohibited, the data between the slave site and the master site is isolated, and based on the operation log of the object in the bucket in the slave site, when data recovery is performed, dirty data is cleaned up based on the slave operation log and according to the operation type, and data synchronization with the master site is performed. In this way, the disaster recovery drill function is realized in the object storage multi-site architecture, and the accuracy of data recovery is guaranteed.

[0086] Figure 3 The description of the features in the corresponding embodiment can be found in Figure 1 The relevant descriptions of the corresponding embodiments will not be repeated here one by one.

[0087] Figure 4A structural diagram of an electronic device provided by an embodiment of the present invention, such as Figure 4 As shown, the electronic device includes: a memory 40 for storing computer programs;

[0088] The processor 41 is configured to implement the steps of the disaster recovery drill method in the above embodiment when executing a computer program.

[0089] Processor 41 may include one or more processing cores, such as a quad-core processor or an octa-core processor. Processor 41 may be implemented using at least one of the following hardware forms: digital signal processing (DSP), field-programmable gate array (FPGA), and programmable logic array (PLA). Processor 41 may also include a main processor and a coprocessor. The main processor is a processor for processing data in the awake state, also known as a central processing unit (CPU); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, processor 41 may be integrated with a graphics processing unit (GPU), which is responsible for rendering and drawing content required to be displayed on the display screen. In some embodiments, processor 41 may also include an artificial intelligence (AI) processor, which is responsible for processing computing operations related to machine learning.

[0090] The memory 40 may include one or more computer-readable storage media, which may be non-transitory. The memory 40 may also include a high-speed random access memory, and a non-volatile memory, such as one or more disk storage devices, flash memory storage devices. In this embodiment, the memory 40 is at least used to store the following computer program 401, wherein, after the computer program is loaded and executed by the processor 41, it can implement the relevant steps of the disaster recovery drill method disclosed in any of the aforementioned embodiments. In addition, the resources stored in the memory 40 may also include an operating system 402 and data 403, etc., and the storage method may be temporary storage or permanent storage. Among them, the operating system 402 may include Windows, Unix, Linux, etc. The data 403 may include but is not limited to configuration data, etc.

[0091] In some embodiments, the electronic device may further include a display screen 42 , an input / output interface 43 , a communication interface 44 , a power supply 45 , and a communication bus 46 .

[0092] Those skilled in the art will understand that Figure 4 The structure shown in the figure does not constitute a limitation of the electronic device, and may include more or fewer components than shown in the figure.

[0093] It is understandable that if the disaster recovery drill method in the above embodiment is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the current technology, or all or part of the technical solution can be embodied in the form of a software product. This computer software product is stored in a storage medium and performs all or part of the steps of the methods of each embodiment of the present invention. The aforementioned storage medium includes: USB flash drive, mobile hard disk, read-only memory (ROM), random access memory (RAM), electrically erasable programmable ROM, register, hard disk, removable disk, CD-ROM, magnetic disk or optical disk, etc. Various media that can store program code.

[0094] Based on this, an embodiment of the present invention further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the above-mentioned disaster recovery drill method are implemented.

[0095] A computer program product provided by an embodiment of the present invention is introduced below. The computer program product described below can be referenced with other embodiments described herein.

[0096] A computer program product includes a computer program / instruction, which implements the steps of the aforementioned disaster recovery drill method when executed by a processor.

[0097] The above describes in detail the disaster recovery drill method, apparatus, device, and medium provided in the embodiments of the present invention. The various embodiments are described in a progressive manner throughout this specification, with each embodiment focusing on its differences from the other embodiments. Similar or identical parts between the various embodiments can be referenced for reference only. The apparatus disclosed in the embodiments corresponds to the method disclosed in the embodiments, so the description is relatively brief. For relevant details, refer to the method description.

[0098] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present invention.

[0099] The above is a detailed introduction to the disaster recovery drill method, device, equipment and medium provided by the present invention. Specific examples are used herein to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present invention, the present invention can also be improved and modified in several ways, and these improvements and modifications also fall within the scope of protection of the present invention.

Claims

1. A disaster recovery drill method, characterized in that: Applicable to slave sites in a multi-site object storage architecture, including: In response to a disaster recovery drill triggering operation, performing a preset operation on an object in a target bucket at the slave site, and prohibiting data synchronization between the slave site and the master site in the object storage multi-site architecture, wherein the preset operation includes a write operation and a delete operation; Recording an operation log corresponding to the object in the target bucket, wherein the operation log includes the operation type; In response to a disaster recovery trigger operation, the system enters a read-only state, traverses the operation log, determines the operation type corresponding to the operation log, and performs dirty data cleaning and data synchronization with the primary site based on the operation type.

2. The disaster recovery drill method according to claim 1, characterized in that: Traversing the operation log, determining the operation type corresponding to the operation log, and performing dirty data cleanup and data synchronization with the primary site based on the operation type, including: Obtain the multi-version status of the target bucket; The operation log is traversed to determine the operation type corresponding to the operation log, and dirty data cleaning and data synchronization with the primary site are performed based on the multi-version status and the operation type.

3. The disaster recovery drill method according to claim 2, characterized in that: Cleaning dirty data and synchronizing data with the primary site based on the multi-version state and the operation type includes: If the multi-version status is that multi-version is not enabled and the slave operation type is a write operation, the object corresponding to the operation log and the metadata of the object are obtained from the master site and written into the target bucket of the slave site. If the object corresponding to the operation log does not exist at the master site, the object in the slave site will be deleted.

4. The disaster recovery drill method according to claim 2, characterized in that: Cleaning dirty data and synchronizing data with the primary site based on the multi-version state and the operation type includes: If the multi-version status is that multi-version is not enabled and the slave operation type is a deletion operation, the object corresponding to the operation log and the metadata of the object are obtained from the master site and written into the target bucket of the slave site. If the object corresponding to the operation log does not exist at the master site, the next operation log is processed.

5. The disaster recovery drill method according to claim 2, characterized in that: Cleaning dirty data and synchronizing data with the primary site based on the multi-version state and the operation type includes: If the multi-version state is to enable multi-version, and the slave operation type is a write operation, then the object of the version corresponding to the write operation will be deleted from the site.

6. The disaster recovery drill method according to claim 2, characterized in that: Cleaning dirty data and synchronizing data with the primary site based on the multi-version state and the operation type includes: If the multi-version status is enabled and the slave operation type is a delete operation of a specified version, the object of the specified version and its metadata are obtained from the master site, written to the target bucket of the slave site, and the last modification time of the object is updated to the last modification time of the object in the master site. If the object does not exist in the bucket of the master site, the object of the index version in the slave site is deleted; If the multi-version status is to enable multi-version, and the slave operation type is a deletion operation with no specified version, the object corresponding to the operation log and the metadata of the object are obtained from the bucket of the master site and written into the target bucket of the slave site, the last modification time of the object is updated to the last modification time of the object in the master site, and the object with the deletion mark generated when the object is deleted from the slave site is deleted; if the object does not exist in the bucket of the master site, the object of the slave site and the object with the deletion mark generated when the object is deleted are deleted based on the version.

7. The disaster recovery drill method according to any one of claims 1 to 6, characterized in that: Enter read-only mode, including: Intercept all write requests and return a write-forbidden response.

8. A disaster recovery drill device, characterized in that: Applicable to slave sites in a multi-site object storage architecture, including: A disaster recovery drill module is configured to, in response to a disaster recovery drill trigger operation, perform a preset operation on an object in a target bucket of a slave site, and prohibit data synchronization between the slave site and the master site in the object storage multi-site architecture, wherein the preset operation includes a write operation and a delete operation; and record an operation log corresponding to the object in the target bucket, wherein the operation log includes an operation type; The disaster recovery module is used to enter a read-only state in response to a disaster recovery trigger operation, traverse the operation log, determine the operation type corresponding to the operation log, clean up dirty data based on the operation type, and synchronize data with the primary site.

9. An electronic device, characterized in that: include: memory for storing computer programs; A processor is used to execute the computer program to implement the steps of the disaster recovery drill method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the disaster recovery drill method according to any one of claims 1 to 7.

Images