Feature overview

更新时间:
复制 MD 格式

This topic describes disk asynchronous replication for disaster recovery and explains its basic capabilities and value.

Function overview

The Cloud Backup service uses disk asynchronous replication technology to provide cross-region or cross-zone disaster recovery capabilities for various business needs.

This technology is implemented at the disk layer through asynchronous replication. You do not need to install an agent on the protected instances.

If the primary system fails, the business system fails over to the disaster recovery system. This process effectively prevents system failures caused by regional disasters, ensures business availability, and meets core metrics such as Recovery Time Objective (RTO) and Recovery Point Objective (RPO).

Disk asynchronous replication is a feature that uses the data replication capability of Elastic Block Storage to protect data across regions or zones. For more information, see How disk async replication works.

The following table compares disk asynchronous replication technology with Continuous Data Replication (CDR) disaster recovery.

Comparison Items

Continuous Replication Disaster Recovery

Disaster recovery using disk async replication

Primary scenarios

Suitable for disaster recovery for a single virtual machine (VM). Suitable for customers who do not mind system intrusion.

Suitable for consistent disaster recovery for VM groups. Suitable for customers who prefer no system intrusion.

System intrusion

Yes

No

Implementing replication

An agent is installed on the protected instance and embedded into the OS. The agent replicates data written to the disk in real time and sends it to a gateway. The gateway transfers the data to OSS for storage. The data is finally written to the disks at the disaster recovery site.

Data replication is achieved through mechanisms such as disk asynchronous replication and snapshots in Elastic Block Storage.

Recovery method

Supports multiple recovery points.

The secondary site creates a shadow ECS instance and a gateway instance for the protected instance. It pulls data from the data transit station and writes the data through the shadow ECS. Recovery points are then created based on the snapshot mechanism.

Supports only a single recovery point.

A recovery point is generated by copying a snapshot to the secondary site.

Consistency protection group

Not supported

Supported

Disaster Recovery Advantages

Agentless

The agentless data replication technology provides zero system intrusion, is OS-agnostic, and consumes no computing resources at the disaster recovery site.

Multi-machine consistency

This feature provides multi-instance consistency to meet the strict requirements of enterprise applications.

Easy to understand

The process is application-centric. You can create a protection group and add all ECS instances for a specific application to the group to start replication. You do not need to manage the relationship between ECS instances and disks. The Cloud Backup service handles the mapping between ECS instances and disks in the background.

Terms

Term

English

Description

Site pair

Site Pair

For cross-region or cross-zone disaster recovery, data must be replicated from one site to another. These two sites must be paired. This is called a site pair. You can create multiple protection groups for each site pair. The protection groups in a site pair can only have one forward protection direction. For example, if protection group A fails over to protection group B, the forward protection is from Region 1 to Region 2. If protection group C fails over to protection group D, the forward protection is from Region 2 to Region 1. In this case, you must create two site pairs. A protection group can belong to only one site pair.

A site pair can use only one replication technology.

Protection group

  • Protected Group (PG)

  • Consistent Protected Group (CPG)

  • A protection group can contain multiple ECS instances. This lets you use a single plan to perform operations on multiple ECS instances at the same point in time. You can select a normal type (no association between multiple VMs) or a consistent group type.

  • All ECS instances in a protection group must use the same underlying disaster recovery technology, either CDR or EBS replication. You must select the underlying technology when you create the protection group.

  • The normal statuses of a protection group include Starting Replication, Full Replication in Progress, Incremental Replication in Progress, Switching, Failover Completed, Reverse Replication in Progress, Failing Back, and Failback Completed. Abnormal statuses include Replication Error, Switchover Failed, and Recovery Failed.

  • All protected instances in a protection group must have the same role because all ECS instances in the group can only fail over together.

Protected instance

Protected Instance

A protected ECS instance or a database that will be supported in the future. Roles are divided into Primary and Secondary. Primary refers to the instance that is currently running the business. Secondary refers to the instance that is currently used for disaster recovery.

Production site

Production Site

The zone or region where the user's production business initially runs.

Disaster recovery site

DR Site

The zone or region that the user uses for production business disaster recovery.

