WO2020063600A1 - 数据容灾方法与站点 - Google Patents

数据容灾方法与站点 Download PDF

Info

Publication number
WO2020063600A1
WO2020063600A1 PCT/CN2019/107620 CN2019107620W WO2020063600A1 WO 2020063600 A1 WO2020063600 A1 WO 2020063600A1 CN 2019107620 W CN2019107620 W CN 2019107620W WO 2020063600 A1 WO2020063600 A1 WO 2020063600A1
Authority
WO
WIPO (PCT)
Prior art keywords
disaster recovery
site
cbt
snapshot
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2019/107620
Other languages
English (en)
French (fr)
Inventor
杨文珺
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to EP19865699.3A priority Critical patent/EP3848809A4/en
Publication of WO2020063600A1 publication Critical patent/WO2020063600A1/zh
Priority to US17/211,906 priority patent/US11947429B2/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operations
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1469—Backup restoration techniques
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2048—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant where the redundant components share neither address space nor persistent storage
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operations
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operations
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • G06F11/1451—Management of the data involved in backup or backup restore by selection of backup contents
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operations
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1464—Management of the backup or restore process for networked environments
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operations
    • G06F11/1479—Generic software techniques for error detection or fault masking
    • G06F11/1482—Generic software techniques for error detection or fault masking using middleware or operating system [OS] functionalities
    • G06F11/1484—Generic software techniques for error detection or fault masking using middleware or operating system [OS] functionalities involving virtual machines
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1658—Data re-synchronization of a redundant component, or initial sync of replacement, additional or spare unit
    • G06F11/1662—Data re-synchronization of a redundant component, or initial sync of replacement, additional or spare unit the resynchronized component or unit being a persistent storage device
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2038—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with a single idle spare processing component
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2097—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements maintaining the standby controller/processing unit updated
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/84—Using snapshots, i.e. a logical point-in-time copy of the data

