Backup and restoration
Backups are a core part of any disaster recovery strategy—they protect your data against corruption, accidental deletion, and instance failures. ApsaraDB RDS provides automatic and manual backup options, along with two restoration methods to fit different recovery scenarios.
Backup
ApsaraDB RDS supports two types of backups. For configuration details, see Automatic and manual backups.
| Backup type | Required | Minimum frequency | Retention period |
|---|---|---|---|
| Data backup | Yes | At least 2 physical backups per week | 7–730 days |
| Log backup | No | N/A (follows data backup schedule) | Same as data backup |
Log backup note: If you disable log backup, you can only restore data to the point in time when the most recent data backup was created.
For ad hoc needs, create a manual backup from the ApsaraDB RDS console or by calling an API operation.
Restoration
ApsaraDB RDS supports two restoration methods. Restoration always creates a new temporary or clone instance—it does not overwrite the source instance.
| Method | When to use | How it works |
|---|---|---|
| Restore from a data backup file | You know the exact backup you want to recover from | Restores data from a specific backup file to a new temporary or clone instance |
| Restore to a point in time | You need to recover to a specific moment | ApsaraDB RDS locates the full backup closest to the selected point in time, then applies subsequent log backups to reach that point |
Restoring to a point in time requires log backup to be enabled. If log backup is disabled, you can only restore from a data backup file.
After restoration completes, verify that the data is intact on the new instance.
For full details, see Restore the data of an ApsaraDB RDS for MySQL instance.
References
Supported backup and restoration methods vary by instance configuration. See the feature list for your database engine: