In order to prevent a disastrous loss of data, you’ll need to backup your database regularly. Having a good backup and restore strategy in place will help protect your databases and avoid data loss caused by failure(s). The best practice after taking your backup is to test it. It is highly recommended to test your backup it on regular basis. You can achieve that by restoring it to test MongoDB deployment.
The MongoDB backup and restore module provides an essential safety measure for protecting data stored in MongoDB Server databases.
This blog post describes the main methods for backup and restore MongoDB data using the different approaches.
1. Mongodump / mongorestore
mongodump is a utility that performs a backup of MongoDB data. You can use mongodump to backup database, collection based on your specific needs. You can enable consistent snapshot of the data by dumping the oplog.
On the other hand, Mongorestore utility is used to load the dumped BSON data into a newly created or an existing mongod/mongos instance.
It is recommended to use mongodump and mongorestore on small system and not on large system. The reason for that the tools are resource intensive and all data is read through the MongoDB memory while the instance is running.
2. Backup and Restore Underlying Files
You can backup MongoDB by using filesystem snapshots or by copying MongoDB files directly. Filesystem snapshots uses system-level tools to copy database files with minimal downtime and can be used to back up a sharded cluster and a replica set.
The biggest downside of using this method is that you cannot use replica set point in time recovery, because it is not supported. Also, it is very complicated for large sharded clusters.
There are two options to obtain a coherent snapshot of the MongoDB database:
1. Stop writes and lock databases, followed by using Linux standard file system copy tools such as rsync, cp.
2. Create a snapshot of the entire file system considering the following:
- Use dedicated mount points for all MongoDB data files.
- Enable journaling.
- Disable the balancer and take a same time snapshot from every shard and config server.
Restoring data taken by filesystem snapshot by copying the underlying file is straight forward. You create a new volume and mount it and then restore from the required snapshot or just straight restore to your specific volume.
3. MongoDB Cloud Manager or Ops Manager
MongoDB offers continuously online backup using Ops Manager or MongoDB Cloud Manager. MongoDB Cloud Manager is online hosted service and Ops Manager is a package both are used to manage MongoDB deployments. They can be used to continually to read the oplog and take backup of replica sets and sharded clusters.
Cloud Manager and Ops manager Backups offer point-in-time recovery and scheduled snapshots and of your MongoDB replica sets and sharded clusters.
Your Backup Workflow described as follow:
1. Activate or install the Backup Agent in your environment.
2. Perform initial sync to MongoDB datacenters.
3. Tailing of the oplog.
4. Snapshots are taken or restored as defined by the user retention policy.
Restore Data with Cloud Manager / Ops Manager
You can restore a standalone MongoDB process, or an entire replica set or sharded cluster using Cloud Manager/Ops Manager. To restore a MongoDB deployment from a backup, select a the wanted snapshot from an existing snapshot list or point in time between existing snapshots.
Snapshot restore can be done automatically, where Cloud Manager / Ops Manager read straight from the snapshot storage. Otherwise, you can manually download the HTTPS link associated with the snapshot files and copy them to your wanted server.
Point in time or a checkpoint restore is done by restoring a full snapshot and then appyling the oplogs until it reaches the specified point specified.
And there you have it. If you’re looking for support for MongoDB, we’re here to help as a MongoDB Premier Partner. We can provide end-to-end solutions customized on what your organization needs. Contact us to learn more.
Subscribe to Our Blog
Never miss a post! Stay up to date with the latest database, application and analytics tips and news. Delivered in a handy bi-weekly update straight to your inbox. You can unsubscribe at any time.
Most people will encounter this error when their application tries to connect to an Oracle database service, but it can also be raised by one database instance trying to connect to another database service via a database link.
Imagine over 100 logins on the source server, you need to migrate them to the destination server. Wouldn’t it be awesome if we could automate the process?