# rds-dr

Part of **RDS**

# ApsaraDB RDS Disaster Recovery Console Guide

## Operations Overview

| Operation | Console Entry Path | Prerequisites | Description |
|----------|-------------------|--------------|-------------|
| Create Disaster Recovery Instance | Console > RDS > Instances > Disaster Recovery > Create DR Instance | - Major engine version matches source instance<br>- Source is a primary instance (not read-only)<br>- Billing method is pay-as-you-go or subscription (not serverless)<br>- Target instance is empty with sufficient storage | Sets up a one-click disaster recovery instance across regions or environments |
| Configure Disaster Recovery Solutions | Console > RDS > Instances > Disaster Recovery Solutions | - Source instance is RDS PostgreSQL<br>- Network connectivity established (for one-click setup)<br>- Consistent major versions (for GAD) | Compares and selects from multiple DR architectures (GAD, one-click, cross-region backup, DTS) |
| Authorize DBS Service Role | Console > ApsaraDB RDS > Backup & Restoration > Authorize Service-Linked Role | Must use a root account | Grants AliyunServiceRoleForDBS permissions to manage RDS for disaster recovery |
| Binlog Data Recovery | Database Development > Data Tracking > Data Tracking Ticket | - MySQL 5.6+<br>- Binary logging enabled<br>- Logged into DMS (Flexible/Stable modes) | Uses DMS to track changes in binlog and generate rollback scripts |
| Restore Deleted Data | Console > ApsaraDB RDS > Instances > Restore Data | - Running RDS instance<br>- Permissions to manage instance<br>- DMS enabled (if using data tracing) | Recovers accidentally deleted data via backup restore or DMS-based rollback |

## Operation Steps

### Create Disaster Recovery Instance

**Navigation**: Console > RDS > Instances > Disaster Recovery > Create DR Instance

**Prerequisites**:
- The major engine version matches that of the source instance
- The instance is a primary instance (read-only instances cannot serve as DR instances)
- The billing method is pay-as-you-go or subscription (serverless instances cannot serve as DR instances)
- The instance is empty, and its available storage capacity is greater than or equal to the total data size of the source instance

1. Set up network connectivity based on the source instance type  
   - Element: **Set up network connectivity** (button) — main content area  
   - Notes: Connect the source environment to the target VPC using Express Connect, VPN Gateway, Smart Access Gateway (SAG), Cloud Enterprise Network (CEN), or Internet NAT gateway.

2. Review the DR overview to understand the architecture and choose the appropriate recovery approach  
   - Element: **Review the DR overview** (link) — main content area  
   - Notes: See 'Overview of disaster recovery solutions' for architectural guidance.

3. Complete pre-setup preparation by configuring the source instance and verifying DR instance prerequisites  
   - Element: **Complete pre-setup preparation** (link) — main content area  
   - Notes: Ensure all prerequisites are met before proceeding.

4. Create and manage the DR instance with ongoing replication configuration  
   - Element: **Create and manage the DR instance** (link) — main content area  
   - Notes: Follow steps in 'Setup and management of disaster recovery instances'.

5. Assess feasibility by reviewing the feasibility assessment report  
   - Element: **Assess feasibility** (link) — main content area  
   - Notes: Analyze the report to validate your DR deployment setup.

### Configure Disaster Recovery Solutions

**Navigation**: Console > RDS > Instances > Disaster Recovery Solutions

**Prerequisites**:
- Source instance must be RDS PostgreSQL
- For GAD: source and DR instances must have consistent major versions
- Network connectivity must be established for one-click setup
- For DTS: sufficient permissions to configure data synchronization tasks

1. Navigate to the Disaster Recovery section in the RDS console  
   - Element: **Disaster Recovery Solutions** (link) — left navigation panel

2. Select a disaster recovery solution from the list  
   - Element: **Global Distributed Cache (GAD)** (button) — main content area  
   - Notes: Each solution includes a comparison table showing RTO, RPO, price, advantages, disadvantages, and use cases.

3. Click on the solution name to view configuration options  
   - Element: **Global Distributed Cache (GAD)** (xref) — table row  
   - Notes: Links to detailed documentation for each solution.

### Authorize DBS Service Role

