Core capabilities and benefits of disaster recovery using async replication-Hybrid Disaster Recovery(HDR)-阿里云帮助中心

This topic describes disaster recovery using asynchronous replication and its core capabilities and benefits.

Function overview

Hybrid Disaster Recovery (HDR) uses asynchronous replication technology for disks to provide cross-region or cross-zone disaster recovery. This feature is designed to meet various business requirements.

This technology uses asynchronous replication at the disk layer. Because it is agentless, you do not need to install an agent on 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 Recovery Time Objective (RTO) and Recovery Point Objective (RPO) metrics.

Asynchronous replication for disks is a feature that uses the data replication capabilities of block storage to protect data across regions or zones. For more information, see How async replication for disks works.

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

Comparison Criterion	Continuous Data Replication (CDR)	Disaster recovery using async replication
Primary supported scenarios	Suitable for disaster recovery of a single virtual machine. Ideal for customers who do not mind system intrusion.	Suitable for disaster recovery with VM group consistency. Ideal for customers who want an agentless solution.
System intrusion	Yes	No
Replication method	An agent is installed on the protected instance and embedded in the OS. The agent replicates data written to the disk in real time and sends it to a gateway. The gateway stores the data in OSS, which acts as a transit station, and then writes the data to the disks at the disaster recovery site.	Data replication is achieved through mechanisms such as async replication and snapshots for Elastic Block Storage disks.
Implementing recovery	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 it through the shadow ECS. Recovery points are then created based on snapshots.	Supports only a single recovery point. A recovery point is generated by replicating a snapshot to the secondary site.
Consistency protection group	Not supported	Supported

Disaster Recovery Advantages

Agentless

The agentless data replication technology provides a non-intrusive solution that is compatible with any operating system (OS). It consumes zero compute resources at the disaster recovery site.

Multi-machine consistency

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

Easy to understand

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

Terms

Term	English	Description
Site Pair	Site Pair	A concept for regions or zones that have a protection group relationship. The disaster recovery direction for protection groups in a site pair is only one-way (forward protection). For example, if protection group A fails over to protection group B, forward protection is from Region 1 to Region 2. If protection group C fails over to protection group D, and forward protection is from Region 2 to Region 1, 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 customers use a single plan to perform operations on multiple ECS instances at the same point in time. Customers can choose a normal type (no association between multiple VMs) or a consistency type (consistent group). The ECS instances in a protection group can use only one underlying disaster recovery technology: CDR or EBS replication. You must select the technology when you create the protection group. Normal statuses for a protection group include the following: Initializing Replication, Full Replication, Incremental Replication, Failing Over, Failover Completed, Reversing, Failing Back, and Failback Completed. Abnormal statuses include the following: Replication Error, Failover Failed, and Failback Failed. All protected instances in a protection group must have the same role because all ECS instances in the group can only be failed over together.
Protected Instance	Protected Instance	A protected ECS instance or a database that may be supported in the future. Roles are divided into Primary and Secondary. Primary refers to the instance currently running the business. Secondary refers to the instance used for disaster recovery.
Production Site	Production Site	The zone or region where the user's production business initially runs.
DR 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 production site ECS instances are already down at the time of the switch.
Failback	Failback	The process of switching the business back from the disaster recovery site to the production site after the production site has recovered.
Forward Protection	Forward	A status for protection groups and ECS instances. Data and services from the production site 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 (Site B) becomes the new production site, and the original production site (Site A) becomes the new disaster recovery site. When protection is restarted, data is replicated in the reverse direction (from B to A). This is called reverse protection. After a failback, Site A returns to its production role, and Site B returns to its disaster recovery role. When replication is started again (from A to B), it returns to the forward protection state.

Technical architecture

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

Supported disaster recovery scenarios

Disaster recovery scenario	Supported types
Failover	Failover 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 failover starts after synchronization is complete. This ensures that the data at the disaster recovery site is identical to the data at the production site, with zero data loss. This mode is suitable for scenarios such as planned disaster recovery drills and business migrations. Immediate failover This failover attempts to stop the protected instances in the protection group but does not wait for them to stop. It also does not perform a final round of data synchronization. Some data within the RPO window may be lost. This mode is suitable for scenarios where the production site experiences a failure that cannot be recovered quickly, and an immediate switch to the disaster recovery site is required.
Failback	Failback 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 failback starts after synchronization is complete. The service unavailability time is longer than that of an immediate failback. This is mainly used in scenarios where the production site is operating normally. Switch now This failback attempts to stop the protected instances in the protection group but does not wait for them to stop. It also does not perform a final round of data synchronization. The failback starts immediately, which may cause 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 restored to the production site.

Limits

Asynchronous replication for disaster recovery of cloud disks is subject to limits on available regions and zones, ECS instance types, cloud disks, and networks. For more information, see Limits.

Workflow

You can protect key applications in the Hybrid Disaster Recovery console. The main steps are as follows:

Step 1: Resource planning.
Before you perform disaster recovery, plan the required compute, storage, and network resources, such as the number of servers, storage capacity, and virtual private clouds (VPCs).
Step 2: Create a disaster recovery site pair.
Prepare a VPC and a vSwitch for the disaster recovery site and configure their CIDR blocks. For testing, you can use the default configurations to create the VPC and vSwitch. You can also set the CIDR blocks of the disaster recovery site to match those of the production site. For production environments, configure the CIDR blocks as required.
Step 3: Configure network and security settings.
Map resources, such as network zones, vSwitches, and security groups.
Step 4: Create a protection group.
Step 5: Add protected instances.
Add the instances that you want to protect.
Step 6: Start replication.
Start replication to begin disaster recovery protection. This process copies data from the production site to the disaster recovery site.
Note
You can perform a failover drill when the protection group is in the Replicating Incrementally state or after a recovery point is created. For more information, see Failover Drill.
Step 7: Failover
- Failover after data synchronization
  This failover pattern first stops the protected instances in the protection group. It waits for all instances to stop before performing a final round of data synchronization. The failover starts after the synchronization is complete. This process ensures that data on the disaster recovery site is identical to the production site, resulting in zero data loss. This pattern is suitable for scenarios such as planned disaster recovery drills and service migration.
- Switch Now
  This failover pattern attempts to stop the protected instances in the protection group. It does not wait for all instances to stop and does not perform a final data synchronization. This results in some data loss within the Recovery Point Objective (RPO) range. This pattern is suitable for scenarios that require an immediate failover to the disaster recovery site, such as when the production site fails and cannot be recovered quickly.

Billing

When you use disaster recovery with asynchronous replication, the following fees are incurred:

HDR software usage fees
Fees are charged based on the number of instances. For more information about pricing, see Billing.
Fees for pay-as-you-go ECS instances, disks, and other resources that are created at the disaster recovery site are charged by ECS. For more information, see Pay-as-you-go.
ECS charges for the data volume of cross-region asynchronous replication on a pay-as-you-go basis. For more information, see Cloud Disk Disaster Recovery.