Definitions

  • the present application relates to the field of information processing, and in particular, to a method and a site for disaster recovery of data.
  • Data disaster recovery is one of the hot topics in the construction of information and data centers. Normally, the production site needs to send data backups to the disaster recovery site during normal operations. So that when the production site fails, the disaster recovery site can take over the services of the production site. When troubleshooting the production site, synchronize data from the disaster recovery site to the production site to restore services.
  • data synchronization from the disaster recovery site to the production site usually uses a full data synchronization scheme.
  • the synchronization of the full amount of data results in a large amount of data to be transmitted between the disaster recovery site and the production site, occupying a large bandwidth, and affecting the disaster recovery time objective (RTO).
  • RTO disaster recovery time objective
  • This application provides a method and site for data disaster recovery, which can reduce the amount of data synchronized between the disaster recovery site and the production site during the disaster recovery process.
  • a data disaster recovery method includes a production site and a disaster recovery site.
  • the method includes: when the disaster recovery site takes over the services of the production site, selecting a first backup copy;
  • the disaster recovery site receives business data by using a virtual machine;
  • the disaster recovery site uses block modification tracking CBT technology and the received business data to obtain CBT information, where the CBT information includes after the disaster recovery site receives the first backup copy Incremental information;
  • the disaster recovery site sends a first message to the production site, the first message contains the CBT information; wherein the storage server in the disaster recovery site and the production server in the production site
  • the storage server is a heterogeneous device.
  • the disaster recovery site uses CBT technology to generate incremental information since the disaster recovery station took over the production site business. It has a smaller amount of data than full backup, which can reduce transmission bandwidth, reduce RTO, and improve user experience.
  • the above disaster recovery site may be composed of multiple servers, where multiple servers include the storage server, backup server, other types of servers, etc. of the above disaster recovery site;
  • the production site may be composed of production host, backup server, and storage server Composition, this application does not specifically limit this.
  • the disaster recovery site may take over the services of the production site when the entire production site fails, or it may take over the services of the production site when the host in the production site fails, which is not specifically limited in this embodiment of the present application.
  • the disaster recovery site using block modification tracking CBT technology and received services to obtain the CBT information includes: the disaster recovery site generates N snapshots, the N is greater than or equal to 2; the disaster recovery site obtains difference information between each snapshot in the N snapshots and the last snapshot of each snapshot in the N snapshots, and the CBT information includes all Mentioned differential information.
  • the snapshot generation speed is fast and the footprint is small.
  • the snapshot-based CBT technology can increase the backup speed and further reduce the RTO.
  • the CBT information includes one CBT corresponding to each snapshot in the N snapshots, the Nth snapshot corresponds to the Nth CBT, and the Nth The CBT contains the difference information between each snapshot in the previous N-1 snapshots and the last snapshot of each snapshot in the previous N-1 snapshots.
  • the corresponding CBT format in the above technical solution can increase the proportion of useful data blocks in the CBT, and further reduce the amount of data synchronized between the disaster recovery site and the production site.
  • the method further includes : The disaster recovery site deletes the first N-1 snapshots and retains the Nth snapshot.
  • deleting the snapshot at the production site of the disaster recovery site after completing the backup can save a certain amount of storage space and optimize the business performance of the disaster recovery site.
  • the last snapshot retained can be used directly as the basis for subsequent backups, saving time when generating snapshots.
  • a data disaster recovery method including: a production site sends a first backup copy to a disaster recovery site, so that the disaster recovery site takes over the business of the production site; the production site receives the disaster A first message sent by the standby site, where the first message includes CBT information, and the CBT information includes incremental information generated since the disaster recovery site took over the services of the production site; A backup copy restores business with the CBT information.
  • the production site generates multiple backup copies, and stores multiple backup copies in a local storage server.
  • the multiple backup copies are stored on a local server, and multiple backup copies are sent to the disaster recovery site.
  • the disaster recovery site and the production site have the same backup data link, which is conducive to achieving incremental backup. It can complete the disaster recovery process when the production host in the production site fails.
  • the CBT information includes N CBTs, and the N is greater than or equal to 2, and the method further includes: the production site determines a CBT of each of the N CBTs. Between the first backup copy and each CBT.
  • the difference between different CBTs can be used to enable the production site to quickly recover services.
  • a disaster recovery site including: a selection module for selecting a first backup copy when taking over services at a production site; a receiving module for receiving business data using a virtual machine; and an acquisition module for utilizing Block modification tracking CBT technology and the received business data to obtain CBT information, the CBT information includes incremental information after the disaster recovery site receives the first backup copy; a sending module is configured to send to the production site A first message, where the first message includes the CBT information; wherein the storage server in the disaster recovery site and the storage server in the production site belong to heterogeneous devices.
  • the disaster recovery site further includes: a generating module for generating N snapshots, where N is greater than or equal to 2; and an acquiring module for obtaining each of the N snapshots Difference information between the second snapshot and the last snapshot of each snapshot in the N snapshots, and the CBT information includes the difference information.
  • the CBT information includes one CBT corresponding to each snapshot in the N snapshots, the Nth snapshot corresponding to the Nth CBT, and the Nth CBT Contains the difference information between each snapshot in the previous N-1 snapshots and the last snapshot of each snapshot in the previous N-1 snapshots.
  • the acquisition module is further configured to delete the first N-1 snapshots and retain the Nth snapshot.
  • a production site including: a sending module configured to send a first backup copy to a disaster recovery site so that the disaster recovery site can take over the services of the production site; a receiving module configured to receive the A first message sent by the disaster recovery site, where the first message includes CBT information, and the CBT information includes incremental information generated since the disaster recovery site took over the services of the production site; a recovery module is configured to Said first backup copy and said CBT information restore business.
  • the CBT information includes N CBTs, the N is greater than or equal to 1, the production site further includes an acquisition module, and the acquisition module is further configured to acquire the N The difference between each CBT in each CBT; the recovery module is further configured to restore a service according to the difference between the first backup copy and each CBT backup.
  • a computer-readable medium for storing a computer program, the computer program including instructions for performing a method in any possible implementation of any of the above aspects.
  • a chip in which instructions are stored that, when run on a computer device, cause the communication chip to execute a method in any possible implementation manner of any of the above aspects.
  • FIG. 1 is a schematic flowchart of a data disaster recovery method in a heterogeneous scenario
  • FIG. 2 is a schematic flowchart of a data disaster recovery method in a heterogeneous scenario according to an embodiment of the present application
  • FIG. 3 is a schematic flowchart of a data disaster recovery method in another heterogeneous scenario according to an embodiment of the present application
  • FIG. 4 is a schematic structural diagram of a CBT information provided by an embodiment of the present application.
  • FIG. 5 is a schematic structural diagram of a difference between CBTs according to an embodiment of the present application.
  • FIG. 6 is a schematic block diagram of a disaster recovery site provided by an embodiment of the present application.
  • FIG. 7 is a schematic block diagram of a production site according to an embodiment of the present application.
  • Data disaster recovery is one of the hot topics in the construction of information and data centers. Normally, the production site needs to send data backups to the disaster recovery site during normal operations. So that when the production site fails, the disaster recovery site can take over the services of the production site.
  • FIG. 1 is a schematic diagram of a data disaster recovery method in a heterogeneous scenario according to an embodiment of the present application.
  • a data disaster recovery method in which a disaster recovery site synchronizes a full amount of data to a production site in a heterogeneous scenario is described using the production site as the user IDC and the disaster recovery site as a site composed of multiple servers as an example.
  • the production site can include production hosts, backup servers, storage servers, and so on.
  • the production host is used to process production site services, and the storage server is used to provide storage services for the production site;
  • the backup server is installed with backup software to back up the data of the production host and synchronize the data to the disaster recovery site; or the backup server Read data from the storage server and send it to the disaster recovery site.
  • the multiple servers that make up the disaster recovery site can be logically divided into a first set and a second set. The first set is used to provide computing resources, and the second set is used to provide storage resources.
  • the storage server in the production site and the disaster recovery site The storage servers are heterogeneous.
  • step S110 the production site operates normally and sends a backup copy to the disaster recovery site.
  • the disaster recovery site stores the backup copy in the storage server.
  • the production host at the production site processes user-related services.
  • a backup server is required to back up the data on the production host and send the backup data to the disaster recovery site.
  • the disaster recovery site stores the backup copy in a storage server in the second set for providing storage resources.
  • step S120 when the production site fails, the disaster recovery site recovers the operation of the virtual machine based on the backup copy received in the above step S110, and uses the recovered virtual machine to take over the business of the production site.
  • step 130 when the production site fails, the disaster recovery site sends a data backup to the production site.
  • the data backup is a full backup.
  • the full backup includes not only the data newly generated after the disaster recovery site takes over the production site, but also includes the data. The original data of the production site.
  • the production site performs disaster recovery based on the received full backup.
  • the storage server at the production site is heterogeneous with the storage devices at the disaster recovery site, you need to send a full backup to the host at the production site so that the production host can resume production based on the full backup.
  • the transmission of full data increases the amount of data that needs to be synchronized at the production site, which results in an increase in transmission bandwidth and RTO.
  • the embodiment of the present application provides a data disaster recovery method in a heterogeneous scenario.
  • the disaster recovery site transmits the full amount of data to the production site during the disaster recovery process to achieve business recovery of the production site.
  • the transmission of incremental data can reduce the disaster recovery site to production during the disaster recovery process.
  • the amount of data synchronized by the site saves transmission bandwidth and reduces RTO.
  • FIG. 2 is a schematic flowchart of the data disaster recovery method provided by the embodiment of the present application.
  • step S210 the disaster recovery site takes over the services of the production site.
  • Both the disaster recovery site and the production site can be sites composed of multiple servers; or the disaster recovery site can consist of multiple servers and the production site is a user IDC; or the disaster recovery site can be a user IDC and the production site can be an enterprise server Wait, this embodiment of the present application does not specifically limit this.
  • the disaster recovery site selects the first backup copy when it takes over the services of the production site.
  • the first backup copy may be any backup copy sent to the disaster recovery site before the production site fails.
  • the first backup copy may be the last backup copy generated by the production site before the failure.
  • the first backup copy may be generated by the production site using backup software and stored in a storage server in the production site.
  • the disaster recovery site and the production site have the same backup data link, which is conducive to the incremental backup during the disaster recovery process.
  • the disaster recovery site can restore the operation of the virtual machine based on the first backup copy and use the virtual machine to take over the services of the production site. So that when the production site fails, the business at the production site will not be affected.
  • the disaster recovery site can sense whether the production site has failed.
  • the production host in the production site fails, other servers in the production site notify the disaster recovery site that the production site has failed, or it may be an overall failure in the production site, and a third-party site is monitoring production
  • the disaster recovery site is notified, or the disaster recovery site can directly perform the disaster recovery operation when it detects a fault operation at the production site.
  • the embodiment of this application does not specifically address this. limited.
  • step S220 the disaster recovery site obtains CBT information by using the CBT technology and the received service data, and the CBT information includes the incremental information after the disaster recovery site receives the first backup copy.
  • the disaster recovery site is restoring virtual machine operations based on the first backup copy, so that the virtual machine can take over the business of the production site and generate new business data, that is, incremental information.
  • the incremental information may also be understood as incremental information relative to the first backup copy.
  • the disaster recovery site can use CBT technology to obtain CBT information.
  • the CBT information contains the incremental information since the disaster recovery site took over the business. In other words, the disaster recovery site implements incremental backup through CBT technology.
  • the CBT information obtained by the disaster recovery site using CBT technology includes: the disaster recovery site generates N snapshots, where N is greater than or equal to 2, and the disaster recovery site obtains each snapshot by comparing it with the last snapshot The difference information between the two snapshots, or the difference information between the two versions at different times of the production site, and the difference information is stored in the CBT information.
  • a snapshot (also called a storage snapshot) is an image of data at a certain point in time. By comparing snapshots, you can get the change in data at one point in time relative to another.
  • the CBT technology determines whether a data block has been modified within a period of time based on a snapshot comparison, and marks or records the modified data block.
  • the embodiment of the present application does not specifically limit the frequency and time point of the snapshot generated by the disaster recovery site.
  • the first step may be to restore the virtual machine operation based on the first backup copy at the disaster recovery site, and use the virtual machine to take over the production site service, that is, at a certain point in time before generating new data relative to the version corresponding to the first backup copy.
  • a snapshot can be generated at a fixed frequency afterwards, or the user can decide to back up the disaster recovery site, and make the disaster recovery site generate a snapshot according to the user's needs.
  • snapshots are not specifically limited in the embodiments of the present application.
  • the snapshots may be split mirror (mirror) snapshots, copy-on-write snapshots, or redirection while writing ( redirect-on-write) snapshots and more.
  • the CBT information generated based on snapshots using CBT technology can also have multiple formats.
  • the CBT information may include one CBT corresponding to each snapshot in the N snapshots, and the Nth snapshot corresponds to the Nth CBT.
  • the Nth CBT contains the difference information between each snapshot in the previous N-1 snapshots relative to the previous N-1 snapshots.
  • the CBT information may include one CBT corresponding to each snapshot in the N snapshots, and the Nth snapshot corresponds to the Nth CBT.
  • the Nth CBT includes the difference information between the Nth snapshot and the N-1th snapshot, and the like, which is not specifically limited in this embodiment of the present application.
  • the above CBT information structure based on the previous CBT, records the new CBT information, which saves CBT block resources, increases the proportion of useful information in CBT information, and saves bandwidth and storage resources.
  • the disaster recovery site may delete the first N-1 snapshots and retain the Nth snapshot.
  • deleting the snapshot can save a certain amount of storage space and optimize the business performance of the disaster recovery site.
  • the last snapshot retained can be used directly as the basis for subsequent backups, saving time when generating snapshots.
  • step S230 the disaster recovery site sends a first message to the production site.
  • the first message contains CBT information.
  • the incremental data transmission has less transmission data volume than the traditional full transmission data, which can reduce the bandwidth occupation and RTO.
  • the production site may use the existing first backup copy and the CBT information in the received first message to restore the service.
  • the CBT information is incremental information generated after the service is transferred to the disaster recovery site.
  • the production site can resume the business based on the first backup copy and the CBT information, that is, the production site can be generated based on the backup before the failure and the disaster recovery site takes over the business Incremental data to resume business after a failure.
  • FIG. 3 is a schematic flowchart of an incremental data synchronization between a disaster recovery site and a production site in a heterogeneous scenario.
  • the disaster recovery site in Figure 3 and the production site form a heterogeneous system.
  • the production site in Figure 3 is the user IDC, and the disaster recovery site consists of multiple servers.
  • the production site may include a production host to process user-related services; a storage server to provide storage services for the production site; a backup server, which has backup software installed on it Production host backup.
  • the multiple servers include a first set and a second set, where the first set is used to provide computing resources and the second set is used to provide storage resources.
  • Storage devices at the disaster recovery site and storage devices at the production site are heterogeneous devices.
  • the server involved in the embodiment of the present application may be a server with an independent physical structure or a softwareized instance on the server, which is not specifically limited in the embodiment of the present application.
  • step S310 the production site synchronizes the backup copy to the disaster recovery site.
  • the production site synchronizes the backup copies in the storage server to the disaster recovery site.
  • the disaster recovery site can store the received backup copies in any of the storage servers that make up the second collection.
  • the storage server may be an object storage service (OBS) on the cloud.
  • OBS object storage service
  • the above backup copy may be a backup copy generated by the production site under normal working conditions.
  • the production site can store this backup copy on a storage server at the production site.
  • step 320 the production site sends a first request message to the disaster recovery site, requesting the disaster recovery site to perform a disaster tolerance switching operation.
  • the production host in the production site fails, and other servers in the production site send a first request message to the disaster recovery site, requesting the disaster recovery site to perform disaster recovery operations, or it may be an overall failure in the production site.
  • the third-party site notifies the disaster recovery site when it detects a production site failure or needs a planned switchover, or it can also directly perform disaster recovery operations when the disaster recovery site detects that the production site fails.
  • the application embodiment does not specifically limit this.
  • step 330 when the disaster recovery site takes over the services of the production site, the first backup copy is selected.
  • the first backup copy may be any one of the backup copies related to the disaster recovery site and the production site, and different versions may be restored according to different backup copies.
  • the disaster recovery site generates a virtual machine based on any one of its multiple servers, for example, it can be a virtual machine generated based on a cloud server.
  • the use of the virtual machine to take over the services related to the production site may specifically be that the virtual machine runs based on the first backup copy to take over the services related to the production site.
  • the disaster recovery site can generate a snapshot for the first time, that is, print the snapshot to the disaster recovery site for the first time.
  • the snapshot generated at this time is called the zeroth snapshot.
  • the disaster recovery site can generate snapshots to form multiple snapshots corresponding to different times.
  • the snapshot-related content has been described above, and is not repeated here.
  • the production site sends a second request message to the disaster recovery site.
  • the second request message is used to notify the production site of the disaster recovery site to troubleshoot and request the disaster recovery site to perform a disaster recovery operation.
  • the second request message may be sent by the production site when the production site is troubleshooting, or may be sent by another third-party site after monitoring the production site troubleshooting.
  • the disaster recovery site obtains CBT information through CBT technology.
  • the CBT message is incremental information. Specifically, the disaster recovery site obtains CBT information by comparing the N snapshots printed after step 330.
  • the disaster recovery site has printed a total of four snapshots.
  • the above four snapshots are referred to as the zeroth snapshot to the third snapshot, where the zeroth snapshot is the first printed snapshot and corresponds to the first backup copy.
  • the first snapshot is the second print snapshot, and the second snapshot is the same as the third snapshot, and is not repeated here.
  • the first CBT can be obtained by comparing the zeroth snapshot with the first snapshot.
  • FIG. 4 shows a structure of CBT information.
  • Block 410 represents a data block that changed when the first snapshot was generated compared to when the zeroth snapshot was generated.
  • the "1" on block 410 indicates the backup copy identifier corresponding to the first CBT.
  • the backup copy referred to herein may also be understood as a backup copy corresponding to the first snapshot. Or it can also be understood as: "1" can also represent the version number corresponding to the version running at the disaster recovery site at the time of the first snapshot.
  • the block 410 may further include a recording unit for recording a backup copy identifier corresponding to the first CBT.
  • the embodiment of the present application does not specifically limit the size of the recording unit. As an example, the recording unit may occupy four bytes, etc. .
  • Block 440 indicates that the data block has not changed.
  • the CBT information structure shown in FIG. 4 records new information based on the previous CBT, saving CBT block resources, increasing the proportion of useful information in CBT information, and saving bandwidth and storage resources.
  • the disaster recovery site may delete the snapshot to save memory space.
  • the last snapshot may be retained, such as the third snapshot in the embodiment of the present application, and the embodiment of the present application does not specifically limit this.
  • block 420 records the change of data blocks when the second snapshot is generated and when the first snapshot is generated.
  • the second CBT records the data when the second snapshot is generated and when the first snapshot is generated based on the first CBT.
  • block 430 in the third CBT records the changes in the data block when the third snapshot is generated and when the first snapshot is generated.
  • the third CBT is based on the second CBT, and the data is generated when the third snapshot is generated and when the second snapshot is generated.
  • "2" on block 420 and "3" on block 430 can be used to indicate the version number corresponding to the second snapshot and the version number corresponding to the third snapshot, respectively.
  • the above CBT information structure based on the previous CBT, records the new information of this CBT, saving CBT block resources, increasing the proportion of useful information in CBT information, and saving bandwidth resources and storage resources.
  • the format of the CBT information shown in FIG. 4 is only an example. In some implementation manners, the format of the CBT information may also have multiple variations, which are not specifically limited in the embodiment of the present application.
  • step 360 the disaster recovery site sends a first message to the production site, and sends the generated CBT information to the production site.
  • step 370 the production site resumes operation using the received CBT information and the first backup copy.
  • the first backup copy may be a backup copy in a local storage server, or may be a backup copy obtained from another third-party device.
  • the production site needs to make a difference between the above CBTs to obtain the difference information between the CBTs.
  • the production site can use the obtained difference information and the first backup copy to resume production.
  • the first CBT itself is the difference information between the version corresponding to the first snapshot and the version corresponding to the zero snapshot, there is no need to calculate the difference information, and it is recorded as the first difference for the convenience of description.
  • the version corresponding to the first snapshot can be restored according to the first difference, that is, the new data generated when the disaster recovery site generates the first snapshot.
  • the second difference shown in FIG. 5 is the difference between the second CBT and the first CBT, and is actually the difference between the version corresponding to the second snapshot and the version corresponding to the first snapshot. Based on the recovery of the version when the first snapshot is completed, the production site can restore the new data generated when the second snapshot is combined with the second difference.
  • FIG. 4 is the difference between the third CBT and the first CBT, and is actually the difference between the version corresponding to the third snapshot and the version corresponding to the first snapshot;
  • FIG. 5 shows the third difference
  • the four differences are the differences between the third CBT and the second CBT, and are actually the differences between the version corresponding to the third snapshot and the version corresponding to the second snapshot. Therefore, when restoring the version corresponding to the third snapshot, the version corresponding to the first snapshot and the third difference may be used for restoration or the version corresponding to the second snapshot and the fourth difference may be used for restoration. This embodiment of the present application does not do this. Specific limitations.
  • the disaster recovery site in the heterogeneous system can complete the restoration of business at the production site by transmitting incremental data to the production site.
  • the method shown in FIG. 2 to FIG. 5 is only an example, and should not limit the present application.
  • the disaster recovery method provided by the embodiment of the present application is described above, and the production site and the disaster recovery site provided by the embodiment of the present application are described below.
  • FIG. 6 is a schematic block diagram of a disaster recovery site 600 according to an embodiment of the present application.
  • the disaster recovery site 600 includes a selection module 610 for selecting a first backup copy when taking over services at a production site; and a receiving module 620 for: Use a virtual machine to receive business data; an acquisition module 630 is configured to use block modification tracking CBT technology and the received business data to obtain CBT information, where the CBT information includes an increase after the disaster recovery site receives the first backup copy.
  • Quantity information a sending module 640, configured to send a first message to the production site, where the first message includes the CBT information; wherein the storage server in the disaster recovery site and the storage server in the production site Belongs to heterogeneous equipment.
  • the disaster recovery device 600 may further include a generating module 650 for generating N snapshots, where N is greater than or equal to 2; and the acquiring module is further configured to obtain each snapshot in the N snapshots and the snapshot.
  • the difference information between the last snapshots of each snapshot in N snapshots, and the CBT information includes the difference information.
  • the CBT information includes one CBT corresponding to each snapshot in the N snapshots, the Nth snapshot corresponds to an Nth CBT, and the Nth CBT includes each of the first N-1 snapshots Difference information between each snapshot and the last snapshot of each of the first N-1 snapshots.
  • the obtaining module is further configured to delete the first N-1 snapshots and retain the Nth snapshot.
  • FIG. 7 is a schematic block diagram of a production site 700 according to an embodiment of the present application.
  • the production site 700 includes
  • a sending module 710 is configured to send a first backup copy to the disaster recovery site so that the disaster recovery site can take over the services of the production site 700;
  • a receiving module 720 is configured to receive a first message sent by the disaster recovery site, so that The first message includes CBT information, and the CBT information includes incremental information generated since the disaster recovery site takes over the operations of the production site;
  • a recovery module 730 is configured to, according to the first backup copy and the CBT, Information recovery business.
  • the CBT information includes N CBTs, where N is greater than or equal to 1, and the production site 700 further includes an obtaining module 740 for obtaining a difference between each CBT in the N CBTs; the restoration The module is further configured to restore a service according to a difference between the first backup copy and each CBT backup.
  • the production site or the disaster recovery site provided in the embodiment of the present application may be a collection of multiple physical devices or a single physical device in the physical structure, which is not specifically limited in this embodiment of the present application.
  • the terminal site or the network site includes a hardware layer, an operating system layer running on the hardware layer, and an application layer running on the operating system layer.
  • This hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and a memory (also called main memory).
  • the operating system may be any one or more computer operating systems that implement business processing through processes, such as a Linux operating system, a Unix operating system, an Android operating system, an iOS operating system, or a windows operating system.
  • This application layer contains applications such as browsers, address books, word processing software, and instant messaging software.
  • the embodiment of the present application does not specifically limit the specific structure of the execution subject of the method provided by the embodiment of the present application, as long as the program that records the code of the method provided by the embodiment of the present application can be run to provide according to the embodiment of the application
  • the communication may be performed by using the method described above.
  • the method execution subject provided in the embodiments of the present application may be a terminal site or a network site, or a function module in the terminal site or the network site that can call a program and execute the program.
  • various aspects or features of the present application may be implemented as a method, apparatus, or article of manufacture using standard programming and / or engineering techniques.
  • article of manufacture encompasses a computer program accessible from any computer-readable device, carrier, or medium.
  • computer-readable media may include, but are not limited to: magnetic storage devices (eg, hard disks, floppy disks, or magnetic tapes, etc.), optical disks (eg, compact discs (CD), digital versatile discs (DVD) Etc.), smart cards and flash memory devices (for example, erasable programmable read-only memory (EPROM), cards, sticks or key drives, etc.).
  • various storage media described herein may represent one or more sites and / or other machine-readable media used to store information.
  • machine-readable medium may include, but is not limited to, wireless channels and various other media capable of storing, containing, and / or carrying instruction (s) and / or data.
  • the disclosed systems, devices, and methods may be implemented in other ways.
  • the device embodiments described above are only schematic.
  • the division of the unit is only a logical function division.
  • multiple units or components may be combined or Can be integrated into another system, or some features can be ignored or not implemented.
  • the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or units, which may be electrical, mechanical or other forms.
  • the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, may be located in one place, or may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the objective of the solution of this embodiment.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, or each of the units may exist separately physically, or two or more units may be integrated into one unit.
  • the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium.
  • the technical solution of this application is essentially a part that contributes to the existing technology or a part of the technical solution can be embodied in the form of a software product.
  • the computer software product is stored in a storage medium, including Several instructions are used to cause a computer site (which may be a personal computer, a server, or a network site, etc.) to perform all or part of the steps of the method described in the embodiments of the present application.
  • the aforementioned storage media include: U disks, mobile hard disks, read-only memories (ROMs), random access memories (RAMs), magnetic disks or compact discs and other media that can store program codes .

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Retry When Errors Occur (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请提供了一种数据容灾的方法与站点，包括：灾备站点在接管生产站点的业务时，选择第一备份副本；灾备站点利用虚拟机接收业务数据；灾备站点利用块修改跟踪CBT技术以及接收的业务数据得到CBT信息，CBT信息包含灾备站点接收第一备份副本之后的增量信息；所述灾备站点向所述生产站点发送第一消息，所述第一消息中包含所述CBT信息；其中，所述灾备站点中的存储服务器与所述生产站点中的存储服务器属于异构设备。本申请提供的数据容灾方法，相比于传统的全量数据同步具有更少的数据量，能够减少占用带宽，减少恢复目标时间。

Description

数据容灾方法与站点 技术领域
本申请涉及信息处理领域，尤其涉及一种数据容灾方法与站点。
背景技术
数据容灾是信息数据中心建设的热门课题之一。通常情况下，生产站点正常运行时需要向灾备站点发送数据备份。以便当生产站点发生故障时，灾备站点能够接管生产站点的业务。生产站点故障排除时进行灾备站点到生产站点的数据同步，从而恢复业务。
异构场景下，由灾备站点到生产站点的数据同步通常采用全量数据的同步方案。但全量数据的同步导致灾备站点与生产站点之间需要传输的数据量大，占用较大带宽，影响灾难恢复时间目标(recovery time object，RTO)。
发明内容
本申请提供一种数据容灾的方法与站点，能减少容灾过程中灾备站点向生产站点同步的数据量。
第一方面，提供了一种数据容灾方法，所述容灾系统包括生产站点和灾备站点，所述方法包括：所述灾备站点在接管生产站点的业务时，选择第一备份副本；所述灾备站点利用虚拟机接收业务数据；所述灾备站点利用块修改跟踪CBT技术以及接收的业务数据得到CBT信息，所述CBT信息包含所述灾备站点接收所述第一备份副本之后的增量信息；所述灾备站点向所述生产站点发送第一消息，所述第一消息中包含所述CBT信息；其中，所述灾备站点中的存储服务器与所述生产站点中的存储服务器属于异构设备。
容灾过程中灾备站点利用CBT技术生成灾备站接管生产站点业务以来的增量信息，具有相较于全量备份更少的数据量，能够减少传输带宽，减少RTO，提高用户体验。
应理解，上述灾备站点可以由多个服务器构成，其中多个服务器包括上述灾备站点的存储服务器，备份服务器，其他类型的服务器等等；生产站点可以由生产主机，备份服务器，以及存储服务器构成，本申请对此不做具体限定。
应理解，灾备站点可以在生产站点整体出现故障时，接管生产站点的业务，还可以是在生产站点中的主机发生故障时接管生产站点的业务，本申请实施例对此不做具体限定。
结合第一方面，在第一方面的某些实现方式中，所述灾备站点利用块修改跟踪CBT技术以及接收的业务得到所述CBT信息包括：所述灾备站点生成N次快照，所述N大于等于2；所述灾备站点获取所述N次快照中的每次快照与所述N次快照中的每次快照的上次快照之间的差量信息，所述CBT信息中包含所述差量信息。
快照生成速度快，占用空间小，基于快照的CBT技术可以提高备份的速度，进一步减少RTO。
结合第一方面，在第一方面的某些实现方式中，所述CBT信息中包含所述N次快照中每次快照对应的一个CBT所述第N次快照对应第N CBT，所述第N CBT中包含前N-1次快照中的每个快照与所述前N-1次快照中的每个快照的上次快照之间的差量信息。
上述技术方案中对应的CBT的格式，能够提高组成CBT中有用数据块的占比，进一步减小灾备站点向生产站点同步的数据量。
结合第一方面，在第一方面的某些实现方式中，在所述灾备站点获得所述N次快照中的每次快照与其上次快照之间的差量信息之后，所述方法还包括：所述灾备站点删除前N-1次快照，保留第N次快照。
上述技术方案中，灾备站点生产站点在完成备份之后将快照删除可以节省一定的存储空间，优化灾备站点的业务性能。
保留的最后一次快照能够直接作为后续备份的基础，节省了生成快照的时间。
第二方面，提供了一种数据容灾的方法，包括：生产站点向灾备站点发送第一备份副本，以便所述灾备站点接管所述生产站点的业务；所述生产站点接收所述灾备站点发送的第一消息，所述第一消息中包含CBT信息，所述CBT信息包含所述灾备站点接管所述生产站点的业务以来产生的增量信息；所述生产站点根据所述第一备份副本与所述CBT信息恢复业务。
可选地，生产站点生成多个备份副本，并将多个所述备份副本存储于本地存储服务器中。
应理解，将上述多个备份副本存储于本地服务器，且并将多个备份副本发送给灾备站点。使得灾备站点与生产站点具有同一备份数据链，利于实现增量备份。能够完成生产站点中的生产主机发生故障时的容灾过程。
结合第二方面，在一些可能的实现方式中，所述CBT信息中包含N个CBT，所述N大于等于2，所述方法还包括：所述生产站点确定所述N个CBT中各个CBT之间的差量；所述生产站点根据所述第一备份副本与所述各个CBT之间的差量恢复业务。
上述技术方案中，利用不同CBT之间的差量能够使得生产站点快速恢复业务。
第三方面，提供一种灾备站点，包括：选择模块，用于在接管生产站点的业务时，选择第一备份副本；接收模块，用于利用虚拟机接收业务数据；获取模块，用于利用块修改跟踪CBT技术以及所述接收的业务数据得到CBT信息，所述CBT信息包含所述灾备站点接收所述第一备份副本之后的增量信息；发送模块，用于向所述生产站点发送第一消息，所述第一消息中包含所述CBT信息；其中，所述灾备站点中的存储服务器与所述生产站点中的存储服务器属于异构设备。
结合第三方面，在一些可能的实现方式中，灾备站点还包括：生成模块，用于生成N次快照，所述N大于等于2；获取模块，用于获得所述N次快照中的每次快照与所述N次快照中的每次快照的上次快照之间的差量信息，所述CBT信息中包含所述差量信息。
结合第三方面，在一些可能的实现方式中，所述CBT信息中包含所述N次快照中每次快照对应的一个CBT，所述第N次快照对应第N CBT，所述第N CBT中包含前N-1次快照中的每个快照与所述前N-1次快照中的每个快照的上次快照之间的差量信息。
结合第三方面，在一些可能的实现方式中，所述获取模块还用于删除前N-1次快照，保留第N次快照。
第四方面，提供了一种生产站点，包括：发送模块，用于向灾备站点发送第一备份副本，以便所述灾备站点接管所述生产站点的业务；接收模块，用于接收所述灾备站点发送的第一消息，所述第一消息中包含CBT信息，所述CBT信息包含所述灾备站点接管所述生产站点的业务以来产生的增量信息；恢复模块，用于根据所述第一备份副本与所述CBT信息恢复业务。
结合第四方面，在一些可能的实现方式中，所述CBT信息中包含N个CBT，所述N 大于等于1，所述生产站点还包括获取模块，所述获取模块还用于获取所述N个CBT中各个CBT之间的差量；所述恢复模块还用于根据所述第一备份副本与所述各个CBT备份之间的差量恢复业务。
第五方面，提供了一种计算机可读介质，用于存储计算机程序，该计算机程序包括用于执行上述任一方面的任意可能的实现方式中的方法的指令。
第六方面，提供了一种芯片，其中存储有指令，当其在计算机设备上运行时，使得该通信芯片执行上述任一方面的任意可能的实现方式中的方法。
附图说明
图1是一种异构场景下的数据容灾方法的示意性流程图；
图2是本申请实施例提供的异构场景下的数据容灾方法的示意性流程图；
图3是本申请实施例提供的另一异构场景下的数据容灾方法的示意性流程图；
图4是本申请实施例提供一种CBT信息的结构示意图；
图5是本申请实施例提供的CBT之间的差量的结构示意图；
图6是本申请实施例提供的灾备站点的示意性框图；
图7是本申请实施例提供的生产站点的示意性框图。
具体实施方式
数据容灾是信息数据中心建设的热门课题之一。通常情况下，生产站点正常运行时需要向灾备站点发送数据备份。以便当生产站点发生故障时，灾备站点能够接管生产站点的业务。
生产站点故障排除时为了恢复业务，需要进行灾备站点到生产站点的数据同步。在同构的场景下，由于生产站点中的存储服务器与灾备站点中的存储服务器来自同一厂商，因此可以利用阵列的复制技术实现灾备站点接管生产站点业务以来的增量数据的同步。上述增量数据的同步需要传输的数据量少，占用的传输带宽少，因此对应RTO也较小。但在异构场景下，由于生产站点的存储设备与灾备站点的存储设备来自于不同的厂商，需要将灾备站点接管业务以来的全量数据(或者说全量备份)同步回生产站点。但同步全量数据需要传输的数据量大，占用较大带宽，影响RTO。
为了便于理解，下面结合图1介绍异构场景下的通过全量备份同步实现的数据容灾方法。图1是本申请实施例提供的一种异构场景下数据容灾方法的示意图。
作为一个示例，以生产站点为用户IDC，灾备站点为由多个服务器组成的站点为例来说明异构场景下灾备站点向生产站点同步全量数据的数据容灾方法。生产站点中可以包括生产主机、备份服务器、存储服务器等。其中生产主机用于处理生产站点业务，存储服务器用于为生产站点提供存储服务；备份服务器安装有备份软件，用于对生产主机的数据进行备份，并将数据同步给灾备站点；或者备份服务器从存储服务器中读取数据，发送给灾备站点。组成灾备站点的多个服务器在逻辑上可以划分为第一集合和第二集合，第一集合用于提供计算资源，第二集合用于提供存储资源，生产站点中的存储服务器与灾备站点中的存储服务器异构。
参考图1，在步骤S110中，生产站点正常运行，并向灾备站点发送备份副本，灾备站点将备份副本存储于存储服务器中。
生产站点正常运行时，生产站点中的生产主机处理用户相关的业务，为了实现数据容灾，还需要使用备份服务器对生产主机中的数据进行备份，并将备份数据发送给灾备站点。灾备站点将备份副本存储于用于提供存储资源的第二集合中的某个存储服务器中。
在步骤S120中，当生产站点发生故障时，灾备站点基于上述步骤S110中接收到的备份副本恢复虚拟机的操作，并利用恢复出的虚拟机接管生产站点的业务。
在步骤130中，当生产站点故障排除时，灾备站点向生产站点发送数据备份，该数据备份为全量备份，该全量备份不仅包含灾备站点接管生产站点接管业务后新产生的数据，还包括生产站点原本的数据。生产站点根据接收到的全量备份进行容灾恢复。
由于生产站点中的存储服务器与灾备站点中的存储设备异构，因此需要向生产站点的主机发送全量备份，以便生产主机根据全量备份恢复生产。但全量数据的传输使生产站点需要同步的数据量增大，从而导致了传输带宽以及RTO的增大。
为了减少容灾过程中灾备站点向生产站点同步的数据量，本申请实施例提供了一种异构场景下的数据容灾方法。相比于现有的异构场景下容灾过程中灾备站点向生产站点传输全量数据以实现的生产站点业务恢复，本申请中通过传输增量数据可以减少容灾过程中灾备站点向生产站点同步的数据量，节省传输带宽，减少RTO。
下面结合附图，对本申请实施例提供的数据容灾方法进行描述，图2是本申请实施例提供的数据容灾方法的示意性流程图。
参考图2，在步骤S210中：灾备站点接管生产站点的业务。
灾备站点与生产站点均可以为由多个服务器组成的站点；或者灾备站点由多个服务器组成，生产站点为用户IDC；或者还可以是灾备站点为用户IDC，生产站点为企业的服务器等等，本申请实施例对此不做具体限定。
灾备站点在接管生产站点的业务时选择第一备份副本。第一备份副本可以是生产站点发生故障前向灾备站点发送的任一个备份副本。作为一个示例，第一备份副本可以是故障发生前生产站点生成的最后一个备份副本。
第一备份副本可以是生产站点利用备份软件生成，并将其存入生产站点中的存储服务器中。生产站点正常工作的状态下，可以将第一备份副本发送给灾备站点。使得灾备站点与生产站点具有同一备份数据链，利于实现容灾过程中的增量备份。
灾备站点可以基于第一备份副本恢复虚拟机操作，利用虚拟机接管生产站点的业务。使得在生产站点发生故障时，生产站点的业务不会受到影响。
可选地，在接管生产站点的业务之前，灾备站点可以感知生产站点是否发生故障。
具体地，可以是生产站点中的生产主机发生故障，生产站点中的其他服务器通知灾备站点该生产站点发生了故障，或者也可以是生产站点中整体发生故障，第三方的站点在监测到生产站点发生故障或者需要进行计划性切换时，通知给容灾站点，或者还可以是容灾站点监测到生产站点发生故障操时，直接进行容灾操作等等，本申请实施例对此不做具体限定。
在步骤S220中，灾备站点利用CBT技术以及接受的业务数据得到CBT信息，CBT信息包含灾备站点接收到第一备份副本之后的增量信息。
灾备站点在基于第一备份副本恢复虚拟机操作，利虚拟机接管生产站点的业务，并产生新的业务数据，即增量信息。增量信息也可以理解为相对于第一备份副本的增量信息。灾备站点可以利用CBT技术得到CBT信息，该CBT信息包含灾备站点接管业务以来的 增量信息。换句话说，灾备站点通过CBT技术实现增量备份。
可选地，灾备站点利用CBT技术得到CBT信息包括：灾备站点生成N次快照(snapshot)，所述N大于等于2，灾备站点通过对比N次快照中每次快照与其上次快照得到两次快照之间的差量信息，或者是生产站点的不同时间下的两个版本之间的差量信息，并将所述差量信息保存在CBT信息中。
快照(又称为存储快照)是数据在某一个时间点的映像，通过对比快照可以得到数据在某一时间点相对于另一时间点的变化。CBT技术基于快照对比判断在一段时间内是否有数据块被修改，并对被修改的数据块进行标记或者记录。
应理解，本申请实施例对于灾备站点生成快照的频率、时间点均不做具体限定。例如，可以是在灾备站点基于第一备份副本恢复虚拟机操作，利用虚拟机接管生产站点业务之前，即相对于第一备份副对应的版本产生新的数据之前的某一时间点生成第一次快照，在此之后可以以某一固定频率生成快照，或者还可以是用户决定对灾备站点进行备份，根据用户的需要使灾备站点生成快照等等。
还应理解，本申请实施例对于快照的种类不做具体限定，例如可以是镜像分离(split mirror)快照，可以是写时拷贝(copy-on-write)快照，还可以是写时重定向(redirect-on-write)快照等等。
利用CBT技术基于快照生成的CBT信息还可以有多种格式。例如，CBT信息中可以包含N次快照中每次快照对应的一个CBT，所述第N次快照对应第N CBT。第N CBT中包含前N-1次快照中每次快照相对于该前N-1次快照之间的差量信息。或者还可以是CBT信息中包含N次快照中每次快照对应的一个CBT，所述第N次快照对应第N CBT。第N CBT中包含第N次快照与第N-1次快照之间的差量信息等等，本申请实施例对此不做具体限定。
上述CBT信息结构，在上一次CBT的基础上，记录本次CBT的新增信息，节省了CBT块资源，增大CBT信息中有用信息的占比，节省带宽资源与存储资源。
可选地，灾备站点在完成增量备份之后可以删除前N-1次快照，保留第N次快照。
灾备站点生产站点在完成备份之后将快照删除可以节省一定的存储空间，优化灾备站点的业务性能。保留的最后一次快照能够直接作为后续备份的基础，节省了生成快照的时间。
在步骤S230中，灾备站点向生产站点发送第一消息。其中第一消息中包含CBT信息。
在生产站点故障排除后，灾备站点向生产站点同步数据的过程中，传输增量数据相比于传统的传输全量数据具有更少的传输数据量，可以降低带宽的占用，减少RTO。
可选地，在步骤240中，生产站点在接收到第一消息之后，可以利用已有第一备份副本与接收到的第一消息中的CBT信息恢复业务。其中，CBT信息是在业务转移到灾备站点后产生的增量信息，生产站点根据第一备份副本以及CBT信息可以恢复业务，即生产站点可以根据故障前的备份以及灾备站点接管业务后产生的增量数据，于故障后恢复业务。
为了便于理解，下面结合图3详细说明异构系统下，灾备站点向生产站点同步增量数据的方案。图3是一种异构场景下灾备站点向生产站点实现增量数据同步的示意性流程图。图3中的灾备站点与生产站点组成异构系统，图3中的生产站点为用户IDC，灾备站点由多个服务器组成。生产站点为用户IDC时，生产站点中可以包括，生产主机，用于处 理用户相关业务；存储服务器，用于为生产站点提供存储服务；备份服务器，该备份服务器上安装有备份软件，用于对生产主机备份。或者备份服务器存储服务器中读取数据，发送给灾备站点。所述多个服务器包括第一集合和第二集合，第一集合用于提供计算资源，第二集合用于提供存储资源。灾备站点中的存储设备与生产站点中的存储设备属于异构设备。
应理解，本申请实施例所涉及的服务器可以是一个具有独立物理结构的服务器，还可以是服务器上的一个软件化实例，本申请实施例对此不做具体限定。
下面结合图3中示出的步骤S310-S370详细介绍本申请实施例提供的数据容灾方法。
在步骤S310中：生产站点向灾备站点同步备份副本。
生产站点将存储服务器中的备份副本同步给灾备站点，灾备站点可以将接收到的备份副本存储于组成第二合集的任一个存储服务器中。例如，该存储服务器可以是云上对象存储服务(object storage service，OBS)。
上述备份副本可以是由生产站点在正常工作的情况下生成的备份副本。生产站点可以将该备份副本存储于生产站点的存储服务器中。
在步骤320中：生产站点向灾备站点发送第一请求消息，请求灾备站点进行容灾切换操作。
具体地，可以是生产站点中的生产主机发生故障，生产站点中的其他服务器向灾备站点发送第一请求消息，请求灾备站点进行容灾操作，或者也可以是生产站点中整体发生故障，第三方的站点在监测到生产站点发生故障或者需要进行计划性切换时，通知给容灾站点，或者还可以是灾备站点监测到生产站点发生故障操时，直接进行容灾操作等等，本申请实施例对此不做具体限定。
在步骤330中：灾备站点在接管生产站点的业务时，选择第一备份副本。
第一备份副本可以是灾备站点与生产站点相关的备份副本中的任意一个，根据不同的备份副本可以恢复出不同版本。
灾备站点基于其多个服务器中的任意一个生成虚拟机，例如可以是基于云服务器生成的虚拟机。利用虚拟机接管与生产站点相关的业务，具体地，可以是虚拟机基于第一备份副本运行从而接管与生产站点相关的业务。
在虚拟机接管生产站点的业务之前，换句话说，在灾备站点恢复第一备份副本对应的版本，但未产生新的数据之前。灾备站点可以第一次生成快照，即首次对灾备站点打印快照。为了便于理解，将此时生成的快照称为第零快照。
在接管生产站点的业务之后，灾备站点可以生成快照，形成不同时间对应的多个快照，上文已经对快照相关的内容进行描述，此处不再赘述。
在步骤340中，生产站点向灾备站点发送第二请求消息。第二请求消息用于通知灾备站点生产站点故障排除，请求灾备站点进行容灾回切操作。第二请求消息可以是生产站点故障排除时由生产站点发送的，还可以是其他的第三方站点在监测到生产站点故障排除后发送的。
在步骤350中，灾备站点通过CBT技术获得CBT信息。该CBT消息为增量信息。具体地，灾备站点通过在步骤330之后打印的N次快照进行对比获得CBT信息。
为了便于理解，下面结合图4详细描述生成CBT信息的过程。
假设灾备站点共打印了四次快照，为了便于理解将上述四次快照分别称为第零快照至 第三快照，其中第零快照为第一次打印的快照，其与第一备份副本对应。第一快照是第二次打印的快照，第二快照与第三快照同理，此处不再赘述。
通过第零快照与第一快照的对比可以获得第一CBT，图4中示出了一种CBT信息的结构。块410表示生成第一快照时相比于生成第零快照时发生变化的数据块。块410上的“1”表示第一CBT对应的备份副本标识。此处所指的备份副本也可以理解为第一快照对应的备份副本。或者也可以理解为：“1”也可以表示第一快照时的灾备站点所运行的版本对应的版本号。在块410中还可以包含记录单元，用于记录第一CBT对应的备份副本标识，本申请实施例对记录单元的大小不做具体限定，作为一个示例，记录单元可以占用四个字节等等。块440表示数据块未发生变化。
图4中示出的CBT信息结构，在上次CBT的基础上记录新增的信息，节省了CBT块资源，增大CBT信息中有用信息的占比，同时节省带宽与存储资源。
可选地，上述快照完成与其相邻的快照之间的对比之后，灾备站点可以将快照删除，以节省内存空间。当然为了保证下次备份可用，可以保留最后一次快照，例如本申请实施例中的第三快照等等，本申请实施例对此不做具体限定。
同理，第二CBT与第三CBT也是通过类似方法得到。如图4所示，块420记录了生成第二快照时与生成第一快照时数据块的变化，第二CBT在第一CBT的基础上，记录生成第二快照时与生成第一快照时数据块的变化。同理第三CBT中的块430记录了生成第三快照时与生成第一快照时数据块的变化，第三CBT在第二CBT的基础上，生成第三快照时与生成第二快照时数据块的变化，同理块420上的“2”与块430上的“3”可以分别用来表示第二快照对应的版本号与第三快照对应的版本号。
上述CBT信息结构，在上一次CBT的基础上，记录本次CBT的新增信息，节省了CBT块资源，增大CBT信息中有用信息的占比，同时节省带宽资源与存储资源。
应理解，图4中示出的CBT信息的格式仅仅是一种示例，在一些实现方式中，CBT信息的格式还可以产生多种变形，本申请实施例对此不做具体限定。
应理解，本申请实施例对上述步骤S340与S350的执行顺序不做具体限定。
在步骤360中：灾备站点向生产站点发送第一消息，将生成的CBT信息发送给生产站点。
在步骤370中：生产站点利用接收到的CBT信息，以及第一备份副本，恢复运行。第一备份副本可以是本地存储服务器中的备份副本，还可以是从其他第三方设备中获取的备份副本。
具体地，当CBT信息是上述图4中的格式时，生产站点需要将上述各个CBT之间做差值，得到CBT间的差值信息。生产站点利用得到的差值信息以及第一备份副本可以恢复生产。
为了便于理解，下面结合图5描述生产站点得到CBT差量信息的过程：
由于第一CBT本身为第一快照对应版本与第零快照对应版本的差量信息，因此不需要对其求差量信息，为了便于描述将其记为第一差量。生产站点基于第一备份副本运行之后，根据第一差量可以恢复第一快照时对应的版本，即恢复灾备站点生成第一快照时产生的新的数据。图5中示出的第二差量，为第二CBT与第一CBT的差值，实际为第二快照对应版本与第一快照对应版本之间的差量。生产站点在完成了第一快照时对应的版本恢复的基础上，结合第二差量可以恢复第二快照时生成时的新数据。图4中示出的第三差量为 第三CBT与第一CBT的差量，实际上为第三快照对应的版本与第一快照对应的版本之间的差量；图5中示出第四差量为第三CBT与第二CBT之间的差量，实际上为第三快照对应的版本与第二快照对应版本之间的差量。因此在恢复第三快照对应的版本时，可以使用第一快照对应的版本与第三差量来恢复或者使用第二快照对应的版本与第四差量来恢复，本申请实施例对此不做具体限定。
应理解，上述版本可以理解为快照时刻的灾备站点运行的版本。
还应理解，如果CBT信息的格式与图4中的格式不同，则生产站点恢复运行的方法也有所不同，本申请实施例对此不做具体限定。
通过上述步骤S310-S370即可完成异构系统下灾备站点向生产站点通过传输增量数据从而完成生产站点业务的恢复。当然图2-图5示出的方法仅仅是一个示例，并不应对本申请造成限定。
上文描述了本申请实施例提供的容灾方法，下文将描述本申请实施例提供的生产站点与灾备站点。
图6为本申请实施例提供的灾备站点600的示意性框图，该灾备站点600包括选择模块610，用于在接管生产站点的业务时，选择第一备份副本；接收模块620，用于利用虚拟机接收业务数据；获取模块630，用于利用块修改跟踪CBT技术以及所述接收的业务数据得到CBT信息，所述CBT信息包含所述灾备站点接收所述第一备份副本之后的增量信息；发送模块640，用于向所述生产站点发送第一消息，所述第一消息中包含所述CBT信息；其中，所述灾备站点中的存储服务器所述生产站点中的存储服务器属于异构设备。
可选地，灾备设备600还可以包括生成模块650，用于生成N次快照，所述N大于等于2；所述获取模块还用于获得所述N次快照中的每次快照与所述N次快照中的每次快照的上次快照之间的差量信息，所述CBT信息中包含所述差量信息。
可选地，所述CBT信息中包含所述N次快照中每次快照对应的一个CBT所述第N次快照对应第N CBT，所述第N CBT中包含前N-1次快照中的每个快照与所述前N-1次快照中的每个快照的上次快照之间的差量信息。
可选地，所述获取模块还用于删除前N-1次快照，保留第N次快照。
图7为本申请实施例提供的生产站点700的示意性框图，该生产站点700包括
发送模块710，用于向灾备站点发送第一备份副本，以便所述灾备站点接管所述生产站点700的业务；接收模块720，用于接收所述灾备站点发送的第一消息，所述第一消息中包含CBT信息，所述CBT信息包含所述灾备站点接管所述生产站点的业务以来产生的增量信息；恢复模块730，用于根据所述第一备份副本与所述CBT信息恢复业务。
可选地，所述CBT信息中包含N个CBT，所述N大于等于1，生产站点700还包括获取模块740，用于获取所述N个CBT中各个CBT之间的差量；所述恢复模块还用于根据所述第一备份副本与所述各个CBT备份之间的差量恢复业务。
应理解，本申请实施例提供的生产站点或灾备站点在物理结构上可以是多个物理设备的集合还可以是一个单独的物理设备，本申请实施例对此不做具体限定。
在本申请实施例中，终端站点或网络站点包括硬件层、运行在硬件层之上的操作系统层，以及运行在操作系统层上的应用层。该硬件层包括中央处理器(central processing unit，CPU)、内存管理单元(memory management unit，MMU)和内存(也称为主存)等硬件。该操作系统可以是任意一种或多种通过进程(process)实现业务处理的计算机操作系统， 例如，Linux操作系统、Unix操作系统、Android操作系统、iOS操作系统或windows操作系统等。该应用层包含浏览器、通讯录、文字处理软件、即时通信软件等应用。并且，本申请实施例并未对本申请实施例提供的方法的执行主体的具体结构特别限定，只要能够通过运行记录有本申请实施例的提供的方法的代码的程序，以根据本申请实施例提供的方法进行通信即可，例如，本申请实施例提供的方法的执行主体可以是终端站点或网络站点，或者，是终端站点或网络站点中能够调用程序并执行程序的功能模块。
另外，本申请的各个方面或特征可以实现成方法、装置或使用标准编程和/或工程技术的制品。本申请中使用的术语“制品”涵盖可从任何计算机可读器件、载体或介质访问的计算机程序。例如，计算机可读介质可以包括，但不限于:磁存储器件(例如，硬盘、软盘或磁带等)，光盘(例如，压缩盘(compact disc，CD)、数字通用盘(digital versatile disc，DVD)等)，智能卡和闪存器件(例如，可擦写可编程只读存储器(erasable programmable read-only memory，EPROM)、卡、棒或钥匙驱动器等)。另外，本文描述的各种存储介质可代表用于存储信息的一个或多个站点和/或其它机器可读介质。术语“机器可读介质”可包括但不限于，无线信道和能够存储、包含和/或承载指令和/或数据的各种其它介质。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机站点(可以是个人计算机，服务器，或者网络站点等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (10)

  1. 一种数据容灾方法，其特征在于，所述方法应用于容灾系统中，所述容灾系统包括生产站点和灾备站点，所述方法包括：
    所述灾备站点在接管生产站点的业务时，选择第一备份副本；
    所述灾备站点利用虚拟机接收业务数据；
    所述灾备站点利用块修改跟踪CBT技术以及接收的业务数据得到CBT信息，所述CBT信息包含所述灾备站点接收所述第一备份副本之后的增量信息；
    所述灾备站点向所述生产站点发送第一消息，所述第一消息中包含所述CBT信息；
    其中，所述灾备站点中的存储服务器与所述生产站点中的存储服务器属于异构设备。
  2. 根据权利要求1所述的方法，其特征在于，所述灾备站点利用块修改跟踪CBT技术以及接收的业务数据得到所述CBT信息包括：
    所述灾备站点生成N次快照，所述N大于等于2；
    所述灾备站点获得所述N次快照中的每次快照与所述N次快照中的每次快照的上次快照之间的差量信息，所述CBT信息中包含所述差量信息。
  3. 根据权利要求2所述的方法，其特征在于，所述CBT信息中包含所述N次快照中每次快照对应的一个CBT，所述第N次快照对应第N CBT，所述第N CBT中包含前N-1次快照中的每个快照与所述前N-1次快照中的每个快照的上次快照之间的差量信息。
  4. 根据权利2或3所述的方法，其特征在于，在所述灾备站点获得所述N次快照中的每次快照与其上次快照之间的差量信息之后，所述方法还包括：
    所述灾备站点删除前N-1次快照，保留第N次快照。
  5. 一种灾备站点，其特征在于，所述灾备站点包括：
    选择模块，用于在接管生产站点的业务时，选择第一备份副本；
    接收模块，用于利用虚拟机接收业务数据；
    获取模块，用于利用块修改跟踪CBT技术以及所述接收的业务数据得到CBT信息，所述CBT信息包含所述灾备站点接收所述第一备份副本之后的增量信息；
    发送模块，用于向所述生产站点发送第一消息，所述第一消息中包含所述CBT信息；
    其中，所述灾备站点中的存储服务器所述生产站点中的存储服务器属于异构设备。
  6. 根据权利要求5所述的灾备站点，其特征在于，所述灾备站点还包括：
    生成模块，用于生成N次快照，所述N大于等于2；
    所述获取模块还用于获得所述N次快照中的每次快照与所述N次快照中的每次快照的上次快照之间的差量信息，所述CBT信息中包含所述差量信息。
  7. 根据权利要求6所述的灾备站点，其特征在于，所述CBT信息中包含所述N次快照中每次快照对应的一个CBT所述第N次快照对应第N CBT，所述第N CBT中包含前N-1次快照中的每个快照与所述前N-1次快照中的每个快照的上次快照之间的差量信息。
  8. 根据权利6或7所述的灾备站点，其特征在于，所述获取模块还用于删除前N-1次快照，保留第N次快照。
  9. 一种计算机可读介质，用于存储计算机程序，该计算机程序包括用于执行1-4中任一项所述方法的指令。
  10. 一种芯片，其中存储有指令，当其在计算机设备上运行时，使得该芯片执行1-4中任一项所述的方法。
PCT/CN2019/107620 2018-09-26 2019-09-25 数据容灾方法与站点 Ceased WO2020063600A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP19865699.3A EP3848809A4 (en) 2018-09-26 2019-09-25 DISASTER DATA RECOVERY PROCESS AND SITE
US17/211,906 US11947429B2 (en) 2018-09-26 2021-03-25 Data disaster recovery method and site

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201811125060.0 2018-09-26
CN201811125060.0A CN109491832A (zh) 2018-09-26 2018-09-26 数据容灾方法与站点

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/211,906 Continuation US11947429B2 (en) 2018-09-26 2021-03-25 Data disaster recovery method and site

Publications (1)

Publication Number Publication Date
WO2020063600A1 true WO2020063600A1 (zh) 2020-04-02

Family

ID=65689990

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/107620 Ceased WO2020063600A1 (zh) 2018-09-26 2019-09-25 数据容灾方法与站点

Country Status (4)

Country Link
US (1) US11947429B2 (zh)
EP (1) EP3848809A4 (zh)
CN (1) CN109491832A (zh)
WO (1) WO2020063600A1 (zh)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109491832A (zh) 2018-09-26 2019-03-19 华为技术有限公司 数据容灾方法与站点
CN110677469B (zh) * 2019-09-23 2022-07-15 上交所技术有限责任公司 一种证券灾备系统及灾备实现方法
CN111190771B (zh) * 2019-12-27 2023-02-28 柏科数据技术（深圳）股份有限公司 一种用于灾备的block追踪技术
CN114416703B (zh) * 2020-10-28 2025-03-28 北京中祥英科技有限公司 数据完整性自动监控方法、装置、设备及介质
CN112882859A (zh) * 2021-02-07 2021-06-01 上海英方软件股份有限公司 一种虚拟机合成备份方法及系统
CN113672350B (zh) * 2021-08-20 2023-12-29 深信服科技股份有限公司 一种应用处理方法、装置及相关设备
CN115277376B (zh) * 2022-09-29 2022-12-23 深圳华锐分布式技术股份有限公司 灾备切换方法、装置、设备及介质
US12536074B2 (en) 2023-05-09 2026-01-27 Saudi Arabian Oil Company System and method for secure proactive activation of a disaster recovery system

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105487940A (zh) * 2015-11-18 2016-04-13 华为技术有限公司 灾备端、生产端及两者之间的数据恢复方法
CN106445735A (zh) * 2016-08-31 2017-02-22 上海爱数信息技术股份有限公司 VMware虚拟机的数据恢复方法、系统
WO2018023994A1 (zh) * 2016-08-05 2018-02-08 华为技术有限公司 一种容灾切换的方法、节点及系统
CN108512693A (zh) * 2018-02-24 2018-09-07 国家计算机网络与信息安全管理中心 一种跨区域容灾方法和装置
CN109491832A (zh) * 2018-09-26 2019-03-19 华为技术有限公司 数据容灾方法与站点

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4668763B2 (ja) * 2005-10-20 2011-04-13 株式会社日立製作所 ストレージ装置のリストア方法及びストレージ装置
CN101635638B (zh) * 2008-07-25 2012-10-17 中兴通讯股份有限公司 一种容灾系统及其容灾方法
CN103222220B (zh) * 2012-10-31 2015-09-09 华为技术有限公司 网络数据的回退方法及设备
CN103810058B (zh) * 2012-11-12 2017-02-22 华为技术有限公司 虚拟机备份方法、设备及系统
ES2669274T3 (es) * 2013-12-12 2018-05-24 Huawei Technologies Co., Ltd. Método de réplica de datos y sistema de almacenamiento
US20160048408A1 (en) * 2014-08-13 2016-02-18 OneCloud Labs, Inc. Replication of virtualized infrastructure within distributed computing environments
US9619172B1 (en) * 2014-09-22 2017-04-11 EMC IP Holding Company LLC Method and system for managing changed block tracking and continuous data protection replication
US20160125059A1 (en) * 2014-11-04 2016-05-05 Rubrik, Inc. Hybrid cloud data management system
US9575849B2 (en) * 2014-11-25 2017-02-21 Sap Se Synchronized backup and recovery of database systems
US10496487B1 (en) * 2014-12-03 2019-12-03 EMC IP Holding Company LLC Storing snapshot changes with snapshots
CN104484480B (zh) * 2014-12-31 2018-06-05 华为技术有限公司 基于重复数据删除的远程复制方法及装置
US10705917B2 (en) * 2015-06-30 2020-07-07 Veritas Technologies Llc Consolidated full backup of a restored virtual machine
EP3223158B1 (en) * 2016-02-01 2020-04-22 Huawei Technologies Co., Ltd. Data recovery method and storage system
CN108255641B (zh) * 2017-12-25 2020-08-18 南京壹进制信息科技有限公司 一种基于云平台的cdp容灾方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105487940A (zh) * 2015-11-18 2016-04-13 华为技术有限公司 灾备端、生产端及两者之间的数据恢复方法
WO2018023994A1 (zh) * 2016-08-05 2018-02-08 华为技术有限公司 一种容灾切换的方法、节点及系统
CN106445735A (zh) * 2016-08-31 2017-02-22 上海爱数信息技术股份有限公司 VMware虚拟机的数据恢复方法、系统
CN108512693A (zh) * 2018-02-24 2018-09-07 国家计算机网络与信息安全管理中心 一种跨区域容灾方法和装置
CN109491832A (zh) * 2018-09-26 2019-03-19 华为技术有限公司 数据容灾方法与站点

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3848809A4 *

Also Published As

Publication number Publication date
US11947429B2 (en) 2024-04-02
US20210208982A1 (en) 2021-07-08
EP3848809A4 (en) 2022-05-18
CN109491832A (zh) 2019-03-19
EP3848809A1 (en) 2021-07-14

Similar Documents

Publication Publication Date Title
WO2020063600A1 (zh) 数据容灾方法与站点
US11429305B2 (en) Performing backup operations using replicas
US9336230B1 (en) File replication
CN111078667B (zh) 一种数据迁移的方法以及相关装置
US9563517B1 (en) Cloud snapshots
US8600945B1 (en) Continuous data replication
US9740572B1 (en) Replication of xcopy command
US11579986B2 (en) Data query method and apparatus
US8521694B1 (en) Leveraging array snapshots for immediate continuous data protection
CN106407356B (zh) 一种数据备份方法及装置
US9535907B1 (en) System and method for managing backup operations of virtual machines
US9256605B1 (en) Reading and writing to an unexposed device
US9940205B2 (en) Virtual point in time access between snapshots
US9557925B1 (en) Thin replication
US9672117B1 (en) Method and system for star replication using multiple replication technologies
US8725691B1 (en) Dynamic LUN resizing in a replication environment
US11080148B2 (en) Method and system for star replication using multiple replication technologies
CN107256182B (zh) 一种数据库还原的方法及设备
US9619172B1 (en) Method and system for managing changed block tracking and continuous data protection replication
US10725967B1 (en) Continuous data protection snapshots
JP2008171387A (ja) 継続的データ保護を備えたバックアップシステム
US10592128B1 (en) Abstraction layer
CN109753381B (zh) 一种基于对象存储的持续数据保护方法
WO2022033269A1 (zh) 数据处理的方法、设备及系统
CN107025149A (zh) 虚拟机备份恢复系统及方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19865699

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2019865699

Country of ref document: EP

Effective date: 20210426

ENP Entry into the national phase

Ref document number: 2019865699

Country of ref document: EP

Effective date: 20210406