Overview of data restoration solutions for ApsaraDB for MongoDB-ApsaraDB for MongoDB(MongoDB)-阿里云帮助中心

ApsaraDB for MongoDB provides multiple data restoration solutions for different scenarios.

Restore data to an ApsaraDB for MongoDB instance

Important

Before you restore data to a new instance:

The new instance must have the same major database version as the source instance. Select a zone that supports this version — available zones vary by version (Usage notes).
The new instance must have at least as much storage as the source instance.
Backups created before a major version upgrade cannot be restored to the new version.
By default, a new instance created for data restoration runs the latest kernel minor version.
If your instance contains time series collections (MongoDB 5.0 or later), point-in-time recovery may encounter issues during the oplog replay phase.

Solution	Instance architecture	Restoration destination	Restoration range	Scenario
Restore one or more databases of an ApsaraDB for MongoDB instance	Replica set instance that uses cloud disks Sharded cluster instance that uses cloud disks	Original instance	All databases Some databases	Recovers accidentally deleted collections or documents.
	Replica set instance that uses local disks and runs MongoDB 4.0 or 4.2 Note Supported regions and other limits are listed in Usage notes.	New instance	All databases Some databases	Recovers accidentally deleted collections or documents.
Create a new instance from a backup point	Standalone instance Replica set instance	New instance	All databases Some databases Note Partial restoration is supported only on local-disk instances.	Suitable when data timeliness is not critical.
Create a new instance using point-in-time recovery	Replica set instance	New instance	All databases Some databases Note Partial restoration is supported only on local-disk instances.	Restores instance data to a specific point in time.
Create a new instance using point-in-time recovery	Sharded cluster instance	New instance	All databases	Restores instance data to a specific point in time.
Flashback by key	Sharded cluster instance that uses cloud disks and runs MongoDB 5.0 or later	Original instance	Partial keys	Quickly rolls back specific data by flashback key after small-scale corruption or accidental loss.
Cross-region data restoration	Replica set instance that uses cloud disks Sharded cluster instance that uses cloud disks	New instance	All databases	Restores a cross-region backup to a new instance in the backup's stored region for compliance or disaster recovery.

Restore data to a self-managed database

To restore data to a self-managed database, first download the backup from your ApsaraDB for MongoDB instance (Download a backup file).

Solution

Instance architecture

Usage notes

Restore a logical backup to a self-managed database

Replica set instance that runs MongoDB 4.2 or earlier and uses local SSDs.
Sharded cluster instance that runs MongoDB 4.2 or earlier and uses local SSDs.

Always use a mongorestore version compatible with your MongoDB version — older versions may not support newer databases (mongorestore).

Restore data from a local disk backup

Replica set instance that meets the following conditions:

Transparent data encryption (TDE) is disabled for the instance (Enable TDE).
The storage engine of the instance is WiredTiger or RocksDB.

None.

FAQ

How do I restore data from an earlier point in time?

The time range to which you can restore instance data depends on the retention period of your backup data. If you want to restore data from an earlier point in time, see Long-term retention backup.

How long does it take to restore data to a new instance?

The time required to restore data to a new instance depends on the storage type, backup data volume, oplog volume to replay, and new instance specifications. It usually ranges from several minutes to several hours.

A complete restoration consists of the following three stages. The total restoration time is the sum of all three stages:

Stage	Description	Related to data volume
Create a new instance	Creates and configures the target instance with your selected specifications.	No
Restore a full backup	Restores the full backup data to the new instance.	Strongly depends on the storage type. See the following sections.
Restore an incremental backup (oplog replay)	Replays incremental data generated between the full backup point and the target point in time to the new instance.	Yes

Note

When you create an instance from a backup point, incremental restoration is not required, so the third stage is excluded. When you use point-in-time recovery to create an instance, data is replayed to your specified point, so the third stage is included. The following tables further divide the Create a new instance stage for the two storage types.

Cloud disk-based instances

Full restoration for a cloud disk-based instance uses cloud disk snapshots. Data is restored by mounting a snapshot, so this stage is largely independent of data volume.

The following estimates use a replica set instance with 4 cores and 8 GB as the reference environment:

Stage	Estimated duration
Create a new instance	10 to 15 minutes
Restore a full backup (snapshot mounting)	Usually 5 to 10 minutes and largely independent of data volume.
Start and initialize the instance	2 to 5 minutes
Restore an incremental backup (oplog replay)	Depends on the incremental data volume and content complexity. See Factors that affect restoration time.

Example: For a cloud disk-based replica set instance with 4 cores and 8 GB, creating an instance from a backup point usually takes 20 to 30 minutes, whether the data volume is 20 GB or 1 TB. Using point-in-time recovery to create an instance requires additional replay time based on the oplog volume generated between the backup point and target point in time.

Local disk-based instances

Full restoration for a local disk-based instance first downloads the backup set from backup storage. It then decompresses the set on the target node. The duration depends on the backup set size and the number of data files.

The following estimates use a replica set instance with 4 cores and 8 GB as the reference environment:

