Disaster recovery method, device, site, and storage medium

Abstract

Embodiments of the present application relate to the field of communication and information, and disclose a disaster recovery method, device, local site and storage medium. In the present application, the disaster recovery method comprises: if it is determined that the identity of the local site is a backup local site, detecting whether there is a target local site satisfying a preset condition; the preset condition comprises: the identity of the target local site is a main local site, and the target local site is assigned to the local site and has not established a disaster recovery relationship with the local site; if there is a target local site satisfying the preset condition, establishing a disaster recovery relationship with the target local site; and backing up data to be backed up in the target local site for the target local site. The flexibility of business expansion can be improved.

Description

TECHNICAL FIELD

[0001] The embodiment of the present application relates to the field of communication and information, in particular to a disaster recovery method, device, local point and storage medium. BACKGROUND

[0002] With the management capability of the telecommunication system expanding and the data information quantity also growing explosively, the high availability of the corresponding system and the disaster recovery of the data are particularly important. As an effective architecture form of system capability expansion, the distributed system is widely applied to the telecommunication system in the form of deploying the application in the micro-service and the container on the platform as a service (PaaS).

[0003] At present, the disaster recovery relationship in the system disaster recovery scheme is mainly one-to-one correspondence, that is, one standby local point can only backup one main local point. If a main local point is added, a new standby local point needs to be newly built to backup the data produced by the newly added main local point, so that the business expansion is not flexible enough. SUMMARY

[0004] The embodiment of the present application aims to provide a disaster recovery method, device, local point and storage medium, the standby local point actively establishes the disaster recovery relationship with the main local point, which can avoid the situation that the original business is interrupted due to the expansion of the business in the running process when the main local point actively establishes the disaster recovery relationship with the standby local point, and improve the flexibility of the business expansion.

[0005] To solve the above technical problems, the embodiment of the present application provides a disaster recovery method, comprising: if it is determined that the identity of the local point is a standby local point, detecting whether there is a target local point meeting a preset condition; the preset condition comprises: the identity of the target local point is a main local point, and the target local point is assigned to the local point and has not established a disaster recovery relationship with the local point; if there is a target local point meeting the preset condition, establishing a disaster recovery relationship with the target local point; and backing up the data to be backed up in the target local point for the target local point.

[0006] The embodiment of the present application further provides a disaster recovery device, comprising: a comprehensive service module, a message middleware and an application embedded with a data backup module; the comprehensive service module is used for detecting whether there is a target local point meeting a preset condition when it is determined that the identity of the local point is a standby local point, the preset condition comprising: the identity of the target local point is a main local point, and the target local point is assigned to the local point and has not established a disaster recovery relationship with the local point; and the comprehensive service module is further used for establishing a disaster recovery relationship with the target local point meeting the preset condition; the message middleware is used for storing the identity information of the local point from the comprehensive service module; and the data backup module in the application is used for listening to the identity information of the local point in the message middleware, and backing up the data to be backed up in the target local point for the target local point according to the identity information of the local point after the local point establishes a disaster recovery relationship with the target local point.

[0007] The embodiment of the present application further provides a local site, comprising: at least one processor; and a memory connected with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the disaster recovery method.

[0008] The embodiment of the present application further provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the disaster recovery method.

[0009] Compared with the prior art, the backup local site actively detects the active local sites assigned to the local site and not yet established a disaster recovery relationship with the local site, and actively requests to establish a disaster recovery relationship, so that the backup local site can establish a disaster recovery relationship with multiple active local sites, and the problem of relatively rigid disaster recovery architecture when the disaster recovery relationship is one-to-one is solved. Moreover, the active local site does not need to care about the state of the backup local site, and the flexibility of business expansion is improved.

[0010] In addition, the establishment of the disaster recovery relationship with the active local site comprises: sending a connection request to the target local site, and confirming that the disaster recovery relationship is successfully established after receiving a response of allowing connection from the target local site. The backup local site initiates the connection actively, so that the active local site does not need to know the corresponding backup local site, and the work burden of the active local site in the process of establishing the disaster recovery relationship is reduced.

[0011] In addition, the detection of whether there is the target local site satisfying the preset condition comprises: scanning a pre-stored active local site list; the active local site list comprises all active local sites assigned to the local site; detecting the current state of each active local site in the active local site list, and determining the active local site whose current state is not yet established a disaster recovery relationship with the local site as the target local site satisfying the preset condition. The active local site list is pre-stored in the backup local site, the active local site not yet establishing a disaster recovery relationship is scanned in the table, and a specific detection manner is provided, so that the backup local site establishes a disaster recovery relationship with only the active local site satisfying the preset condition.

[0012] In addition, the backup of the data to be backed up in the target local site for the target local site comprises: pulling the data to be backed up from a storage area of the target local site for the backup local site to access. The backup local site actively pulls the data to be backed up from the active local site having established a disaster recovery relationship, so that the active local site does not need to assign the data to the corresponding backup local site, and the work burden of the active local site in the process of backing up the data is reduced.

[0013] In addition, the data to be backed up is bound with identity information of the target site; and the data to be backed up in the target site is backed up for the target site, including: storing the data to be backed up in a storage area corresponding to the target site according to the identity information. The identity information can be used to know the source of the obtained data to be backed up, and all the obtained data to be backed up can be distinguished according to the identity information, so that the obtained data to be backed up can be stored and managed. In addition, the identity information is unique, so that the source of the obtained data to be backed up is reliable.