Failover

Failover

The process of switching the business to the disaster recovery site when the production site fails. There are two types: planned failover and unplanned failover. The difference is whether the ECS instances at the production site are down at the time of the switch.

Fault Recovery

Failback

The process of switching the business from the disaster recovery site back to the production site after the production site has recovered from a failure.

Forward protection

Forward

A status for protection groups and ECS instances. Production site data and business are replicated to the disaster recovery site.

Reverse protection

Reverse

A status for protection groups and ECS instances. After a failover, the disaster recovery site B becomes the "production site", and the production site A becomes the "disaster recovery site". When protection is restarted, data replication is reversed from the initial direction. The direction is B to A. This is called reverse protection. After a failback, A returns to the production site status, and B returns to the disaster recovery site status. When replication is started from A to B, it returns to the forward protection status.

Technical architecture

The following figure shows the disaster recovery technical architecture based on CDR and disk asynchronous replication.

image

Supported disaster recovery scenarios

Disaster recovery scenario

Supported type

Failover

  • Switch after data synchronization

    This failover first stops the protected instances in the protection group. It waits for all protected instances to stop before performing a final round of data synchronization. The switch starts after data synchronization is complete. This ensures that the data at the disaster recovery site is identical to the data at the production site, with no data loss. This switchover mode is suitable for scenarios such as planned disaster recovery drills and business migration.

  • Switch immediately

    This failover attempts to stop the protected instances in the protection group. It does not wait for all protected instances to stop and does not perform a final round of data synchronization. Some data within the RPO range is lost. This mode is suitable for scenarios where the production site experiences a failure that cannot be recovered quickly and the business must be immediately switched to the disaster recovery site.

Fault recovery

  • Switch after data synchronization

    This failback stops the protected instances in the protection group. It waits for all protected instances to stop before performing a final round of data synchronization. The recovery starts after data synchronization is complete. The service unavailability time is longer than that of an immediate switch. This is mainly used in scenarios where the production site is working normally.

  • Switch immediately

    This failback attempts to stop the protected instances in the protection group. It does not wait for all protected instances to stop and does not perform a final round of data synchronization. The recovery starts immediately, which causes some data loss. This is mainly used in scenarios where the disaster recovery site experiences a failure that cannot be recovered quickly and the business must be immediately recovered to the production site.

Usage flow

Implement disaster recovery protection for critical applications in the Cloud Backup console by completing the following steps:

  1. Plan resources.

    Plan the required compute, network, and storage resources: number of servers, storage capacity, and VPCs.

  2. Create a disaster recovery site pair.

    Create VPCs and vSwitches for the disaster recovery site and configure CIDR blocks. For testing, use default configurations or the same VPC and vSwitch CIDR blocks as the production site. For actual disaster recovery, configure CIDR blocks as required.

  3. Configure network and security settings.

    Create resource mappings: zone mapping, vSwitch mapping, and security group mapping.

  4. Create a protection group.

  5. Add protected instances.

    Add the instances to be protected.

  6. Start replication.

    Start disaster recovery protection to replicate data from the production site to the disaster recovery site.

    Note

    Perform a fault drill when the protection group is in Incremental Replication status or has a recovery point. See Fault drill.

  7. Perform a failover.

    • Switch after data synchronization

      Cloud Backup stops protected instances, performs final data synchronization, then starts the failover. Data at the disaster recovery site matches the production site. Use for planned fault drills and business migration.

    • Switch now

      Cloud Backup attempts to stop protected instances and does not wait for full synchronization. Some data within the RPO may be lost. Use when the production site cannot be restored quickly and you must switch to the disaster recovery site immediately.

Billing

The following fees are incurred when you use disaster recovery with disk async replication:

  • Cloud Backup charges a software usage fee for disaster recovery.

    Fees are charged based on the number of instances. For more information, see Pricing.

  • ECS charges for pay-as-you-go resources created at the disaster recovery site, such as ECS instances and disks. For more information, see Pay-as-you-go.

  • ECS charges fees for cross-region replication traffic on a pay-as-you-go basis. For more information, see Cloud Disk Disaster Recovery.