FAQ about ECS disaster recovery
This topic answers frequently asked questions about Elastic Block Storage (EBS) async replication and continuous data replication (CDR) for Elastic Compute Service (ECS) disaster recovery.
EBS async replication
What instance specifications does EBS async replication support?
EBS async replication works with most instance types and has the following limits:
Regions and zones: More regions will be added over time. The regions and zones listed when you create a site pair are the supported options. For more information, see Limits on regions and zones.
Disk types: Enterprise SSDs (ESSDs) and ESSD AutoPL disks are supported. ESSD Entry disks are not supported. For more information, see Limits on specifications and ECS disks.
ECS networks:
Single elastic network interface (ENI):
After a failover, some operating systems cannot automatically configure the ENI at the disaster recovery site. Check and configure the ENI after failover to make sure the network works correctly. For more information, see Configure a secondary ENI.
Multiple ENIs:
Some images cannot automatically detect the IP address of a secondary ENI or add a route after the ENI is bound to an ECS instance, which prevents the secondary ENI from working correctly.
If an ECS instance has a secondary ENI, verify the IP address of the secondary ENI after a failover to make sure it works as expected. For more information, see Configure a secondary ENI.
Only ENIs and ECS instances in the same virtual private clouds (VPCs) as the disaster recovery site pair are supported.
Where can I change the IP address of the disaster recovery site for EBS async replication?
Change the IP address from either of these locations:
The Network Information tab on the instance details page.
The Preview Basic Information panel.
Does EBS async replication support ECS configuration changes?
Before a protection group's first replication, the following configuration changes are allowed:
If disk count and total capacity stay within the limits set during protection group setup, the system automatically syncs existing configurations to the disaster recovery site, including changes to new disks.
During system downtime, you can mount, unmount, and scale up disks, rename disks, and roll back disks from snapshots.
Based on vSwitch and security group mappings, you can add or remove instances from security groups, unbind instances, and modify security groups for ENIs.
Configuration changes are not supported in the following scenarios:
Once the protection group enters the running state, configuration changes at either the production site or the disaster recovery site may affect failover and failback.
Unsupported operations may cause system exceptions and trigger alerts.
If an exception occurs or an alert is triggered, evaluate your business requirements before proceeding:
During forward replication
Suspend the replication, remove the affected protected instances, and re-add them to maintain data synchronization consistency.
During reverse replication
Remove the related protected instances and create a new disaster recovery site to maintain data security and service continuity.
What do I do if I cannot select an instance when adding instances for EBS async replication?
EBS async replication has limits on regions, zones, disk types, networks, and configuration quotas. Click the icon to the left of the instance ID to see why protection cannot be enabled for that instance, then fix the issue. For more information, see Limits.
What do I do if the instance type of the disaster recovery site is abnormal when enabling EBS async replication?
This happens when the instance type of the protected instance is unavailable or insufficient at the disaster recovery site. Run the Change Instance Type operation in the console to select an available type. If the operating system or IP address is also affected, use the Modify Operating System or Modify Disaster Recovery IP operation to fix those as well.
What do I do if a protection group is in the "Failed to enable replication", "Failover failed", or "Failback failed" state?
The steps are the same for all three failed states. Using Failover Failed as an example:
Click the ID of the failed task shown in the console. On the Tasks tab, view the detailed error message.
For example,
Not have any stock of instance type family ...indicates that the instance type family does not exist. In this case, run the Change Instance Type at DR Site operation on the Protected Instances page, then retry the task.
What are the differences between CDR and EBS async replication for ECS disaster recovery?
EBS async replication protects data across regions or across zones within the same region using EBS data replication capabilities. For more information, see Overview of disk disaster recovery.
The following table compares CDR and EBS async replication.
Item | CDR | EBS async replication |
Scenarios | Disaster recovery for a single virtual machine (VM). Use this option if system intrusion is acceptable. | Disaster recovery that ensures consistency across VM groups. Use this option if system intrusion is not acceptable. |
Intrusive to the system | Yes | No |
Replication implementation | An agent installed on the protected instance's operating system replicates data written to the disks in real time and sends it to a gateway. The gateway stores the data in an Object Storage Service (OSS) bucket and then writes it to the disk at the disaster recovery site. | Data is replicated using the EBS async replication and snapshot features. |
Recovery implementation | Supports multiple recovery points. A shadow ECS instance and a gateway server are created at the disaster recovery site. Cloud Backup reads data from the OSS bucket to the shadow instance, writes it to the ECS instance at the disaster recovery site, and creates a recovery point using the snapshot mechanism. | Supports a single recovery point. Cloud Backup creates a recovery point by replicating the snapshot to the disaster recovery site. |
Consistency group | Not supported | Supported |
What do I do if the operating system of an ECS instance fails to start during disaster recovery or a drill?
Check the boot mode of the ECS instance at the production site—either basic input/output system (BIOS) or Unified Extensible Firmware Interface (UEFI). The two boot modes are incompatible. The ECS instance at the disaster recovery site must use an image with the same boot mode as the production instance. A mismatched boot mode prevents the operating system from starting. For more information, see Boot modes of ECS instances.
How do I calculate the amount of data replicated during EBS async replication?
EBS async replication has two phases: forward replication and reverse replication.
Forward replication
Forward replication starts with a full replication, then continues with incremental replications.
The full replication copies all data on a disk. The data size equals the total storage capacity of the disk.
After the full replication, an incremental replication runs every 15 minutes and copies only the data changed during that interval.
Reverse replication
Reverse replication starts after a failover and replicates data back to the original instance only. Full replication is not supported—only incremental replication runs every 15 minutes, copying the data changed during each interval.
What are the retention policies for ECS instances and disks at the disaster recovery site?
Long-term retention
ECS instances and disks at the disaster recovery site are retained until you manually remove the corresponding protected instance from the production site. Resources are not automatically reclaimed by default.
Retention after failover
If the service is running at the disaster recovery site (protection group status is Failover Completed or Failover Confirmed), ECS instances and disks at the disaster recovery site are not automatically reclaimed even if you remove the protected instances.
Disaster recovery drill resources
ECS instances and disks created during a disaster recovery drill are automatically reclaimed when the drill group is deleted.
Production site resources
ECS disaster recovery does not reclaim ECS instances or disks at the production site.
Billing
ECS billing depends on the stop mode selected during startup, replication, failover, and failback. For more information, see Economical mode. For discount details, see Instance type billing.
EBS async replication supports subscription and pay-as-you-go billing. For more information, see Billing.
Can I start the ECS instance at the disaster recovery site or production site directly, without performing a failover or failback?
No. When the protection group is in the Reverse Replication state, disks at the destination site are automatically set to read-only to prevent data inconsistency caused by an unexpected startup. To verify your disaster recovery setup, use the disaster recovery drill feature. To restore workloads, perform a formal failover or failback.
What is the RTO of EBS async replication?
A recovery time objective (RTO) is the time from when a disaster recovery plan is executed to when the business system is restored to its target service level.
For failover and failback, the RTO is measured in minutes—from when the operation starts to when the ECS instance is running.
For disaster recovery drills, the RTO scales with the ECS system disk size. Factor in service startup and detection time based on your workload complexity.
CDR
What are the RPO and RTO of CDR?
CDR replicates business data from self-managed data centers to the cloud in real time, achieving recovery point objectives (RPOs) in seconds to minutes. If a major failure occurs at a self-managed data center, data is replicated from the self-managed data center to the cloud within a few minutes, achieving RTOs in minutes.
Which operating systems does CDR support?
CDR supports mainstream Windows and Linux operating systems. For more information, see Operating systems.
CDR supports only the following operating systems.
Only the operating systems listed in the following table are supported. For unsupported operating systems, use the asynchronous replication feature instead.
|
Operating system |
Supported versions and requirements |
|
Windows Server |
2008 R2, 2012, 2012 R2, and 2016 |
|
Linux |
Important
For Linux systems, the /boot partition and the / partition must reside on the same disk. If they do not, resize the disk manually before registering the protected instance for CDR.
|
What are the snapshot retention policies for CDR?
CDR uses the snapshot feature of shadow disks to create recovery points, allowing protected servers to be restored to a specific historical version.
Recovery points used for disaster recovery drills or failover are not subject to these retention policies.
The retention policies are:
All recovery points from the last day are retained.
For example, if the current UTC time is 2020-10-12T17:00:00Z, the last day spans from 2020-10-11T00:00:00Z to 2020-10-12T17:00:00Z—a total of 41 hours.
The last recovery point of each day in the past week is retained.
The last recovery point of each week in the past month is retained.
Recovery points older than one month are deleted.
Does CDR support scaling up or adding disks on a source ECS instance?
Scale-up and disk additions are supported only for source Linux ECS instances in site pairs for cross-region and cross-zone cloud disaster recovery.
After you scale up the source instance or add disks, ECS disaster recovery detects the disk changes within 5 minutes. It then stops the ongoing replication, adjusts the capacity of the destination shadow disks, repairs the replication, and resumes real-time replication. This process runs automatically. Watch the status change from Repair Replication to Replicating in the console. The time required depends on disk size.
Scale-in and disk reduction on the source ECS instance are not supported. These operations can cause replication errors or data loss.
How do I fix a boot image error?
Issue
When you start data replication or preview a disaster recovery drill plan, Cloud Backup reports a boot image error.
Cause
When replication starts, Cloud Backup uses a proxy image to create a corresponding ECS instance at the disaster recovery site. Cloud Backup then replicates data from the production site to this instance and generates or updates recovery points at the end of each replication cycle. During a disaster recovery drill, Cloud Backup uses a proxy image to create a drill instance at the disaster recovery site and replaces the content there with the latest recovery point.
Cloud Backup does not modify the operating system directly. If the ECS image in the production environment becomes unavailable due to an upgrade, deprecation, or deletion, Cloud Backup may not be able to identify the boot mode and operating system version of the instance. This causes destination instances to fail to start during a failover or drill. For best practices on instance boot modes, see Instance boot mode.
Solution
Automatic fix
During the preview, if Cloud Backup reports an image error, click View Details for more information.
In the Details dialog box, select an available image for one or more ECS instances. Cloud Backup uses Cloud Assistant to provide a quick fix feature. Click Fix to run the automatic fix. The fix runs scripts to detect the boot mode and operating system version, then matches an appropriate available boot image. View all operations performed in the Cloud Assistant console.
Manual fix
If the automatic fix cannot detect an appropriate image, log on to the ECS console to check the boot mode and operating system version. Then update the ECS boot image as needed and continue with the replication or disaster recovery drill.
