Guide to selecting backup methods and backup plan specifications
Data Disaster Recovery provides two backup methods — logical backup and physical backup — and multiple backup plan specifications. Use this guide to choose the method and specification that fit your database size, performance requirements, and budget.
Logical backup vs. physical backup
Logical backup operates at the database object level (tables, indexes, stored procedures). Physical backup operates at the database file level, copying the raw files from the operating system. The right choice depends on your database size and what you need to back up.
| Attribute | Logical backup | Physical backup |
|---|---|---|
| Backup scope | Individual databases and tables | Entire database instance only |
| Recommended database size | 1 MB – 1 TB | Larger than 1 TB |
| Common tools | mysqldump (MySQL), exp/imp (Oracle) | XtraBackup (MySQL), RMAN (Oracle) |
| Full backup mechanism | DBS splits table data and reads it across multiple threads using parallel SQL execution | A backup gateway installed on the database server copies the database files directly |
| Incremental backup mechanism | DBS reads database logs from memory in real time, adjusting read speed based on log generation rate | Not applicable |
| Requires backup gateway | No | Yes — see Add a backup gateway |
| Impact on database I/O | Minimal — databases are not locked during backup | Moderate — reads directly from disk, which affects input/output operations per second (IOPS) |
| Backup size | Smaller — selective table or data backup is possible | Larger — reflects the full storage footprint of the database |
| Backup and recovery speed | Typically slower | Typically faster |
| Sandbox support | No | Yes — see Sandbox feature overview |
| Supported databases | All database types, including ApsaraDB (ApsaraDB supports logical backup only) | Self-managed databases; ApsaraDB is not supported |
For the full list of backup methods supported per database engine, see Supported database engines and features.
Choose a backup plan specification
Data Disaster Recovery offers the following backup plan specifications: serverless, micro, small, medium, large, xlarge, 2xlarge, and 4xlarge. Higher-tier specifications deliver faster backup and recovery performance at a lower unit price per GB.
The primary factor determining your monthly cost is how your actual backup volume compares to the free quota of your selected tier. If your backup volume consistently exceeds the free quota, upgrading to a higher tier is often more cost-effective than paying overage fees at a lower tier.
Specification details
| Specification | Time to back up 100 GB | Free quota (GB/month) | Chinese mainland config fee (USD/month) | Excess rate — Chinese mainland (USD/GB) | China (Hong Kong) region and outside China config fee (USD/month) | Excess rate — China (Hong Kong) region and outside China (USD/GB) |
|---|---|---|---|---|---|---|
| micro | ~20 hours | 40 | 5 | 0.117 | 7 | 0.175 |
| small | ~5 hours | 400 | 22 | 0.055 | 33 | 0.083 |
| medium | ~2.5 hours | 800 | 35 | 0.039 | 53 | 0.059 |
| large | ~1.5 hours | 1,600 | 56 | 0.024 | 84 | 0.036 |
| xlarge | ~1 hour | Unlimited | 140 | Free | 209 | Free |
The fees displayed on the buy page prevail. Each calendar month, the free quota resets — unused quota does not roll over.
|
Backup schedule type |
Estimated time required to back up 100 GB of data |
Free quota for data backup (GB per month) |
Configuration fee for the Chinese mainland |
Configuration fee for the China (Hong Kong) region and regions outside China |
||
|
Configuration fee (USD per month) |
Unit price of excess backup data (USD per GB) |
Configuration fee (USD per month) |
Unit price of excess backup data (USD per GB) |
|||
|
micro |
20 hours |
40 |
5 |
0.117 |
7 |
0.175 |
|
small |
5 hours |
400 |
22 |
0.055 |
33 |
0.083 |
|
medium |
2.5 hours |
800 |
35 |
0.039 |
53 |
0.059 |
|
large |
1.5 hours |
1600 |
56 |
0.024 |
84 |
0.036 |
|
xlarge |
1 hour |
∞ |
140 |
Free of charge |
209 |
Free of charge |
Usage notes
-
Backup schedule upgrades only: Downgrading a backup schedule is not supported. See Upgrade a backup schedule.
-
Table count limit: Keep the number of tables in the source database under 10,000. Exceeding this causes long table initialization times during backup and recovery.
-
Primary key considerations: Tables without primary keys, tables with string primary keys, or tables with composite primary keys result in longer backup times.
-
Complex table schemas: If your database has unreasonable table schemas, large tables, or large fields, start with a higher-tier specification. If backup exceptions occur, upgrade the schedule and retry. For unresolved issues, join the DBS DingTalk group (ID: 35585947) for technical support.
Select a specification based on your priority
High-performance requirement
For production databases where backup and recovery speed matters, choose the 4xlarge or 2xlarge specification.
Cost-effectiveness requirement
Use the billing formula to compare costs across tiers, then choose the lowest-cost option that meets your performance needs:
Subscription (upfront) billing = Configuration fee + max(0, Actual backup volume − Free quota) × Excess rateExample: Company A runs four full backups per month on a 150 GB database, producing 600 GB of backup data. Prices apply to the Chinese mainland.
| Specification | Calculation | Monthly cost |
|---|---|---|
| micro | USD 5 + (600 − 40) GB × USD 0.117/GB | USD 70.52 |
| small | USD 22 + (600 − 400) GB × USD 0.055/GB | USD 33 |
| medium | USD 35 + 0 (within free quota) | USD 35 |
In this example, small is the cheapest option. Medium is only USD 2 more but offers faster backup speed — the right choice depends on your performance requirements.
This example is illustrative. Account for incremental backup volume and data growth between full backups when estimating your actual monthly usage. When total monthly backup volume exceeds 5,207 GB, xlarge becomes the most cost-effective option — it has no data volume limit and provides the best backup performance.
Performance benchmark data
The benchmark results below help you validate which specification meets your throughput requirements before purchasing.
Logical backup and recovery
Test environment:
| Configuration item | Value |
|---|---|
| Database type | RDS for MySQL (general-purpose) |
| CPU | 8-core |
| Memory | 2,400 MB |
| IOPS | 1,200 |
Test database:
| Metric | Value |
|---|---|
| Database size | 102 GB |
| Total records | 150 million |
| Record size | 1 KB – 100 KB |
| Fields per record | 3 – 22 columns |
| Field types | int, varchar, datetime |
Full backup
| Specification | RPS (records per second) | Throughput (MB/s) |
|---|---|---|
| large | 42,855.7 | 15.3 |
| medium | 33,122.2 | 11.8 |
| small | 9,569.3 | 3.4 |
| micro | 6,756.2 | 1.9 |
Incremental backup
| Specification | Throughput (MB/s) |
|---|---|
| large | 46.1 |
| medium | 29.8 |
| small | 14.9 |
| micro | 5.0 |
Full restoration
| Specification | RPS (records per second) |
|---|---|
| large | 34,190.5 |
| medium | 19,740.9 |
| small | 9,949.4 |
| micro | 4,320.2 |
Incremental restoration
| Specification | RPS (records per second) |
|---|---|
| large | 35,546.9 |
| medium | 21,331.4 |
| small | 10,061.5 |
| micro | 4,972.1 |
Physical backup and recovery
Physical backup reads MySQL files as a stream and writes backup data to cloud storage using multiple concurrent streams. The concurrency level scales with the specification tier — higher tiers mean faster backups. Two compression algorithms are available: gzip (higher compression ratio, smaller files) and LZ4 (faster speed, larger files).
Test database:
| Metric | Value |
|---|---|
| Database size | 40.3 GB |
| Total records | 2 billion |
| Number of tables | 160 |
| Record size | 0.2 KB |
Full backup
| Specification and compression | Time | Throughput | Compressed file size |
|---|---|---|---|
| small (4 threads) + gzip | 636 s | 63 MB/s | 21.1 GB |
| large (8 threads) + gzip | 341 s | 118 MB/s | 21.1 GB |
| xlarge (16 threads) + gzip | 204 s | 197 MB/s | 21.1 GB |
| small (4 threads) + LZ4 | 268 s | 150 MB/s | 31.1 GB |
| large (8 threads) + LZ4 | 119 s | 338 MB/s | 31.1 GB |
| xlarge (16 threads) + LZ4 | 104 s | 387 MB/s | 31.1 GB |
Full restoration
| Specification and compression | Compressed data volume | Duration | Recovery speed (relative to raw data size) |
|---|---|---|---|
| small (4 threads) + gzip | 21.1 GB | 320 s | 126 MB/s |
| large (8 threads) + gzip | 21.1 GB | 161 s | 250 MB/s |
| xlarge (16 threads) + gzip | 21.1 GB | 86 s | 468 MB/s |
| small (4 threads) + LZ4 | 31.1 GB | 408 s | 99 MB/s |
| large (8 threads) + LZ4 | 31.1 GB | 208 s | 194 MB/s |
| xlarge (16 threads) + LZ4 | 31.1 GB | 108 s | 373 MB/s |
Key insight: LZ4 is approximately 2–3x faster than gzip at the same specification tier, but produces backup files roughly 47% larger. Choose gzip when storage space is the priority; choose LZ4 when backup speed matters more.
What's next
-
Add a backup gateway — required for physical backup
-
Upgrade a backup schedule — scale up your specification if performance is insufficient
-
Supported database engines and features — verify backup method support for your database engine
-
Performance tests on backup and restoration — detailed benchmark methodology