**Navigation**: Console > ApsaraDB RDS > Backup & Restoration > Authorize Service-Linked Role

**Prerequisites**:
- You must use a root account for authorization.

1. Log on to the Resource Access Management (RAM) console  
   - Element: **Resource Access Management (RAM) console** (link) — browser  
   - Notes: Navigate to https://ram.console.aliyun.com/

2. Choose Permissions Management > Policies in the left-side navigation pane  
   - Element: **Permissions Management > Policies** (menu) — left-side navigation pane

3. Click the Create Policy button on the Policies page  
   - Element: **Create Policy** (button) — Policies page

4. Switch to the Script Edit tab on the Create Policy page  
   - Element: **Script Edit** (tab) — Create Policy page

5. Enter the policy content in the script editor  
   - Element: **Policy Content** (text_input) — script editor  
   - Notes: The required policy content is referenced from another document. See 'AliyunServiceRoleForDBS' section for details.

6. Enter a policy name and description  
   - Element: **Policy Name** (text_input) — form fields  
   - Notes: The form includes fields for policy name and description.

7. Click the Confirm button to create the policy  
   - Element: **Confirm** (button) — form

8. Alternatively, in the RDS console, click the Backup & Restoration tab in the left-side navigation pane  
   - Element: **Backup & Restoration** (menu) — left-side navigation pane

9. Click the 'Authorize' button in the dialog box that appears  
   - Element: **Authorize** (button) — dialog box  
   - Notes: Clicking this button creates the AliyunServiceRoleForDBS service-linked role.

10. Click the Confirm button to complete the authorization  
    - Element: **Confirm** (button) — dialog box

| Parameter | Type | Required | Options/Values | Description |
|-----------|------|----------|----------------|-------------|
| Policy Name | text_input | Yes | — | The name of the new RAM policy being created. |
| Description | text_input | No | — | A brief description of the policy's purpose. |

### Binlog Data Recovery

**Navigation**: Database Development > Data Tracking > Data Tracking Ticket

**Prerequisites**:
- A MySQL 5.6 or later database
- Binary logging enabled for the database
- Logged on to the database in DMS (required for Flexible Management and Stable Change modes; not required for Security Collaboration mode)

1. Log on to the DMS console V5.0  
   - Element: **DMS console V5.0** (link) — top navigation bar

2. Navigate to Database Development > Data Tracking > Data Tracking Ticket  
   - Element: **Database Development** (menu) — top navigation bar

3. Click Data Tracking in the upper-right corner of the Data Tracking Ticket page  
   - Element: **Data Tracking** (button) — upper-right corner of the Data Tracking Ticket page

4. Configure parameters on the Data Tracking Tickets page and submit the ticket  
   - Element: **Submit** (button) — upper-right corner of the Data Tracking Tickets page  
   - Notes: Parameters include Task Name, Database Name, Table Name, Track Type, Time Range, and Change Stakeholder.

5. Wait for approval from the database administrator (DBA)  
   - Notes: By default, the DBA of the selected database approves the ticket.

6. Wait for DMS to download and parse the binary logs after approval  
   - Notes: Processing may take several minutes depending on log volume.

7. Filter results by Track Type, Table Name, or Column Name to isolate target rows  
   - Element: **Export Rollback Script** (button) — after filtering results  
   - Notes: Click **View Details** to review individual records before exporting.

| Parameter | Type | Required | Options/Values | Description |
|-----------|------|----------|----------------|-------------|
| Task Name | text_input | Yes | — | Enter a name that helps you and approvers identify the purpose of the ticket. |
| Database Name | dropdown | Yes | — | Select the database whose data you want to track. You must have management permissions for the database in DMS. Type a prefix to filter the list. |
| Table Name | dropdown | No | — | Select one or more tables to track. |
| Track Type | checkbox | Yes | Insert, Update, Delete | Select the operation types to roll back: Insert (generates INSERT rollback statements), Update (generates UPDATE rollback statements), or Delete (generates DELETE rollback statements). |
| Time Range | text_input | Yes | — | Specify the time window covering the accidental change. Flexible Management mode: limited to the previous 30 minutes. Stable Change or Security Collaboration mode: any range within the binary log retention period, up to 48 hours per ticket. |
| Change Stakeholder | dropdown | No | — | Select the stakeholders who need access to ticket details. Only the selected stakeholders and ticket approvers can view the ticket. |

