How to select a backup specification-Data Management-阿里云帮助中心

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

The fees displayed on the buy page prevail. Each calendar month, the free quota resets — unused quota does not roll over.

Backup schedule specifications	Backup time for 100 GB database (reference)	Free quota (GB/month)	Chinese mainland region configuration fees		Hong Kong and overseas region configuration fees		Finance cloud configuration fees
Backup schedule specifications	Backup time for 100 GB database (reference)	Free quota (GB/month)	Basic fee (CNY/month)	Excess fee (CNY/GB)	Basic fee (CNY/month)	Excess fee (CNY/GB)	Basic fee (CNY/month)	Excess fee (CNY/GB)
serverless	5 hours	0	20	0.45	30	0.675	38	0.855
micro	20 hours	40	30	0.75	45	1.13	57	1.43
small	5 hours	400	140	0.35	210	0.53	266	0.67
medium	2.5 hours	800	224	0.25	336	0.38	426	0.48
large	1.5 hours	1600	359	0.15	539	0.23	683	0.29
xlarge	1 hour	No limit	900	Free	1350	Free	1710	Free

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 rate

Example: 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	CNY 30 + (600 − 40) GB × CNY 0.75/GB	CNY 450
small	CNY 140 + (600 − 400) GB × CNY 0.35/GB	CNY 210
medium	CNY 224 + 0 (within free quota)	CNY 224

In this example, small is the cheapest option. Medium is only 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