Data Disaster Recovery

Introduction

To every storage system, data disaster recovery is indispensable, so is database disaster recovery. Data disaster recovery is especially indispensable to those service scenarios with strong needs for data availability, such as finance and games. Database disaster recovery is guaranteed mainly through multi-replica architecture. Also, the data's high availability is assured through regular data backup and master-slave data synchronization. In a complicated network, the users should have cross-datacenter, cross-AZ, and cross-region data disaster recovery capacity.

The following introduces Baidu AI Cloud RDS's data disaster recovery solutions.

Solutions

Database multi-replica -master-slave architecture

Currently, RDS for MySQL provides users with "One Master, One Backup" Dual High-availability Version. The master-slave architecture is designed for the following purpose. When the fault or disaster of the master database takes place, the RDS turns the backup database into the master database in real time and switches the service traffic to the new master database. Also, it creates a backup database and ensures service efficiency.

Data Backup

Data backup helps you recover the database to the designated moment ahead of the incorrect action when you find the incorrect action, as a way to minimize the loss.

Automated backup at backup node

Data at the backup node are subject to automated backup once a day. Here, the backups are transparent to the users, and you need not perform any action for the automated backup at the backup node.

Create the automated backup by the users

The RDS supports the setting of the custom backup cycle to meet users' different backup needs fully and alleviate the users' OPS workload. You may set the automated backup cycle as one day per week to seven days per week, in addition to setting the time point for backup.

For detailed actions, see Automated Backup Creation

Creation of manual backup by the users

If there are special needs for data backup, for example, the data is subject to the significant change, the users can trigger the backup manually.

For detailed actions, see Manual Backup Creation

DTS data synchronization

DTS synchronization service helps realize real-time data synchronization between cross-region RDS instances, and in turn, fulfill remote disaster recovery. It helps the user improve data security and build a high-availability architecture.

DTS data synchronization helps overcome obstacles on the cross-region instance network, and it is transparent to the users. No matter what kind of data recovery disaster (in the same region or in different regions) takes place, you just need to configure master instance and disaster recovery instance's access entries on the DTS.

For usage of the DTS data synchronization, see Data Synchronization

MySQL cross-instance master-slave synchronization

To ensure the user data's high availability, the users may purchase one new RDS instance to synchronize the online service's RDS master instance. In this way, when all of the service's instances are disabled, the user can use the RDS instance of the backup node.

Use method:

• Purchase one RDS instance in the same region (in the same AZ or in different AZs) as the disaster recovery instance;
• Import the data and apply for disaster recovery instance's "Super" privilege. On the disaster recovery instance, execute "change master", and establish the relationship of synchronization with the master instance.

DB firewall

In what situations is the DB firewall used?

DB firewall is deployed on the Baidu AI Cloud RDS service's proxy instance. It can effectively intercept SQL injection attacks, and improve the user data's security. You can deploy your services with the Baidu AI Cloud RDS service and have it directly connected to RDS. Thus, hackers may take advantage of Web application vulnerabilities to launch SQL injection attacks. In this case, you need to identify and process the SQL injection attacks at the service layer, adding to the complexity of development at the business layer. After deploying the Baidu AI Cloud's proxy instance deployed and enabling the firewall feature, the DB firewall can parse SQL, match the injection feature, and warn against or intercept SQL injections under the condition of no influence on services. All in all, DB firewall can effectively intercept the injection attacks and protect the users' data security. Meanwhile, the system can summarize injection details of five minutes, and send the user an alarm email or an SMS notification. The system does not send anything when no injection occurs. Thus, the user can receive the alarm information and take security actions in a real-time manner.

Note:

1. DB firewall gets deployed on a proxy instance, and only RDS for MySQL supports the creation of proxy instance for now. Thus, only the MySQL instance can use the DB firewall.
2. Currently, the DB firewall only supports instance-level defensive granularity rather than a database, table, and user-level defense.

Instructions on DB firewall mode

After creating MySQL instance and getting a proxy instance, the user can enable the DB Firewall feature on the proxy instance management page. After the DB firewall is enabled, the users may choose two security levels, namely, alert and block.

• Alert: The DB firewall outputs the SQL injection alert log, which does not intercept SQL's normal execution. At this level, the DB firewall parses the SQL and records the identified injection attacks in the log. The SQL is further executed on MySQL instance. The user can query the identified SQL injections on the SQL injection query page. The users may sort out the SQL injections. If the users deem the SQL as "Wrong alert", they may add it into SQL whitelist;
• Block: DB firewall outputs SQL injection block log, and SQL, identified as "Injection", is blocked, failing to be sent to MySQL instance. Likewise, the users may query the intercepted SQL on SQL injection query page.
• Note:

