ApsaraDB for MongoDB:Point-in-time recovery to a new instance

Supported instance types

• Replica set instances.

• Sharded cluster instances.

Usage notes

• For accurate point-in-time recovery, you must enable Log Backup. If Log Backup is disabled, ApsaraDB for MongoDB restores data from the nearest full backup due to missing oplog data, resulting in inaccurate data recovery. To learn how to enable log backup, see Automatically back up data for an ApsaraDB for MongoDB instance.

  Note

  You cannot perform a point-in-time recovery if the specified time point is outside the log backup retention period.

• Database-level recovery is supported only for physical backups and not for logical backups. If your ApsaraDB for MongoDB instance runs a version earlier than MongoDB 4.0 and has more than 10,000 collections and indexes, a physical backup may fail. Before you perform a physical backup, you can upgrade your ApsaraDB for MongoDB instance to MongoDB 4.0 or later. For more information, see Upgrade the major version of an instance.

  Important

  After a major version upgrade, backup files from the previous version cannot be used to restore data to the new version.

• Database restoration time depends on factors such as the data volume, task queue, and network conditions.

  • You cannot view the exact progress of the oplog replay or the estimated completion time. Use the change of the new instance status to Running as the indicator that the restoration is complete.

  • During restoration, the disk space used by the new instance increases gradually. Because of oplog replay and temporary files, the storage usage may temporarily exceed expectations. This is typically normal and does not affect the final restoration result. When the disk space usage of the new instance approaches the data volume of the source instance, the restoration is typically nearing completion.

  • Data restoration consumes compute resources on the new instance. A new instance with a lower specification (CPU or memory) is expected to take longer to complete restoration.

• If the source instance runs a minor version that is no longer maintained, the system automatically upgrades the new instance to the latest minor version during the restoration process. This ensures better performance and stability.

Billing

This operation creates a new instance and incurs charges. For more information, see Billing items and pricing.

Replica set instances

1. Go to the ApsaraDB for MongoDB Replica Set Instances page. In the top navigation bar, select a resource group and a region, and then click the ID of the target instance.

2. In the left-side navigation pane of the instance details page, click Backup and Restoration.

3. On the Full Backup tab, click Create Instance by Time Point.

4. In the Create Instance by Time Point panel, configure the following parameters and click OK.

   Parameter	Description
   Select Time Point for Restoration	Select the point in time from which to restore data. Note The restore point must be earlier than the current time and later than the instance creation time. The available time range for restoration is determined by the log backup retention period. For more information about how to configure log backup, see Automatically back up data for an ApsaraDB for MongoDB instance.
   Select Database for Restoration	All Databases: Restore all databases in the instance. Partial Databases: Restore specific databases in the instance. Select the required databases from the list, or click Enter Databases to enter the database names manually. Note If entering names manually, separate them with a comma (,). If you have upgraded the database version, backup files from the previous version cannot be used to restore data. Replica set instances that use cloud disks only support the All Databases option.

5. Create a new instance.

   1. On the Clone Instance page, select a Product Type.

      • Replica Set (Subscription): A prepaid billing method where you pay for the instance upon creation. This option is suitable for long-term needs and is more cost-effective than the pay-as-you-go option. The longer the subscription period, the larger the discount.

      • Replica Set (Pay-as-you-go): A postpaid billing method where you are billed hourly based on the instance specifications and the maximum storage capacity. This option is suitable for short-term needs. You can release the instance at any time to save costs.

   2. Configure the new instance. For parameter details, see Create a replica set instance.

      Important

      The storage capacity of the new instance must be greater than or equal to that of the source instance.

6. Purchase the instance.

   1. Click Buy Now.

   2. On the Confirm Order page, read the Service Agreement.

   3. Click Pay.

   4. Follow the on-screen instructions to complete the payment process.

Sharded cluster instances

1. Go to the ApsaraDB for MongoDB Sharded Cluster Instances page. In the top navigation bar, select a resource group and a region, and then click the ID of the target instance.