### Restore Deleted Data

**Navigation**: Console > ApsaraDB RDS > Instances > Restore Data

**Prerequisites**:
- Access to the ApsaraDB RDS console
- Permissions to manage RDS instances
- For DMS-based restoration: Data Management (DMS) service enabled and configured

1. Navigate to the RDS instance list in the console  
   - Element: **Instances** (menu) — left navigation panel

2. Select the target RDS instance  
   - Element: **Select instance** (button) — main content area  
   - Notes: Ensure the instance is in a running state before proceeding with restoration.

3. Click on the 'Restore' option under the instance actions  
   - Element: **Restore** (button) — top-right corner  
   - Notes: The restore method varies based on whether the data loss is large or small scale.

4. Choose the appropriate restore method based on data volume  
   - Element: **Method** (dropdown) — restore configuration form  
   - Notes: For large amounts of data, use backup-based restore. For small amounts, use DMS data tracing.

5. If using DMS, enable data tracing and generate rollback statements  
   - Element: **Use data tracking** (link) — DMS section  
   - Notes: This feature automatically generates SQL rollback statements for individual records.

| Parameter | Type | Required | Options/Values | Description |
|-----------|------|----------|----------------|-------------|
| Restore Method | radio | Yes | Backup-based restore, Data tracing (DMS) | Select the method used to recover the deleted data based on volume and complexity. |
| Target Backup Point | dropdown | Yes | Latest backup, Custom point in time, Specific backup file | Choose the backup snapshot or point in time to restore from. |

## FAQ

Q: Where do I find the disaster recovery setup option in the RDS console?
A: Go to Console > RDS > Instances, then look for "Disaster Recovery" or "Disaster Recovery Solutions" in the left navigation panel or instance action menu.

Q: Can I modify the disaster recovery configuration after creating the DR instance?
A: Some settings like network connectivity and replication parameters may be adjustable post-creation, but core properties like engine version and instance type cannot be changed. Refer to the specific DR solution documentation.

Q: What happens if I leave the Time Range blank in DMS data tracking?
A: The Time Range field is required. In Flexible Management mode, it defaults to the last 30 minutes, but you must explicitly specify a valid range within system limits.

Q: Do I need special permissions to authorize the DBS service-linked role?
A: Yes, only a root account can perform this authorization. RAM users, even with administrative policies, cannot create service-linked roles without explicit delegation.

Q: Is there a limit on how far back I can restore data using binlog?
A: Yes. In Flexible Management mode, only the last 30 minutes are available. In Stable Change or Security Collaboration mode, you can go back up to 168 hours (7 days) if log backup is disabled, or up to 730 days if enabled—but each ticket covers a maximum of 48 hours.

## Pricing & Billing

### Billing Model
DR instances are billed hourly based on compute and storage usage. Costs apply from creation until deletion. Other DR methods incur costs based on network usage, storage (OSS), or per-request fees.

### Price Reference

| Tier | Input Price | Other Price |
|------|-------------|-------------|
| Standard (DR Instance) | 0.08 / | — |
| Global Distributed Cache (GAD) | Medium | Network fees based on one-way synchronization link usage |
| One-click disaster recovery setup | Slightly high | Users bear network costs |
| Cross-region backup | Low | Storage cost in Object Storage Service (OSS) |
| Data synchronization (DTS) | High | Higher cost when synchronizing many databases |
| Restore Deleted Data | 0.01 / | — |

### Free Tier
- Flexible Management mode in DMS: free
- Restore Deleted Data: 10 free recovery operations per month

### Billing Notes
- DR instances are billed hourly from creation until deletion.
- Network fees apply for GAD and one-click setup.
- Cross-region backup storage is billed via OSS.
- DTS costs scale with the number of databases synchronized.
- For Stable Change or Security Collaboration mode in DMS, fees apply.
- A single data tracking ticket covers a maximum of 48 hours; split longer ranges into multiple tickets.
- Restore operations are billed per request regardless of data volume.