Database Backup (DBS) supports a variety of databases, including MySQL, SQL Server, Oracle, PostgreSQL, Redis, and MongoDB databases. DBS allows you to back up these types of databases that are deployed on Elastic Compute Service (ECS) instances, in on-premises data centers, on Alibaba Cloud, or on third-party clouds. Then, you can restore the backup data by using DBS.
This topic describes how to back up and restore ECS-hosted user-created MySQL databases by using DBS to meet disaster recovery and security requirements. DBS provides you with features such as real-time backup, quick restoration, remote backup, and long-term archiving. DBS helps eliminate the security risks that may arise from data loss, misoperation, data encryption, blackmail, and hacker attacks.
- You forgot to back up your business data.
- You want to use a cost-effective disaster recovery scheme for your ECS-hosted databases.
- Your database encountered a hacker attack and was deleted. You want to restore the data to the status of yesterday.
- The database server encountered a Trojan horse attack. A large amount of data was lost and the service website cannot be accessed.
- You deleted the data files of your database by mistake and you cannot start mysqld.
- Your colleague replaced your database with a test database. Your database was an online database and has not been backed up.
|Usage of ECS instances||Scheme|
|As the database server||Use DBS backup schedules|
|As the application server||Use ECS snapshots|
|As the database server and application server||Use DBS backup schedules and ECS snapshots|
For more information about how to activate the ECS Snapshot service, see Activate ECS Snapshot.
|Real-time backup||DBS obtains event logs from databases in real time. It also supports the recovery point objective (RPO) accurate to seconds.||View details|
|Quick restoration||DBS allows you to restore the data of a single table. This greatly reduces the recovery time objective (RTO).||View details|
|Restoration to a time point accurate to seconds||DBS allows you to restore a database to a time point accurate to seconds. You can restore a database to the status of the last second instead of the status of yesterday.||View details|
|Low storage costs||DBS provides a data compression ratio up to 30% to reduce storage costs and automatically archives backup data to cheaper storage services.||View details|
|Backup sets available to be queried||DBS allows you to query the data of backup sets. You can directly execute SQL statements to query the data, without restoring the data to databases.||View details|
|Remote backup and restoration||DBS supports remote backup where the distance between the backup source and backup destination is more than 2,000 kilometers. After the data is backed up, you can use DBS to restore the data to a database in the current region or another region.||View details|
|Handling of table name conflicts||DBS allows you to manually rename a table if duplicate names exist when you run restore tasks. DBS can also automatically rename a table.||View details|
|Quick restoration to ApsaraDB for RDS||DBS can automatically create an ApsaraDB for RDS instance with the appropriate specifications and storage space based on the metadata of a backup set.||View details|
After you purchase a backup schedule, a backup schedule in the Not Configured state is listed on the Backup Schedules page of the DBS console. To configure the backup schedule, follow these steps:
- Configure the backup source and backup destination.
- Select backup objects.
- Specify the backup time.
- Configure the lifecycle of backup sets.
- Perform a precheck.
You must create a backup schedule based on the region of the backup destination. Assume that you want to back up a database deployed in the China (Beijing) region to DBS in the China (Hangzhou) region. You must create a backup schedule in the China (Hangzhou) region.
|Backup type||Region of the backup schedule and region of the backup source||Region of the backup schedule and region of the backup destination|
DBS allows you to back up and restore the following types of databases:
- User-created databases connected to Alibaba Cloud through IP addresses and port numbers
- User-created databases hosted on ECS instances
- ApsaraDB for RDS instances
- User-created databases connected to Alibaba Cloud over Express Connect, VPN Gateway, or Smart Access Gateway
- ApsaraDB for PolarDB instances
For more information about database permissions required for database backup, see Database permissions.
You can click Set Whitelist to view the Classless Inter-Domain Routing (CIDR) blocks of the DBS server. You must allow DBS to access your database.
You must configure a backup gateway before you start physical backup. For more information, see Add a backup gateway.
You may have multiple databases in a database instance. You can back up the entire database instance, a specific database, or several tables.
You can specify when to back up your database. You can back up your database on a weekly basis and at a specific time based on your business requirements. For example, you can perform a full backup at 03:00 during off-peak hours of your business.
You can also enable incremental backup. After incremental backup is enabled, you can restore the database to a time point accurate to seconds. However, incremental backup generates more backup data and incurs higher costs.
DBS allows you to manage the lifecycle of backup sets stored in Object Storage Service (OSS) to reduce storage costs. You can configure transfer and deletion policies for all backup sets stored in OSS. As shown in the following figure, the maximum retention period of a full backup set is 730 days. The backup set will be deleted after it is stored for 730 days. A newly created backup set is first stored in OSS Standard storage for 180 days, and then transferred to OSS Infrequent Access (IA) storage. After another 365 days, the backup set is transferred to OSS Archive storage. You can configure similar policies for incremental backup. For more information, see Notes on lifecycle configuration.
After the backup schedule is configured, you can precheck the configurations, database connectivity, and database logging settings. If the precheck is successful, the backup schedule will take effect immediately.
Log on to the DBS console. In the left-side navigation pane, click Backup Schedules. On the Backup Schedules page that appears, click a backup schedule to go to the Configure Task page. In the left-side navigation pane, click Full Data. Find the target backup set and click Query Backup Set in the Actions column.
You are navigated to the Data Lake Analytics console. On the page that appears, the schema of the target DBS full backup set is automatically created in the left-side object list. You can enter SQL statements in the SQL window and click Sync Execute or Async Execute to quickly query the backup set.
Log on to the DBS console. In the left-side navigation pane, click Backup Schedules. On the Backup Schedules page that appears, find the target backup schedule and click Manage in the Actions column. On the Configure Task page, click Restore Database in the upper-right corner. Then, follow these steps:
- Specify the time point to restore.
- Select objects to restore.
- Perform a precheck.
DBS displays the time points to which the database can be restored in a calendar. You can quickly specify the time point accurate to seconds to which the database will be restored.
You can choose to create an instance or select an existing instance as the destination instance of the restore task.
- Create an instance: DBS automatically creates an ApsaraDB for RDS instance that uses the pay-as-you-go billing method as the destination instance. Then, DBS restores the backup data to this instance. DBS determines the specifications and storage space of the ApsaraDB for RDS instance based on the metadata of the backup set and creates the instance in pay-as-you-go mode. DBS detects the creation status of the instance in real time. After the instance is created, the restore task is automatically triggered without manual operations. This greatly shortens the restore process.
- Use an existing instance: DBS restores the backup data to an existing ApsaraDB for RDS instance that you specify.
DBS allows you to restore a single database, multiple tables at a time, or a single table based on your business requirements. This greatly reduces the RTO.
DBS supports table mapping. After you select the tables to restore in the destination database, DBS allows you to rename the tables with duplicate names.
To handle table name conflicts, DBS provides the following two options:
- Fail When Object with the Same Name Exists: The restore task fails when an object with the same name exists. You need to process the corresponding object in the destination database manually.
Assume that you select Fail When Object with the Same Name Exists when you restore an object named DB1.table1, and the original object named DB1.table1 is found in the destination instance. In this case, you need to manually rename the original DB1.table1 object in the destination instance, and restart the DBS restore task.
- Rename Object with the Same Name: The object to restore will be automatically renamed when an existing object with the same name is found in the destination instance. In this case, the existing object in the destination instance remains unchanged.
Assume that you select Rename Object with the Same Name when you restore an object named DB1.table1, and the original object named DB1.table1 is found in the destination instance. In this case, the DB1.table1 object to restore is renamed, and the restore task is completed without any problems. The original DB1.table1 object and the restored DB1xxx.table1xxx object coexist in the destination instance. In the object name format, xxx is the standard naming suffix. Note that if you select this option, incremental data may fail to be restored. We recommend that you manually process objects with duplicate names in the destination instance before you run the restore task.