Backup and restoration

ApsaraDB for MongoDB provides a variety of solutions that allow you to back up or restore data in different scenarios. The following table describes the solutions provided by ApsaraDB for MongoDB in various scenarios.

Overview

Note

The following table describes the backup and restoration solutions provided by ApsaraDB for MongoDB. The - symbol in the table indicates that the solution is not fixed to any specified scenarios. Select the solution that suits your business requirements and preferences.

Operation	Solution	Supported instance architecture	Scenario

Operation	Solution	Supported instance architecture	Scenario
Back up databases	Configure automatic backup for an instance	Standalone instances Replica set instances Sharded cluster instances	-
	Configure manual backup for an instance	Standalone instances Replica set instances Sharded cluster instances	Applicable to scenarios in the gaming industry, such as server maintenance before version releases. You can manually back up data before version releases.This way, you can quickly roll back to the original status after issues occur.
	Configure high-frequency backup for an instance	Replica set instances that use cloud disks Sharded cluster instances that use cloud disks	Applicable to scenarios in which the write loads are heavy. The main bottleneck of point-in-time restoration may exist in the incremental log playback phase. If you enable high-frequency backup, the restoration time can be significantly shortened.
	Configure cross-region backup for an instance	Replica set instances that use cloud disks Sharded cluster instances that use cloud disks	Applicable to scenarios in which backup data is used for cross-region disaster recovery. When a region-level failure occurs, you can use the cross-region backup data to recover your services.
Restore backup data to ApsaraDB for MongoDB instances	Restore the databases of an instance to the original instance	Replica set instances that use cloud disks Sharded cluster instances that use cloud disks	Applicable to scenarios in which one or more databases need to be quickly restored. For example, you can use this solution if you delete a collection or document by mistake.
	Restore the databases of an instance to a new instance	Replica set instances that run MongoDB 4.2 or earlier and use local disks
	Restore backup data to a new instance by point in time	Replica set instances Sharded cluster instances	Applicable to scenarios in which data of multiple databases in an instance or data of the entire instance needs to be restored to a specific point in time.
	Restore backup data to a new instance by backup point	Standalone instances Replica set instances	Applicable to scenarios in which an entire instance needs to be restored but data timeliness is not a key requirement.
	Restore the instance data to a different region	Replica set instances that use cloud disks Sharded cluster instances that use cloud disks	Applicable to scenarios in which data monitoring or disaster recovery is required. You can use cross-region backup files to restore the instance data to a new instance in the region where the backup files reside.
Restore backup data to self-managed databases	Restore the instance data to a self-managed MongoDB database by using logical backup	Replica set instances that run MongoDB 4.2 or earlier and use local disks Sharded cluster instances that run MongoDB 4.2 or earlier and use local disks	Applicable to scenarios such as business testing or data analysis. Note Before you restore backup data to self-managed databases, you must download backup files. For more information, see Download a backup file.
Restore backup data to self-managed databases	Restore the instance data to a self-managed MongoDB database by using physical backup	Replica set instances that run MongoDB 4.2 or earlier and use local disks

FAQ

How do I restore the instance data that is generated at an earlier time point?

The time range to which the instance data can be restored depends on the specified retention period of the backup data. For more information about how to restore data generated at an earlier time point, see Retain the backup files of an instance for a long period of time.

How do I restore the backup data to the original instance?

For a sharded cluster instance that uses cloud disks, you can use the database and collection restoration feature to restore the instance data to the instance. For more information, see Restore the databases of an instance.

If the data of your instance fails to be restored to the instance by using the database and collection restoration feature, you can restore the backup data to a new instance and then modify the endpoint and port information of the original and new instances or use Data Transmission Service (DTS) to migrate data from the new instance to the original instance.

For more information about how to modify the endpoint and port information of an instance, see Modify the endpoint and port of an instance.
For more information about how to use DTS to migrate data, see Migrate data from a self-managed MongoDB database or an ApsaraDB for MongoDB instance.

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

You cannot restore a downloaded backup file to an instance. To restore a downloaded backup file to an instance, restore the file to a self-managed database and then use DTS to migrate the file from the database to the instance. For more information about how to use DTS to migrate data, see Migrate data from a self-managed MongoDB database or an ApsaraDB for MongoDB instance.

How do I restore the instance data to a self-managed database if the instance architecture does not allow I to download backup files?

You can use DTS to migrate the instance data to a self-managed database. For more information, see Migrate data from a self-managed MongoDB database or an ApsaraDB for MongoDB instance.
You can back up and restore the instance by using mongodump and mongorestore provided by ApsaraDB for MongoDB.

What is the impact if I back up an instance?

For an instance that uses local disks, backup is executed only on hidden nodes without degraded instance performance.
However, if the instance runs a version earlier than MongoDB 4.2, a certain amount of disk space is inflated during full backup. If a primary/secondary switchover is triggered for your instance, an original hidden node becomes a secondary or the new primary node, which causes a disk utilization fluctuation. For more information about a primary/secondary switchover, see Primary/secondary switchover. If such an situation is observed, analyze it in conjunction with the current backup operation and switchover records.
For an instance that uses cloud disks, backup has a small impact on instance performance.
- Backup execution node: Backup is executed only on secondary or hidden nodes and does not affect the performance of a primary node.
- Physical backup optimization: ApsaraDB for MongoDB optimizes physical backup to avoid expensive operations such as fsync or writing new checkpoint.
- Overhead of disk snapshots: The creation of disk snapshots has a low overhead. For more information about the principles and implementation details, see Overview.

Related API operations

Operation	Description

Operation	Description
DescribeBackups	Queries the backup files of an ApsaraDB for MongoDB replica set instance.
DescribeClusterBackups	Queries the backup sets of an ApsaraDB for MongoDB sharded cluster instance.
ModifyBackupPolicy	Modifies the backup policy of an ApsaraDB for MongoDB instance.
DescribeBackupPolicy	Queries the backup policy of an ApsaraDB for MongoDB instance.
CreateDBInstance	Restores the data of an ApsaraDB for MongoDB instance to a new replica set instance.
CreateShardingDBInstance	Restores the instance data to a new sharded cluster instance.
CheckRecoveryCondition	Checks whether an ApsaraDB for MongoDB instance meets the data restoration conditions.

Overview

FAQ

Related API operations

Sales Support

Technical Support

Connect & Report Abuse