[0014] In addition, after the disaster recovery relationship with the target site is established, the method further includes: if it is detected that the identity of the local site and the target site is interchanged, sending a response allowing connection to the target site when a connection request of the target site is received. The embodiment provides a processing mode after the primary and backup identities are interchanged.

[0015] In addition, after the disaster recovery relationship with the target site is established, the method further includes: if it is detected that the identity of the local site and the target site is interchanged, sending a response allowing connection to the target site when a connection request of the target site is received. The embodiment provides a processing mode after the primary and backup identities are interchanged.

[0016] In addition, after the disaster recovery relationship with the target site is established, the method further includes: if it is detected that the identity of the local site and the target site is interchanged, sending a response allowing connection to the target site when a connection request of the target site is received. The embodiment provides a processing mode after the primary and backup identities are interchanged.

[0017] In addition, the data to be backed up is bound with identity information of the target site; and the data to be backed up in the target site is backed up for the target site, including: storing the data to be backed up in a storage area corresponding to the target site according to the identity information. The identity information can be used to know the source of the obtained data to be backed up, and all the obtained data to be backed up can be distinguished according to the identity information, so that the obtained data to be backed up can be stored and managed. In addition, the identity information is unique, so that the source of the obtained data to be backed up is reliable. BRIEF DESCRIPTION OF DRAWINGS

[0018] One or more embodiments are illustrated by way of example in the figures that are part of this document and which illustrate key principles of the embodiments. The purpose and objects of the embodiments will be more readily understood from the following written description, and the appended drawings, in which like reference numerals refer to like elements throughout and in which:

[0019] Figure 1 is a structural schematic diagram of a 2+2 type disaster recovery architecture in the first embodiment of the application;

[0020] Figure 2 is a flowchart of a disaster recovery method in the first embodiment of the application;

[0021] Figure 3is a schematic diagram of a disaster recovery relationship of a 2+2 type disaster tolerance architecture in the first embodiment of the present application;

[0022] Figure 4 is a schematic diagram of a disaster recovery relationship of a 3+2 type disaster tolerance architecture in the first embodiment of the present application;

[0023] Figure 5 is a schematic diagram of a disaster recovery relationship of a 3+3 type disaster tolerance architecture in the first embodiment of the present application;

[0024] Figure 6 is a flow chart of a disaster tolerance method in the second embodiment of the present application;

[0025] Figure 7 is a flow chart of a disaster tolerance method in the third embodiment of the present application;

[0026] Figure 8 is a flow chart of a disaster tolerance method in the fourth embodiment of the present application;

[0027] Figure 9 is a flow chart of a disaster tolerance method in the fifth embodiment of the present application;

[0028] Figure 10 is a schematic diagram of a structure of a disaster tolerance device in the sixth embodiment of the present application;

[0029] Figure 11 is a schematic diagram of a disaster recovery relationship establishment of a 2+2 type disaster tolerance architecture in the sixth embodiment of the present application;

[0030] Figure 12 is a schematic diagram of backup data of a 2+2 type disaster tolerance architecture in the sixth embodiment of the present application;

[0031] Figure 13 is a schematic diagram of a structure of a local site in the seventh embodiment of the present application. DETAILED DESCRIPTION

[0032] In order to make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the embodiments of the present application will be described in detail below with reference to the drawings. However, those skilled in the art can understand that, in the embodiments of the present application, many technical details are presented in order to make the readers better understand the present application. However, the technical solutions claimed by the present application can be implemented even without these technical details and based on various changes and modifications of the following embodiments. The division of the following embodiments is for the convenience of description, and should not constitute any limitation on the specific implementation of the present application, and the embodiments can be combined and referenced with each other on the premise of no contradiction.

[0033] The inventor finds that although a new backup site is built to backup the data produced by the newly added primary site, the disaster recovery purpose can be achieved, but the resource demand is large, and the system operation and maintenance cost is inevitably increased. Meanwhile, if the primary site actively establishes a disaster recovery relationship with the backup site, the business expansion will cause business interruption and affect the flexibility of business expansion. Based on this, the inventor proposes the technical scheme of the present application.

[0034] The first embodiment of the present application relates to a disaster recovery method. In the present embodiment, if the identity of the local site is a backup site, a disaster recovery relationship is established with the primary site assigned to the local site and not yet established with the local site. After the disaster recovery relationship is established, the local site backs up the data in the primary site as a backup site. The whole disaster recovery method involves an M+N type disaster recovery architecture, which is composed of a primary domain and a backup domain, wherein the primary domain contains M primary sites, and the backup domain contains N backup sites. It can be considered that the disaster recovery architecture is composed of M primary sites and N backup sites, and the primary sites and the backup sites can communicate with each other. One primary site can establish a disaster recovery relationship with multiple backup sites, and one backup site can also establish a disaster recovery relationship with multiple primary sites. Each site can be deployed in the same or different regions according to actual planning needs. Wherein, M and N are both natural numbers greater than or equal to 1. As shown in Figure 1 When M and N are both 2, i.e. the structure diagram of the 2+2 type disaster recovery architecture, the primary domain includes primary sites A and B, and the backup domain includes D and E. The implementation details of the disaster recovery method of the present embodiment will be specifically described below, and the following content is only provided for the implementation details for easy understanding, and is not necessary for implementing the present scheme. The specific process is shown in Figure 2 As shown in

