Solutions and methods for data restoration - 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, consider the following:

The new instance must have the same major database version as the source instance. You must select a zone that supports this version. The available zones vary by database version. For more information about zone-related limits, see Usage notes.
The storage capacity of the new instance must be greater than or equal to that of the source instance.
If you upgrade an instance's major version, backups created before the upgrade cannot be restored to the new version.
By default, a new instance created for data restoration runs the latest kernel minor version.

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	Use this solution to recover accidentally deleted collections or documents.
	Replica set instance that uses local disks and runs MongoDB 4.0 or 4.2 Note For more information about limits, such as the supported regions, see Usage notes.	New instance	All databases Some databases
Create a new instance from a backup set	Standalone instance Replica set instance	New instance	All databases Some databases Note Only instances that use local disks support partial database restoration.	This solution is for scenarios where data timeliness is not a high priority.
Create a new instance using point-in-time recovery	Replica set instance	New instance	All databases Some databases Note Only instances that use local disks support partial database restoration.	Use this solution to restore instance data to a specific point in time.
Create a new instance using point-in-time recovery	Sharded cluster instance	New instance	All databases
Cross-region data restoration	Replica set instance that uses cloud disks Sharded cluster instance that uses cloud disks	New instance	All databases	This solution supports data compliance and disaster recovery. It lets you restore a backup file to a new instance in the region where the cross-region backup is stored.

Restore data to a self-managed database

To restore data to a self-managed database, you must first download the backup file of your ApsaraDB for MongoDB instance. For instructions, see 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.

Because MongoDB is continuously updated, older mongorestore versions may not be compatible with newer database versions. Always use a mongorestore version that is compatible with your MongoDB version. For more information, see 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. For more information about TDE, see 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.