1. When using the DB firewall, recommend you to select the alert level. After running for a period, check if there is a wrong alert, and add the SQL of "Wrong Alert" into a whitelist. Wait till the system runs steadily, switch to the "Block" mode to intercept SQL injection attacks.
2. The SQL, having been added into a whitelist, is identified and released by the DB firewall. Also, It cannot intercept the SQLs with the same signature as the current SQL. So, you need to add it with great care. If you delete the SQL from the whitelist, it can intercept the released SQL again.
3. If a wrong interception occurs, you cannot add a wrongly intercepted SQL into the whitelist in time. So, you can modify the DB firewall defense level as "Alert", avoiding blocking the SQL's normal execution.

Backup and recovery

Create a backup

Backup creation includes two modes, namely, automated creation by the system and manual creation by the users. You can use these data backup snapshots for data recovery and instance cloning.

• Automated backup creation by the system:
  Regardless of choosing the "Backup on the current day", the RDS can automatically generate data snapshots at the hot backup node every day to fully ensure the user data's availability and reliability.
• Manual backup creation by the users:
  According to your service needs, you may select a given time point on given days within one week for automated generation of data backup snapshots.
• Manual backup creation by the users:
  You can create backups manually at any time and we recommend that you create backup manually after every important data change.
• Backup space management:
  By default, the system presents you with backup space (the same as RDS instance's disk capacity) free of charge for the storage of backups from automated and manual creation. Excess part beyond the free backup space will be additionally charged. For storage billing, see Backup Storage Billing. According to your service needs, you can define the total size of data snapshots (exceeding the complimentary space or not), as well as set the number of days for reservation of automated backups. Custom days for reservation of backups may be set as any value ranging from 7 days to 730 days. If you do not set the days for reservation, total size of reserved data snapshots by default will not exceed the complimentary space, and the number of data snapshots will not exceed 30.

Backup recovery

Backup recovery falls into three types, namely, snapshot recovery, clone instance snapshot recovery, and clone instance time point recovery. By clone instance, you may recover the data after confirming the data correctness. That helps reduce data loss risk.

• Snapshot recovery:
  You may carry out data recovery using existing data snapshots at any time. Note: once the data recovery is executed, the original instance's existing data are all lost and cannot be recovered. For this reason, we recommend that you should execute recovery action with great care, and ensure that one data snapshot is generated before recovery for usage in rollback.
• clone instance snapshot recovery:
  Aside from directly executing data recovery on the current RDS instance, you may recover the data using a data cloning feature. You may specify one data snapshot to create RDS clone instance. Then, the system export data from the current data snapshot to this clone instance. Therefore, you may import corresponding data into original RDS via DTS service to complete data recovery after confirming the correctness of the cloned data imported. After completing the data recovery, you can release the clone instance at any time.
• Clone instance time point recovery:
  By the clone instance, you may recover the data to any time point. You just need to select the time point for data import when creating a clone instance. Then, the system imports current RDS instance's data at this time point into the clone instance. Still, you may import corresponding data into original RDS via DTS service to complete data recovery after confirming the correctness of the cloned data imported. After completing the data recovery, you can release the clone instance at any time.

Network isolation

Realize network access control via IP whitelist

Baidu AI Cloud RDS provides the IP whitelist feature, realizing the users' control over the network access. IP whitelist is effective to RDS instance's all connection modes (like connection in VPC, and public network connection). We recommend that you should set the corresponding whitelist rule to ensure the security of the RDS instance before applying for public network IP.

Realize network isolation via private network VPC

By default, the RDS instance is saved in VPC, which improves the RDS instance's security to the maximum extent. VPC is a private network environment that is provided by Baidu AI Cloud for the users. Via underlying network protocol, VPC strictly isolates the users' network packets, so that the users complete the access control on the network layer. VPC's custom RDS IP segment helps users resolve the conflict of IP resources. By default, RDS instance in VPC may be accessed by BCC instances in the same VPC via the IP whitelist.

Realize secure connection to the Internet via VPN

Generally, the users may apply for public network IP for RDS, and add the opposite party IP into the whitelist, making RDS accessed by the public network IP, from example, accessed by another private network exit EIP(elastic public network IP), and accessed by users' self-built IDC public network exit.

To ensure secure access to the Baidu AI Cloud RDS by the users' self-owned server, the users may connect the self-built IDC server with Baidu AI Cloud RDS via VPN. Baidu AI Cloud VPN gateway is subordinate to private network VPC service. For detailed building process, see VPN Gateway.