[0035] Step 101, when it is determined that the identity of the local site is a backup site, it is detected whether there is a target site that meets the preset condition; if there is, go to step 102; otherwise, the process is ended.

[0036] Specifically, in the process of detecting whether there is a target site that meets the preset condition, first, the local site scans the pre-stored primary site list, which includes all the primary sites assigned to the local site, and then detects the current state of each primary site in the primary site list, and determines the primary site whose current state is not yet established with the local site as a disaster recovery relationship as the target site that meets the preset condition.

[0037] In a specific example, the identity of the local site includes a primary site and a backup site, and the operation and maintenance personnel can configure through a specific interface to achieve the purpose of setting the identity of the local site.

[0038] Step 102, a disaster recovery relationship is established with the target site.

[0039] Specifically, when a target site satisfying the preset condition is detected, the local site sends a connection request to the target site as a backup site, and after receiving a response of the target site allowing the connection, the local site confirms that the disaster recovery relationship is successfully established. The connection request can contain the identity information of the local site, so that the target site can identify and record the identity information of the local site, and thus the target site can know the source of the connection request, i.e., the object of establishing the disaster recovery relationship.

[0040] In step 103, the target site backs up the data to be backed up in the target site.

[0041] Specifically, when the local site is a backup site, the local site pulls the data to be backed up in the target site from a preset storage area of the target site. In this way, the coupling caused by the many-to-many disaster recovery relationship can be well solved. The master site only needs to back up the data, and the recovery process of the backup site is decoupled. Moreover, the master sites in the master domain and the backup sites in the backup domain are independent of each other, and the entire disaster recovery process will not be unavailable due to the failure of a master site to produce data to be backed up or the failure of a backup site to back up data.

[0042] Specifically, the data to be backed up is bound with the identity information of the target site, and the local site stores the data to be backed up in the storage area corresponding to the target site according to the identity information.

[0043] Specifically, the data to be backed up and each application in the target site correspond one-to-one. When the local site backs up the data to be backed up in the target site, each application of the local site backs up the data to be backed up in each application of the target site, and each application of the local site and each application of the target site correspond one-to-one.

[0044] In one specific example, each application in the primary site produces data required for disaster recovery, which is to be backed up. The application autonomously decides the backup strategy according to the particularity of its own business and relevant parameters, which includes period, full backup, incremental backup, etc., without limitation. For the data of each key application in the system, the backup period can be as short as possible, for example, it can be set to backup once every 30 seconds. For non-key applications, it can be set to backup once every 1 hour. For applications with large data volume, incremental synchronization can be selected, and otherwise full backup can be selected. It should be noted that key applications and non-key applications can be distinguished according to preset standards, and the standards for distinguishing key applications and non-key applications are not limited herein, and can be determined according to actual conditions in actual operation. In particular, for the primary site in the primary domain, there can be a case that multiple primary sites are backed up by the same standby site, so that the primary site identification bit is carried during data backup, i.e., the identity information is bound. Correspondingly, the application in each standby site in the standby domain pulls the corresponding backup data from the storage medium of the active primary site in the primary domain to perform data synchronization. The period, frequency, and timing of data synchronization can be determined by each application according to its own business by configuring relevant parameters. The application in each site in the standby domain restores the backup data to the standby site, maintaining the consistency of the primary and standby sites. For the standby site in the standby domain, there can be a case that one standby site backs up multiple primary sites, so that the primary site identification bit carried by the backup data needs to be restored together. In principle, the versions of each site in the primary domain and the standby domain should be consistent. When the versions are inconsistent, for example, the versions in the primary domain are high and low, the version of the site in the standby domain should use the high version in principle, so that the standby domain can restore the data with low version in the primary domain compatibly.

[0045] In one specific example, it is assumed that a 2+2 type multi-to-multi disaster recovery relationship is to be established, as shown in FIG. 1. Figure 3 At this time, the disaster recovery relationship of the 2+2 type is shown in Table 1, i.e., the standby site D establishes a disaster recovery relationship with the primary sites A and B respectively, and the standby site E establishes a disaster recovery relationship with the primary site A. It should be noted that the establishment of the above disaster recovery relationship is only one case in actual operation, and is not a necessary condition for implementing the present scheme.

[0046]

[0047] Table 1

[0048] First, the identity of the local site is determined, and if the local site is a backup site, the identity of the local site as a backup site is published to the message middleware. Similarly, if the identity of the local site is a primary site, the identity of the local site as a primary site is published to the message middleware. Then, a heartbeat message is sent to the primary site that meets the preset condition and is in an active state, such as the backup site D sending a heartbeat message to the active primary site A to request to establish a connection. If the backup site receives a response allowing the connection, the disaster recovery relationship is confirmed to be established. If no response is received, the object that sends the heartbeat message is set to an abnormal state in the local site. For example, the backup site D sends a heartbeat message to the active primary site A that meets the preset condition, but no response to the heartbeat message is received, so the backup site D records the primary site A as an abnormal state and sends an alarm notification. Each application in the site listens to the stored site identity information of the message middleware, and then performs a corresponding action according to the site identity, the primary site produces data to be backed up, and the backup site backs up and restores the data to be backed up in the primary site that has established the disaster recovery relationship.

