Automated Restores

MongoDB

#Cloud

If you’ve requested a restore from Cloud Manager Backup recently, and have Automation, you may have noticed a new option: Automated restores!

https://webassets.mongodb.com/_com_assets/blog/tblr/41.media.tumblr.com--d668ac6c9c60f738ebedd5a7f253b6e1--tumblr_nzd2ismEPT1sdaytmo1_400.png

With Automated Restores, you now have easier access to your restore files, in a way that plays nicely with Cloud Manager Automation. Here’s the requirements:

  • If you are restoring a replica set, you must have a replica set managed by Automation
  • If you are restoring a sharded cluster, you must have a sharded cluster with the same number of shards as the source cluster managed by Automation

In both cases, while you can restore into the same deployment entity that the backup came from, you should be certain that is what you want to do before doing it, as the automated restore process clears out the dbpath. Also, in both cases, you must be either in the Free Trial, or in Cloud Manager Standard, because you need to be actively using Automation.

Additionally, the target replica set or sharded cluster must be running the same storage engine as the snapshot you are looking to restore, so here’s how to change your storage engine with Automation.

Once you start an automated restore, the Automation Agent does the following:

  1. Clears out the dbpath on your replica set and cluster members
  2. Downloads a snapshot from Cloud Manager Backup and decompresses it
  3. Seeds the members oplogs so they won’t need to perform initial syncs between each other
  4. If you’re restoring a sharded cluster, they patch the cluster metadata to match the new shards’ locations
  5. Finally, they start up the MongoDB processes and make sure they’re happy

Could you do all this? Sure, but the Automation Agents make it easier!