2. In the left-side navigation pane of the instance details page, click Backup and Restoration.

3. (Optional) In the upper-right corner of the page, click Upgrade to Cluster Backup Mode.

   Note

   This step is required only for sharded cluster instances that use cloud disks and were created before October 18, 2023. If this button is not displayed, the instance has already been upgraded.

4. On the Full Backup tab, click Create Instance by Time Point.

5. In the Create Instance by Time Point panel, configure the following parameters and click OK.

   Follow the procedure for your instance type.

   Cloud disk

   Parameter	Description
   Recovery Mode	Select Create Instance by Time Point. Note For information about how to use Database and Collection Restoration, see Restore one or more databases of an ApsaraDB for MongoDB instance.
   Valid Time Range	The time range available for restoration. This is a read-only parameter.
   Select Time Point for Restoration	Select the point in time from which to restore data. Note The restore point must be earlier than the current time and later than the instance creation time. The available time range for restoration is determined by the log backup retention period. For more information about how to configure log backup, see Automatically back up data for an ApsaraDB for MongoDB instance.
   Select Database for Restoration	The default value is All Databases. Note If you have upgraded the database version, backup files from the previous version cannot be used to restore data.

   Local disk

   Parameter	Description
   Select Time Point for Restoration	Select the point in time from which to restore data. Note The restore point must be earlier than the current time and later than the instance creation time. The available time range for restoration is determined by the log backup retention period. For more information about how to configure log backup, see Automatically back up data for an ApsaraDB for MongoDB instance.
   Select Database for Restoration	Select All Databases. Note If you have upgraded the database version, backup files from the previous version cannot be used to restore data. Sharded cluster instances that use local disks only support restoring all databases.

   Important

   • The restore point must be earlier than the current time and later than the instance creation time.

   • When restoring a sharded cluster instance, avoid selecting a time point that is too recent (usually within the last hour), as this may cause the restoration to fail.

   • The available time range for restoration is determined by the log backup retention period. For more information about how to configure log backup, see Automatically back up data for an ApsaraDB for MongoDB instance.

6. Create a new instance.

   1. On the Clone Instance page, select a Product Type.

      • Sharded Cluster (Subscription): A prepaid billing method where you pay for the instance upon creation. This option is suitable for long-term needs and is more cost-effective than the pay-as-you-go option. The longer the subscription period, the larger the discount.

      • Sharded Cluster (Pay-as-you-go): A postpaid billing method where you are billed hourly based on the instance specifications and the maximum storage capacity. This option is suitable for short-term needs. You can release the instance at any time to save costs.

   2. Configure the new instance. For parameter details, see Create a sharded cluster instance.

      Important

      • The number of shard nodes in the new sharded cluster instance must be the same as that in the source instance.

      • The storage capacity of each shard node in the new instance must be greater than or equal to that of the corresponding shard node in the source instance.

7. Purchase the instance.

   1. Click Buy Now.

   2. On the Confirm Order page, read the Service Agreement.

   3. Click Pay.

   4. Follow the on-screen instructions to complete the payment process.

FAQ

Q: Why can't I find the "Create Instance by Time Point" option in the console?

A: This feature is available only for replica set and sharded cluster instances. It is not supported for single-node instances.

Q: What is the difference between restoration from a backup point and point-in-time recovery?

A:

• Restoration from a backup point can restore data only to the point in time of the most recent full backup. This method is suitable for scenarios in which data timeliness is not critical. For more information, see Restore backup data to a new ApsaraDB for MongoDB instance by backup point.

• Point-in-time recovery can restore data to a precision of seconds and depends on log backup (oplog). This method is suitable for scenarios such as accidental data deletion in a production environment, where you need to precisely roll back to a specific moment.

• If data is accidentally deleted in a production environment, we recommend that you use point-in-time recovery to restore data to the moment right before the deletion, and configure the new instance with a specification no lower than that of the source instance. This helps avoid slow restoration, an out of memory (OOM) interruption, or the new instance being unable to handle production traffic because of an insufficient specification.