[0049] In a specific example, it is assumed that the disaster recovery architecture is of a 2+2 type, that is, two primary sites and two backup sites, denoted as A, B for the primary sites and C, D for the backup sites, and the specific disaster recovery relationship is as follows Figure 3As shown, now because of business expansion, a new main site C needs to be opened in a certain region, and two disaster recovery redundancies, i.e., two backups, are needed. First, site C needs to be built, then the network plane needs to be opened to enable site C to interwork with sites A, B, D, and E. Then, the operator sets the identity of site C as the main site in the configuration interface. At this time, the operator can configure the environment information of main site C on the current backup sites D and E, i.e., add main site C to the main site list of backup sites D and E, and set main site C to the active state. It needs to be noted that if main site C is in the inactive state, a disaster recovery relationship cannot be established with other backup sites. The environment information includes port information, which is not limited here. Taking backup site D as an example, when site D determines itself as a backup site, it will detect whether there is a main site that meets the preset condition, i.e., a main site that is assigned to itself and has not established a disaster recovery relationship with itself. Since main site C is newly added, there must be a main site C that meets the preset condition in the main site list. When the information of main site C is scanned in the main site list, a connection request, which can be a heartbeat message, is sent to main site C. When main site C accepts the connection request from backup site D, it will store the information of backup site D, and backup site D will also store the information of main site C. Then, the active main site C sends a response allowing the connection to backup site D, confirming that the disaster recovery relationship between main site C and backup site D is successfully established. After the disaster recovery relationship is established, each application on main site C will store the data to be backed up in the storage medium according to the backup strategy of each application. The applications in backup site D will obtain the data to be backed up from the storage medium of main site C according to the recovery strategy of each application, and the obtaining method includes Rsync, Ftp, etc., which is not limited here, and finally the data is recovered. Backup site E is the same, and is not described one by one. At this time, the disaster recovery architecture is expanded from 2+2 to 3+2, as shown in Figure 4 Table 2 shows the disaster recovery relationship between sites when the disaster recovery architecture is expanded to 3+2:

[0050]

[0051] Table 2

[0052] Further, in another specific example, assuming that the above disaster recovery architecture is of the 3+2 type, for the primary sites A and C, the current two disaster recovery redundancies do not meet the disaster recovery requirements, and a backup site needs to be added, and the current disaster recovery architecture can be expanded from the 3+2 type to the 3+3 type, that is, one standby site is added. Assuming that the added site is F, first, site F is built, and then the network plane is connected to enable the new site F to interwork with sites A, B, D, and E. Then, the operator sets the identity of site F as a standby site in the configuration interface. The operator configures the environment information of the primary sites A and C on site F, that is, adds the primary sites A and C to the primary site list of site F, and sets the primary sites A and C as active. It should be noted that the operator can also configure only the environment information of the primary site A on site F, that is, in this example, the operator configures the environment information of the primary sites A and C on site F is only one of the situations that can be selected in actual implementation, and is not a necessary condition for implementing the present scheme. After site F determines itself as a standby site, it detects whether there is a primary site that meets the preset condition, that is, a primary site that is assigned to itself and has not established a disaster recovery relationship with itself. Since the standby site F is newly added, the primary sites A and C in the primary site list of the standby site F must meet the preset condition. Taking the primary site C as an example, when site F scans the information of the primary site C in the primary site list, it sends a connection request to the primary site C, which can be a heartbeat message, without limitation. When the primary site C accepts the connection request from the standby site F, it stores the information of the standby site F, and then the active primary site C sends an answer allowing the connection to the standby site F, confirming that the disaster recovery relationship between the primary site C and the standby site F is established successfully. After the disaster recovery relationship is established, the applications on the primary site C store the data to be backed up in the storage medium according to the backup strategy of each application. The applications in the standby site F obtain the data to be backed up from the storage medium of the primary site C according to the recovery strategy of each application, the obtaining mode includes Rsync, Ftp, etc., without limitation, and finally the data is recovered. The standby site E is the same, and is not described again. At this point, the disaster recovery architecture is expanded from the 3+2 type to the 3+3 type, as shown in FIG. 8. The disaster recovery relationship between the sites when the disaster recovery architecture is expanded to the 3+3 type is shown in Table 3. Figure 5

[0053]

[0054] Table 3

[0055] ​In the embodiment, after determining that the local site is a backup site, the local site initiatively establishes a disaster recovery relationship with a primary site assigned to the local site and not yet having established a disaster recovery relationship with the local site, and then backs up data for the primary site. In the process of establishing the disaster recovery relationship, no active request is required from the primary site, avoiding the situation that the original service is interrupted due to expansion of the service in the running process when the primary site initiatively establishes the disaster recovery relationship, and improving the flexibility of service expansion.

