One of the most common scenarios for needing to go to a backup is human error. Someone releases buggy code to production. You drop a collection by accident. Some hackers breached your internal network and dumped political slogans all over your data. Or maybe you’re just worried about such a thing happening, and you want to try starting over, just in case the worst should happen.
Note: Before being able to restore, you would have to configure how to receive the backup files, either HTTPS “pull” or SCP “push” restore formats. If you’re not sure about using HTTPS vs SCP, watch this tutorial.
Now that you’ve decided what format you’d like to use, make sure that whatever machine will be downloading the snapshot has sufficient disk space. On a Linux server, this can be done by running
df -h. In Windows, this information can be found in My Computer by right-clicking on the drive in question. In OSX, you can option-click the relevant hard drive in any Finder window. Then compare it to the size in your Sharded Cluster Status or Replica Set Status page in MMS.
Once you’ve decided on the delivery method, and know you have enough disk space, you can retrieve the snapshot. If you’re running sharded clusters, you can find your snapshots in your Sharded Cluster Status page. If you’re running replica sets, you can find them in your Replica Set Status page. In either case, you then click on the replica set or shard you want to restore and you will see your snapshots. Click on the “restore this snapshot” link for the snapshot you wish to restore. The popup will give you the ability to select the delivery method, and in the case of SCP, test it.
To restore your data, you can either:
- Restore from a Stored Snapshot, which is the fastest restoration method to restore historical information. Data from the stored snapshot will be slightly older than the very latest data received by the backup service, however, depending on the cause of the data corruption this might be acceptable or even ideal.
- Restore from a point in time in the last 24 hours. If you’re sure that your corruption issue took place within the last 24 hours, you can restore from a snapshot prior to when the failure occurred. MMS will then generate a new snapshot at your request based on the your selection via the UI. If the data corruption is from before 24 hours ago, you must restore from a stored snapshot (option #1).
If only one collection or database is corrupted, you may opt to use the mongodump utility in combination with your backup snapshots to pull out the data you need. Once extracted, the data can be imported into a running mongod using mongorestore.
To have this same functionality for sharded clusters, you should configure cluster checkpoints for MongoDB by going to the Sharded Cluster node within MMS Backup and clicking the gear icon that appears next to the cluster. These checkpoints can be configured to take place every 15, 30, or 60 minutes, and you can also decide how long to store each clustershot.