Restoring MongoDB Atlas Database Backups in AWS
Restoring MongoDB Atlas Database Backups in AWS
These tips will help you keep your database restoration plans in shape. Get a look at how to restore MongoDB Atlas data to your clusters.
Join the DZone community and get the full member experience.Join For Free
Create a continuous deployment pipeline with open source tools. Watch the screencast.
DBAs, DevOps, or Sys Admin professionals spend valuable time writing scripts for managing database backups. Whether a combination of common tools such as rsync or native dump scripts, database backups tend to be tricky from the OS level. Then there are options to do things such as snapshots of the disk, but is the database currently in the middle of a write when this snapshot happens? Do you have a RAID for your volumes that is frozen when you do such a snapshot?
What about commercially licensed enterprise backup software if you aren't certain how to leverage one of the other options mentioned? Are you spending on both your software license costs and the physical storage to retain these backups? There could be options for you, but think about the cost associated with the hardware you may need, the software licensing, then the monitoring associated with ensuring the backups actually happened.
Does your database in the cloud right now have a recovery time objective? Does your database in the cloud right now have recovery point objective? These are business critical processes to consider if you need a sustainable continuity plan during any data layer failure A cohesive backup strategy is directly connected to the existence of some businesses.
Several months back, a large open source provider ran into an issue with database backups. The issue wasn't just that the backups weren't there, it was also that no one noticed the backups didn't work during a restore. This leads me to the next question: Who do you trust to ensure that the vital application data will be easily restored in the case of a failure?
MongoDB Atlas backups consistently provide you with point in time recovery of your MongoDB data. There's no human intervention, just access your backups in the Atlas control panel and start working with your recovery data. Atlas provides the ability to query one of the snapshots available to ensure that the data you're looking for exists prior to restoring it.
Let's go over how simple it is for you to either restore data to a new Atlas cluster, an existing cluster, or even to your local computer.
Restore to a New Cluster
If you decide you'd like another Atlas cluster with your MongoDB data, it only takes a few clicks. First, build your new Atlas cluster and name it something unique. Then go to the backup section in your Atlas control panel and select the backup you'd like to restore. It's important to ensure you restore to a like version cluster. That means restore MongoDB 3.2 database snapshots to MongoDB Atlas 3.2 clusters. The same goes for all MongoDB 3.4 clusters. You will not be able to mix and match versions of backup and cluster.
Cluster0-shard-0 is the name of my original cluster, I can go to the backups for this and select my snapshot or point in time backup I would like to restore. Once I finish selecting a snapshot, I click "NEXT" in the bottom of the restore menu.
Section 2 of the restore process asks, "Do you want to restore this snapshot to a MongoDB cluster or download a copy of your data?" In this case, I want to restore to a cluster, but I want to restore it to a new one. So first, I'll click "RESTORE MY SNAPSHOT" at the bottom of the window. I'll be brought to Section 3 of the restore process that will ask which replica set I want to restore to. I created "Cluster0-restore" just for this purpose, so I'll click the dropdown and select this cluster.
Once I click the restore button, the Atlas agents will begin to copy the contents of the snapshot over to your Atlas cluster. Once completed, it will ensure that all three nodes have replication working as normal.
Or Restore to the Same Cluster
You do not have to restore to a new cluster. If the current production database requires a restore, you can select it as the restore target.
Your cluster will restore the data to one cluster node at a time and ensure replication continues to work once the restore process is done. There's no need for you to modify the application's connection string either. You can just wait for the process to finish and get your app back to work.
Additionally, you can select an HTTPS based download of the snapshot if you would like to work with this data locally or even to place in a cold storage location.
Published at DZone with permission of Jay Gordon , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.