[0056] The second embodiment of the present application relates to a disaster recovery method. In the embodiment, the local site and the target site having established a disaster recovery relationship exchange identities, at which time the identity of the local site is changed from a backup site to a primary site, and the identity of the target site is changed from a primary site to a backup site. Therefore, at this time, the local site only needs to send a connection-allowed response to the target site upon receiving a connection request from the target site. The embodiment considers the case of primary-backup switching. The implementation details of the disaster recovery method of the embodiment are specifically described below, and the following content is only provided for the implementation details for easy understanding, and is not necessary for implementing the present application. The specific flow of the disaster recovery method of the second embodiment is shown in Figure 6

[0057] Step 201, when determining that the identity of the local site is a backup site, detecting whether there is a target site satisfying a preset condition; if yes, proceeding to step 202; otherwise, ending the flow.

[0058] Step 202, establishing a disaster recovery relationship with the target site.

[0059] Step 203, backing up data to be backed up in the target site for the target site.

[0060] Steps 201-203 are similar to steps 101-103 in the first embodiment, and will not be described again.

[0061] Step 204, detecting whether the local site exchanges identities with the target site; if yes, proceeding to step 204; otherwise, ending the flow.

[0062] Step 205, receiving a connection request from the target site, and sending a connection-allowed response to the target site.

[0063] It should be noted that in the embodiment, the detection of whether the local site exchanges identities with the target site in step 204 is performed after the backup of the data to be backed up in the target site for the target site in step 203, and the present embodiment only provides one case. However, in actual implementation, step 204 can be performed simultaneously with step 203, or after step 203, and these cases should be within the protection scope.

[0064] ​In a specific example, considering the risks and unpredictability brought by automatic active-standby switching, and the fact that the disaster recovery relationship designed by the method is a many-to-many relationship, i.e., the data of one active site can be backed up to multiple standby sites, when a disaster occurs, the operation and maintenance personnel manually select a standby site in the standby domain to perform the active operation according to the data recovery status of each standby site. Assuming that the current disaster recovery architecture is a 3+3 type, the active sites are A, B, and C, and the standby sites are D, E, and F, and a natural disaster occurs in the region where the active site C is located, and the active site C is unavailable and needs to be quickly restored. The operation and maintenance personnel can check the health status and current operation of the active site C in the standby sites D, E, and F. Assuming that the final determination is to exchange the identities of the standby site F and the active site C, and then the operation and maintenance personnel configure the standby site F as an active site to replace the active site C to provide normal business functions. Correspondingly, the operation and maintenance personnel restores the active site C and configures the active site C as a standby site to replace the standby site F to work, and completes the business recovery work. After the identity exchange, the local site F as the active site only needs to receive the connection request from the target site C and send a connection allowed response to the site C. Each site listens to the middleware messages in the messages, and performs corresponding actions according to the identity of the site, i.e., the active site produces data to be backed up according to the backup strategy, and the standby site obtains the backup data for recovery according to the recovery strategy.

[0065] In this embodiment, considering the identity exchange, the local site now as the active site only needs to respond to the connection request of the target site which has become a standby site. Although the identity exchange is performed, the essence is still that the standby site actively establishes a disaster recovery relationship with the active site assigned to the local site and has not established a disaster recovery relationship with the local site, without the active site actively requesting, avoiding the case that the original business is interrupted due to the expansion of the business in the running process when the active site actively establishes a disaster recovery relationship, and improving the flexibility of business expansion.

[0066] The third embodiment of the application relates to a disaster recovery method. In this embodiment, after detecting that the local site and the target site exchange identities, the data backed up by the local site for the target site is put into the storage area of the local site for the standby site to access, so that the target site can pull from the storage area of the local site for the standby site to access. The working condition of the local site after the identity exchange is provided. The implementation details of the disaster recovery method of this embodiment will be specifically described below, and the following content is only provided for the implementation details for easy understanding, and is not necessary for implementing the scheme. The specific process is as shown in Figure 7 , which includes:

[0067] Step 301, when determining that the identity of the local site is a backup site, detecting whether there is a target site meeting the preset condition; if yes, entering step 302; otherwise, the process ends.

[0068] Step 302, establishing a disaster recovery relationship with the target site.

[0069] Step 303, backing up the data to be backed up in the target site for the target site.

[0070] Steps 301-303 are similar to steps 101-103 in the first embodiment, and will not be repeated here.

[0071] Step 304, detecting whether the local site and the target site exchange identities; if yes, entering step 304; otherwise, the process ends. Similar to step 204, it will not be repeated here.

[0072] It should be noted that in the present embodiment, the detection of whether the local site and the target site exchange identities in step 304 is performed after the backup of the data to be backed up in the target site for the target site in step 303, and the present embodiment only provides one case. However, in actual implementation, step 304 can be performed simultaneously with step 303 or after step 303, and these cases should be within the protection scope.

[0073] Step 305, putting the data backed up by the local site for the target site into the storage area of the local site for the backup site to access, so that the target site pulls from the storage area of the local site for the backup site to access.

[0074] Step 306, receiving the connection request of the target site and sending the response allowing the connection to the target site. Similar to step 205, it will not be repeated here.

[0075] It should be noted that in the present embodiment, the putting of the data backed up by the local site for the target site into the storage area of the local site for the backup site to access in step 305 is performed after the receiving of the connection request of the target site and the sending of the response allowing the connection to the target site in step 306, and the present embodiment only provides one case. However, in actual implementation, step 305 can be performed simultaneously with step 306 or after step 306, and these cases should be within the protection scope.

