Overview of backup and recovery solutions - ApsaraDB for MongoDB

ApsaraDB for MongoDB provides various backup and recovery solutions for different scenarios.

Solution overview

Note

A hyphen (-) in the table indicates that there is no fixed scenario. You can choose a solution based on your needs and preferences.

Task	Implementation	Supported instance types	Scenarios
Back up a database	Automatically back up MongoDB data	Standalone instances Replica set instances Sharded cluster instances	-
	Manually back up MongoDB data	Standalone instances Replica set instances Sharded cluster instances	Suitable for scenarios such as operations and maintenance (O&M) during service downtime before a new version release in the game industry. You can create a manual backup before a business release. This lets you quickly roll back to the state before the change if issues occur.
	High-frequency backup	Replica set cloud disk instances Sharded cluster cloud disk instances	Suitable for business scenarios with heavy write workloads. The main bottleneck for a point-in-time restore can be the incremental log replay phase. Enabling high-frequency backup can significantly reduce the restoration time.
	Cross-region backup	Replica set cloud disk instances Sharded cluster cloud disk instances	Suitable for cross-region disaster recovery of backup data. If a region-level failure occurs, you can use the off-site backup data to restore your business.
Restore backup data to an ApsaraDB for MongoDB instance	Restore one or more databases of an ApsaraDB for MongoDB instance to the source instance	Replica set cloud disk instances Sharded cluster cloud disk instances	Suitable for business scenarios that require fast data restoration for one or more databases, such as recovering an accidentally deleted collection or document.
	Restore one or more databases of an ApsaraDB for MongoDB instance to a new instance	Replica set instances with local disks that run MongoDB 4.2 or earlier
	Restore backup data to a new instance based on a point in time	Replica set instances Sharded cluster instances	Suitable for restoring multiple databases or an entire instance to a specific point in time.
	Restore backup data to a new instance based on a backup point	Standalone instances Replica set instances	Suitable for scenarios where you need to restore an entire instance and the data timeliness requirements are not high.
	Restore data across regions	Replica set cloud disk instances Sharded cluster cloud disk instances	Suitable for scenarios such as data monitoring or disaster recovery. You can use backup files to restore data to a new instance in the region where the off-site backup is stored.
Restore backup data to a self-managed database	Restore data from a cloud disk backup	Replica set instances with local disks that run MongoDB 4.2 or earlier Sharded cluster instances with local disks that run MongoDB 4.2 or earlier	Suitable for scenarios such as business testing or data analytics. Note When you restore backup data to a self-managed database, you must first download the backup files. For more information, see Download a backup file.
Restore backup data to a self-managed database	Restore data from a local disk backup	Replica set instances with local disks that run MongoDB 4.2 or earlier

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.

What is the impact of a backup?

Instances with local disks: Backups are performed only on hidden nodes and have a negligible performance impact on the instance.
However, for instances that run a version earlier than 4.2, disk space may expand during a full backup. If a high availability (HA) switchover (primary/secondary switchover) occurs on your instance, the original hidden node may become a secondary or primary node. This can cause abnormal fluctuations in disk utilization. If you observe this phenomenon, you can analyze the cause by checking the backup operations and switchover records.
Cloud disk instances: Backups have a minimal performance impact on the instance. The details are as follows:
- Backup execution node: Backups are performed only on secondary or hidden nodes and do not affect the primary node.
- Physical backup optimization: Alibaba Cloud has optimized physical backups for MongoDB to avoid high-overhead operations such as fsync or writing a new checkpoint.
- Cloud disk snapshot overhead: The overhead of creating a cloud disk snapshot is very low. For more information about the principles and implementation details, see Snapshot overview.

Related API operations

API	Description
Querying an instance's backup list	Queries the backup list of an ApsaraDB for MongoDB replica set instance.
DescribeClusterBackups	Queries the backup list of an ApsaraDB for MongoDB sharded cluster instance.
ModifyBackupPolicy	Modifies the backup policy of an ApsaraDB for MongoDB instance.
View an instance's automatic backup policy	Queries the backup policy of an ApsaraDB for MongoDB instance.
Create or clone a replica set instance	Restores data to a new ApsaraDB for MongoDB replica set instance.
Create or clone a sharded cluster instance	Restores data to a new ApsaraDB for MongoDB sharded cluster instance.
Check if the instance meets the requirements for data restoration	Queries whether an ApsaraDB for MongoDB cloud disk instance meets the data restoration conditions.