Overview of data restoration solutions for ApsaraDB for MongoDB - ApsaraDB for 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 set	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.
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 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?

A cloned instance inherits the complete routing data from the source instance, including its shard IDs (shard names). The documents in these collections contain a field similar to shard: 'shard01' that identifies which shard the data belongs to. This causes a mismatch between the retained shard ID and the shard name displayed in the sh.status() output of the cloned instance.

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.