[0076] In the embodiment, after detecting that the local site and the target site exchange identities, the data backed up by the local site for the target site is put into the storage area of the local site for the backup site to access, so that the target site after the identity exchange can pull the data from the storage area of the local site for the backup site, without the need of the local site after the identity exchange to actively send, and the working condition of the local site after the identity exchange is provided.

[0077] The fourth embodiment of the present application relates to a disaster recovery method. Compared with the second embodiment, after detecting that the local site and the target site exchange identities, the data stored in the local site except for the data backed up for the target site needs to be cleared or stored, that is, the backup data of the local site as the master site in other disaster recovery relationships and the backup data of the target site after the identity exchange are stored separately, so that the target site after the identity exchange can directly pull, and the difficulty of the target site in the process of pulling the backup data is reduced. The implementation details of the disaster recovery method of the embodiment will be specifically described below, and the following content is only provided for the implementation details for easy understanding, and is not necessary for implementing the present application. The specific flow is shown in Figure 8

[0078] Step 401, when it is determined that the identity of the local site is the backup site, it is detected whether there is a target site meeting the preset condition; if yes, the process goes to step 402; otherwise, the process ends.

[0079] Step 402, a disaster recovery relationship is established with the target site.

[0080] Step 403, the target site backs up the data to be backed up in the target site.

[0081] Steps 401-403 are similar to steps 101-103 in the first embodiment, and will not be described here.

[0082] Step 404, it is detected whether the local site and the target site exchange identities; if yes, the process goes to step 404; otherwise, the process ends. Step 404 is similar to step 204, and will not be described here.

[0083] It should be noted that in the embodiment, the detection of whether the local site and the target site exchange identities in step 404 is performed after the backup of the data to be backed up in the target site for the target site in step 403, and the present embodiment only provides one case. However, in actual implementation, step 404 can be performed simultaneously with step 403 or after step 403, and these cases should be within the protection scope.

[0084] Step 405, the data stored in the local site except for the data backed up for the target site is cleared or stored. ​

[0085] Step 406, receiving the connection request of the target site, and sending the response of allowing the connection to the target site. Similar to step 205, it will not be repeated here.

[0086] It should be noted that in the present embodiment, the clearing or storing of the data stored in the local site except for the backup data of the target site in step 405 is performed after receiving the connection request of the target site in step 406 and sending the response of allowing the connection to the target site. The present embodiment only provides one case. In actual implementation, step 405 can be performed simultaneously with step 406 or after step 406, which should be within the protection scope.

[0087] In the present embodiment, when it is detected that the local site and the target site perform identity exchange, the backup data stored in the local site except for the backup data of the target site needs to be cleared or stored, i.e., the backup data of the local site in other disaster recovery relationship and the backup data of the target site in identity exchange are stored separately, which facilitates the target site to directly pull after identity exchange and reduces the difficulty of the target site to pull the backup data.

[0088] The fifth embodiment of the present application relates to a disaster recovery method. In the present embodiment, when it is detected that the local site and the target site perform identity exchange, not only the backup data stored in the local site except for the backup data of the target site needs to be cleared or stored, i.e., the backup data of the local site in other disaster recovery relationship and the backup data of the target site in identity exchange are stored separately, but also the backup data of the target site in the local site is put into the storage area of the local site for the backup site to access, so as to be pulled by the target site from the storage area of the local site for the backup site to access. The implementation details of the disaster recovery method of the present embodiment will be specifically described below, and the following content is only provided for the implementation details for easy understanding, and is not necessary for implementing the present solution. The specific flow is as shown in Figure 9 , which includes:

[0089] Step 501, when it is determined that the identity of the local site is the backup site, detecting whether there is a target site meeting the preset condition; if yes, entering step 502; otherwise, the flow ends.

[0090] Step 502, establishing a disaster recovery relationship with the target site.

[0091] Step 503, backing up the data to be backed up in the target site for the target site.

[0092] Steps 501-503 are similar to steps 101-103 in the first embodiment, and will not be repeated here.

[0093] Step 504, detecting whether the local site and the target site exchange identities; if yes, entering step 505; otherwise, the flow ends. Similar to step 204, it will not be described here.

[0094] It should be noted that in the present embodiment, the detection of whether the local site and the target site exchange identities in step 504 is performed after the backup of the data to be backed up in the target site in step 503, and the present embodiment only provides one case. However, in actual implementation, step 504 can be performed simultaneously with step 503 or after step 503, and these cases should be within the protection scope.

[0095] Step 505, putting the data backed up by the local site for the target site into the storage area of the local site for the backup site to access, so that the target site pulls from the storage area of the local site for the backup site to access.

[0096] Step 506, clearing or storing the data stored in the local site except for the backup site of the target site. Similar to step 405, it will not be described here.

[0097] Step 507, receiving the connection request of the target site and sending the response of allowing the connection to the target site. Similar to step 205, it will not be described here.

[0098] It should be noted that the execution order of steps 505, 506 and 507 in the present embodiment can be changed according to actual conditions, and all the changed cases should be within the protection scope.