Stage	Estimated duration
Create a new instance	10 to 15 minutes
Download the full backup set	The reference rate is 50 to 200 GB per hour, depending on instance specifications and network conditions.
Decompress the full backup set	Depends on the number of data files. See the following note.
Download the oplog	The reference rate is 50 to 200 GB per hour.
Replay the oplog	Depends on the incremental data volume and content complexity. See Factors that affect restoration time.

Note

Decompression time is determined primarily by the number of data files in the backup set, not only by its size. More collections and indexes mean more data files and longer decompression. Decompression usually takes minutes for a typical instance. For an instance with hundreds of thousands of collections and indexes, decompression may take several hours or longer. This is expected. For more information, see Performance issues from excessive databases and collections. If your instance has many collections and requires fast restoration, use a cloud disk-based instance.

Example: Consider a local disk-based replica set instance with 4 cores and 8 GB and 200 GB of data. To create an instance from a backup point, assume a download rate of 100 GB per hour and approximately 30 minutes for decompression. End-to-end restoration takes approximately 3 hours. Using point-in-time recovery to create an instance also requires time to download and replay the oplog.

Note

The preceding durations are empirical estimates and do not constitute a service commitment. If a restoration task makes no progress for an extended period, submit a ticket to contact technical support.

Factors that affect restoration time

Storage type: Full restoration for a cloud disk-based instance mounts a snapshot. This is significantly faster than downloading and decompressing data for a local disk-based instance.
Backup set size: A larger backup takes longer to download for a local disk-based instance. This factor does not affect a cloud disk-based instance.
Number of data files: More collections and indexes increase decompression time for a local disk-based instance.
New instance specifications: More CPU cores, memory, and disk IOPS accelerate downloads, decompression, and oplog replay. Restoring a large data volume to a low-specification instance takes significantly longer.
Oplog volume: For point-in-time recovery, a target point in time farther from the full backup point requires more oplog data to be replayed. This increases restoration time.
Oplog content complexity: Multi-document transactions in the oplog must be replayed serially and cannot be accelerated through parallelism. Large documents and hotspot updates cause additional write amplification. For complex write workloads, higher instance specifications may not noticeably improve replay speed.
Source instance write rate: For point-in-time recovery, a higher source write rate generates more oplog data in the same period. This increases replay time.
Sharded cluster instances: The Config Server, shards, and mongos nodes of a sharded cluster instance are restored in parallel. Completion time depends on the slowest component. It is typically no shorter than for a replica set instance with the same data volume.

Recommendations to reduce restoration time

Prefer a cloud disk-based instance. Full restoration takes minutes and is unaffected by data volume or the number of collections.
Select specifications for the new instance that are no lower than those of the source instance. This prevents specification bottlenecks during restoration.
Prefer to create an instance from a backup point. If your business permits, use the backup point closest to the target point in time. This reduces or eliminates oplog replay time.
Limit the number of collections and indexes. Promptly remove unused collections and indexes to significantly reduce decompression time for a local disk-based instance.
Enable High-frequency backup. This shortens the interval between the backup point and target point in time, reducing the oplog volume to replay.

How do I restore backup data to the source instance?

For sharded cluster cloud disk instances, you can use the database and table restoration feature to restore data to the source instance. For more information, see Restore one or more databases of an ApsaraDB for MongoDB instance.

If your instance does not support restoring data to the source instance using the database and table restoration feature, you can restore the backup data to a new instance. Then, you can either switch the endpoints and port numbers of the source and new instances or use Data Transmission Service (DTS) to migrate data from the new instance to the source instance.

To modify the endpoint and port of an instance, see Modify the endpoint and port.
For more information about data migration using DTS, see Migration solutions for self-managed MongoDB databases or ApsaraDB for MongoDB instances.

How do I restore a downloaded backup file to an ApsaraDB for MongoDB instance?

You cannot directly restore a downloaded backup file to an ApsaraDB for MongoDB instance. You can first restore the data to a self-managed database and then use DTS to migrate the data to the ApsaraDB for MongoDB instance. For more information about data migration using DTS, see Migration solutions for self-managed MongoDB databases or ApsaraDB for MongoDB instances.

If my instance type does not support downloading backup files, how can I restore data to a self-managed database?

You can use DTS to migrate instance data to a self-managed database. For more information, see Migration solutions for self-managed MongoDB databases or ApsaraDB for MongoDB instances.
You can use the native MongoDB backup and restore tools, Mongodump and Mongorestore, to back up and restore the instance.

Why does the shard ID of a cloned sharded cluster instance differ from the output of the sh.status() command?

The Config Server of a sharded cluster instance stores routing metadata for all sharded collections, including the config.collections and config.chunks collections. Documents in these collections contain fields such as shard: 'shard01' that identify the shard to which the data belongs. Clone restoration requires the complete routing data of the source instance, so the source shard IDs (shard names) must be retained. As a result, the shard IDs of the cloned instance differ from the shard names displayed in the sh.status() output.

You can map them by comparing the Shard ID (replicaSetName) on the instance details page in the console with the sh.status() output. This mapping remains unchanged after restoration.