[0099] In the present embodiment, when it is detected that the local site and the target site exchange identities, not only the data stored in the local site except for the backup site of the target site is cleared or stored, but also the data backed up by the local site for the target site is put into the storage area of the local site for the backup site to access, so that the target site pulls from the storage area of the local site for the backup site to access, providing a working condition after the local site and the target site exchange identities.

[0100] The step division of the above methods is only for clear description, and in implementation, one step can be combined or some steps can be split and decomposed into multiple steps, as long as the same logical relationship is included, which is within the protection scope of the present patent; adding irrelevant modifications or introducing irrelevant designs in the algorithm or flow, but not changing the core design of the algorithm and flow, are within the protection scope of the present patent.

[0101] The fifth embodiment of the present application relates to a disaster recovery device. The disaster recovery device comprises: a comprehensive service module 601, a message middleware 602, and an application embedded with a data backup module 603. The number of applications is n, and n is a natural number greater than zero. The specific structure diagram is shown in Figure 10 as shown, comprising:

[0102] The comprehensive service module 601 is configured to detect whether there is a target site meeting the preset condition when it is determined that the local site is a backup site, and the preset condition includes: the target site is a primary site, and the target site is assigned to the local site and has not established a disaster recovery relationship with the local site; and is further configured to establish a disaster recovery relationship with the target site meeting the preset condition.

[0103] Specifically, the operation and maintenance personnel can set the identity of the site through the interface provided by the comprehensive service module 601, such as setting the identity of a certain site as a primary site.

[0104] The message middleware 602 is configured to store the identity information of the local site from the comprehensive service module 601.

[0105] The data backup module 603 is configured to listen to the identity information of the local site in the message middleware, and after the local site establishes a disaster recovery relationship with the target site, backup the data to be backed up in the target site according to the identity information of the local site.

[0106] In a specific example, the initiator of establishing a disaster recovery relationship is generally the comprehensive service module 601 of the backup site. The backup site comprehensive service module 601 sends a connection request to the target site, and after receiving the response of the target site allowing the connection, it confirms that the disaster recovery relationship is established successfully. The connection request can be a heartbeat message, which is not limited here. Assuming that the comprehensive service module 601 establishes and maintains the disaster recovery relationship between the primary and backup sites through the heartbeat message. The schematic diagram of the 2+2 type disaster recovery architecture when establishing a disaster recovery relationship is shown in Figure 11 The comprehensive service modules 601 in the backup sites D and E in the backup domain respectively send heartbeat messages to the primary sites A and B in the primary domain.

[0107] In a specific example, the comprehensive service module 601 scans the pre-stored primary site list, which includes all primary sites assigned to the local site. Then detect the current state of each primary site in the primary site list, and determine the primary site whose current state is that it has not established a disaster recovery relationship with the local site as the target site meeting the preset condition.

[0108] In a specific example, during the process of backing up the data to be backed up in the target site for the target site, the data backup module 603 pulls the data to be backed up from the storage area of the target site for the backup site to access.

[0109] In one specific example, the data to be backed up is bound with the identity information of the target site. During the process of backing up the data to be backed up in the target site for the target site, the data backup module 603 stores the data to be backed up in the storage area corresponding to the target site according to the identity information. A schematic diagram of backing up data in a 2+2 type disaster recovery framework is shown in FIG. 2B. As shown in FIG. 2B, the data backup modules 603 in the standby sites D and E in the standby domain respectively send a request for backing up data to the active sites A and B in the active domain, and then respectively pull the data to be backed up from the storage medium of the active sites A and B. Figure 12

[0110] In one specific example, after the local site and the target site establish a disaster recovery relationship, if it is detected that the identity of the local site and the target site are interchanged, the comprehensive service module 601 sends a response allowing connection to the target site when receiving a connection request from the target site.

[0111] In one specific example, after it is detected that the identity of the local site and the target site are interchanged, the data backup module 603 puts the data backed up by the local site for the target site into the storage area of the local site for the standby site to access, so as to be pulled by the target site from the storage area of the local site for the standby site to access.

[0112] In one specific example, after it is detected that the identity of the local site and the target site are interchanged, the data backup module 603 clears or stores the data stored in the local site except for the data backed up for the target site.

[0113] In one specific example, during the process of backing up the data to be backed up in the target site for the target site, the application of the local site backs up data for the application in the target site which is the same as the application.

[0114] It can be found that the present embodiment is a system embodiment corresponding to the first embodiment, and the present embodiment can be implemented in cooperation with the first embodiment. The related technical details mentioned in the first embodiment are still valid in the present embodiment, and the technical effects that can be achieved in the first embodiment can also be achieved in the present embodiment. In order to reduce repetition, they will not be described here. Correspondingly, the related technical details mentioned in the present embodiment can also be applied in the first embodiment.

[0115] It is worth mentioning that each module involved in the present embodiment is a logical module. In actual application, a logical unit can be a physical unit, a part of a physical unit, or a combination of multiple physical units. In addition, in order to highlight the innovative part of the present application, units not closely related to solving the technical problems proposed in the present application are not introduced in the present embodiment, but this does not mean that there are no other units in the present embodiment. ​

[0116] The sixth embodiment of the present application relates to a local point, comprising: Figure 13 As shown, comprising: at least one processor 701; and a memory 702 connected with the at least one processor in communication; wherein the memory 702 stores instructions executable by the at least one processor 701, and the instructions are executed by the at least one processor 701 to enable the at least one processor 701 to perform the disaster recovery method.

[0117] The memory 702 and the processor 701 are connected in a bus manner, the bus can include any number of interconnected buses and bridges, and the bus connects one or more processors 701 and various circuits of the memory 702 together. The bus can also connect various other circuits such as peripheral local points, voltage stabilizers and power management circuits together, which are well known in the art, and therefore, further description is not given herein. The bus interface provides an interface between the bus and the transceiver. The transceiver can be one element or multiple elements such as multiple receivers and transmitters, which provide a unit for communicating with various other devices on a transmission medium. The data processed by the processor 701 is transmitted on a wireless medium through an antenna, and further, the antenna also receives data and transmits the data to the processor 701.

[0118] The processor 701 is responsible for managing the bus and general processing, and can also provide various functions including timing, peripheral interface, voltage regulation, power management and other control functions. The memory 702 can be used to store data used by the processor 701 in performing operations.

[0119] The seventh embodiment of the present application relates to a computer readable storage medium, which stores a computer program. The computer program is executed by a processor to implement the method embodiments described above.

[0120] That is, those skilled in the art can understand that all or part of the steps in the above-mentioned embodiment methods can be completed by programs instructing related hardware, the programs are stored in a storage medium, and include a plurality of instructions for causing a local point (which can be a single-chip microcomputer, a chip, etc.) or a processor to execute all or part of the steps of the method described in each embodiment of the present application. The foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk, and various media that can store program codes.

[0121] Those skilled in the art can understand that the above-mentioned embodiments are specific embodiments for implementing the present application, and in actual applications, various changes can be made in form and details without departing from the spirit and scope of the present application.

Claims

1. A disaster recovery method, characterized by, The method comprises the steps of: If it is determined that the identity of the local site is a backup site, scanning a pre-stored primary site list, wherein the primary site list comprises all primary sites assigned to the local site, and detecting whether a target site satisfying a preset condition exists in the primary site list; The preset condition comprises that the identity of the target site is a primary site, and the target site is assigned to the local site and has not established a disaster recovery relationship with the local site; If the target site satisfying the preset condition exists, establishing the disaster recovery relationship with the target site; Backing up data to be backed up in the target site for the target site.

2. The disaster recovery method according to claim 1, wherein, The step of establishing the disaster recovery relationship with the target site comprises: Sending a connection request to the target site, and confirming that the disaster recovery relationship is successfully established after receiving a response of allowing connection from the target site.

3. The disaster recovery method of claim 1, wherein, The step of detecting whether the target site satisfying the preset condition exists in the primary site list comprises: Detecting a current state of each primary site in the primary site list, and determining a primary site whose current state is that the primary site has not established the disaster recovery relationship with the local site as the target site satisfying the preset condition.

4. The disaster recovery method of claim 1, wherein, The step of backing up the data to be backed up in the target site for the target site comprises: pulling the data to be backed up from a storage area for backup sites to access in the target site.

5. The disaster recovery method of claim 1, wherein, The data to be backed up is bound with identity information of the target site. The step of backing up the data to be backed up in the target site for the target site comprises: According to the identity information, storing the data to be backed up in a storage area corresponding to the target site.

6. The disaster recovery method of claim 1, wherein, After the disaster recovery relationship with the target site is established, the method further comprises: If it is detected that the identities of the local site and the target site are interchanged, when a connection request of the target site is received, sending a response of allowing connection to the target site.

7. The disaster recovery method of claim 6, wherein, After it is detected that the identities of the local site and the target site are interchanged, the method further comprises: Putting data backed up by the local site for the target site into a storage area for backup sites to access in the local site, so that the target site pulls the data from the storage area for backup sites to access in the local site.

8. The disaster recovery method of claim 6, wherein, After it is detected that the identities of the local site and the target site are interchanged, the method further comprises: Clearing or archiving data stored in the local site except for data backed up for the target site.

9. The disaster recovery method of claim 1, wherein, The step of backing up the data to be backed up in the target site for the target site comprises: An application of the local site backs up data for an application in the target site which is the same as the application of the local site.

10. A disaster recovery device, comprising: The method comprises: An integrated service module, a message middleware and an application embedded with a data backup module; The integrated service module is configured to scan a pre-stored primary site list when it is determined that the identity of the local site is a backup site, wherein the primary site list comprises all primary sites assigned to the local site, detect whether a target site satisfying a preset condition exists in the primary site list, and establish a disaster recovery relationship with the target site satisfying the preset condition. The preset condition comprises: the target site is a primary site identity, and the target site is assigned to the local site and has not established a disaster recovery relationship with the local site; The message middleware is configured to store the identity information of the local site from the integrated service module; The data backup module in the application is configured to listen to the identity information of the local site in the message middleware, and backup data to be backed up in the target site according to the identity information of the local site after the local site establishes the disaster recovery relationship with the target site.

11. A locus characterised in that, Comprise: At least one processor; And The memory is in communication connection with the at least one processor; wherein The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the disaster recovery method of any one of claims 1 to 9.

12. A computer-readable storage medium storing a computer program, characterized in that, The computer program is executed by the processor to realize the disaster recovery method of any one of claims 1 to 9.

Images