I am using mongodump and mongorestore for taking the backup and recovering the MongoDB sharded cluster 3.2. ( 3 node cluster)
I have created a database called "testing" which has a collection named "collection1" and "collection2"
I have then enabled sharding on the "testing" database and sharded the collections "collection1" and "collection2".
I then tried taking the backup using
mongodump -d testing --out /backups/shard
Backup worked fine.
Next, I have dropped the database "testing"
Now I tried to restore it back using mongorestore.
mongorestore -d "testing" /backups/shard/testing/
Restored completed.
Although the database and its collections were restored. I see that sharding is not enabled in the restored database.
How to retain the sharded information of a particular database so that after the restore operation, the collection should be in the same sharded state.
Related
I restored a database using this command
mongorestore --dbpath = <my backup database path>
and at the I got the : documents restored successfully
but when I use show databases in mongo, I see all of my databases except my restored databases.
I check this process for two different database but I have the same problem for twice of them.
The name of databases are all different.
I'm a SQL Server DBA trying to use MongoDB for some particular cases. What I have at the moment is 3 node replica set with 2 data bearing nodes and 1 arbiter. The thing that i'm struggling at the moment is finding a clear answer on ho to create Backups that will allow me a point in time restores, similar to what you have in MS SQL with FULL and LOG backups. How can i do that?
Mongodb provides different methods to Backup and restore
1. Back Up with Atlas(cloud based AWS services)
2. Back Up with MongoDB Cloud Manager or Ops Manager(Enterprise edition only. Supports backing up and restoring MongoDB replica sets and sharded clusters from a graphical user interface.)
3. Back Up with file system snapshot on OS( on Linux, the Logical Volume Manager (LVM) can create snapshots. Similarly, Amazon’s EBS storage system for EC2 supports snapshots)
To get a correct snapshot of a running mongod process, you must have journaling enabled. Without journaling enabled, there is no guarantee that the snapshot will be consistent or valid.
To create a snapshot with LVM, issue a command as root in the following format:
lvcreate --size 100M --snapshot --name mdb-snap01 /dev/vg0/mongodb
This command creates an LVM snapshot (with the --snapshot option) named mdb-snap01 of the mongodb volume in the vg0 volume group.
This example creates a snapshot named mdb-snap01 located at /dev/vg0/mdb-snap01. The location and paths to your systems volume groups and devices may vary slightly depending on your operating system’s LVM configuration.
To restore a snapshot , issue the following sequence of commands:
umount /dev/vg0/mdb-snap01
lvcreate --size 1G --name mdb-new vg0
dd if=/dev/vg0/mdb-snap01 of=/dev/vg0/mdb-new
mount /dev/vg0/mdb-new /srv/mongodb
for more details https://docs.mongodb.com/manual/tutorial/backup-with-filesystem-snapshots/#back-up-and-restore-using-lvm-on-linux
4.Back Up with mongodump (Terminal based Mongodb tools)
mongodump and mongorestore are simple and efficient tools for backing up and restoring small MongoDB deployments
mongodump and mongorestore operate against a running mongod process
If you dont specify any database it captures all the databases and copies into seperate folder along with indexes(json format) for every database
By default, mongodump does not backup the local database(which contains Replicaset configuration & oplog.rs collection).
For replica sets, mongodump provides the --oplog option to include in its output oplog entries that occur during the mongodump operation. This allows the corresponding mongorestore operation to replay the captured oplog. To restore a backup created with --oplog, use mongorestore with the --oplogReplay option.
Mongorestore captures only database files. indexes must be rebuild after restoring the data.
https://docs.mongodb.com/manual/tutorial/backup-and-restore-tools/#
commands:
mongodump --out /data/backup/ (It backups all the databases and indexes)
mongodump --collection myCollection --db test (specified database & collection)
mongorestore --port
I want to backup data in mongo shard. How i can backup no downtime because they're in production. I can't do from mongodb official manual.
Back Up a Sharded Cluster with Database Dumps
I have a standalone MongoDb instance. It has many databases in it. I am though only concerned with backingup/restoring one of those databases, lets call it DbOne.
Using the instructions in (http://www.mongodb.com/blog/post/dont-let-your-standalone-mongodb-server-stand-alone), I can create an oplog on this standalone server.
Using the tool Tayra, I can record/store the oplog entries. Being able to create incremental backups is the main reason I enabled the oplog on my standalone instance.
I intend to take full backups once a day, using the command
mongodump --db DbOne --oplog
From my understanding, this backup will contain a point-in-time snapshot of my db.
Assuming I want to discard all updates since this backup, I delete all backedup oplog and I restore only this full backup, using the command
mongorestore --drop --db DbOne --oplogReplay
At this point, do I need to do something to the oplog collection in the local db? Will mongodb automatically drop the entries pertaining to this db from the oplog? Because if not, then wouldn't Tayra end up finding those oplog entries and backup them all over again?
Tbh, I haven't tried this yet on my machine. I am hoping someone can point to a document that lists supported/expected behaviour in this scenario.
I had experimented with a MongoDb server, setup as a replica set with only 1 member, shortly after asking the question. I however forgot to answer this question.
I took a backup using mongodump --db DbOne --oplog. I executed some additional updates. Keeping the mongodb server as is, ie still running under replication, if I run the mongorestore command, then it would create thousands of oplog entries, one for each document of each collection in the db. It was a big mess.
The alternative was to shutdown MongoDb and start it as a standalone instance (ie not running as a replica set). Now if I were to restore using mongorestore the oplog wouldnt be touched. This was bad, because the oplog now contained entries that were not present in the actual collections.
I wanted a mechanism that would restore both my database as well as oplog info in the local database to the time the backup took place. mongodump doesnt backup the local database.
Eventually I had stop using mongodump and instead switched to backing up the entire data directory (after stopping mongodb). Once we switch to AWS, I could use the EBS Snapshot feature to perform the same.
I understand you want a link to the docs about mongorestore:
http://docs.mongodb.org/manual/reference/program/mongorestore/
From what I understand you want to make a point in time backup and then restore that backup. The commands you listed above will do that:
1)mongodump --db DbOne --oplog
2)mongorestore --drop --db DbOne --oplogReplay
However, please note that the "point in time" that the backup was effectively taken at it is when the dump ends, not the moment the command started. This is a fine detail that might not matter to you, but is included for completeness.
Let me know if there is anything else.
Best,
Charlie
I'm looking for the right way to do a Mongodb backup on a replica set (non-sharded).
By reading the Mongodb documentation, I understand that a "mongodump --oplog" should be enough, even on a replica (slave) server.
From the mongodb / mongodump documentation :
--oplog
Use this option to ensure that mongodump creates a dump of the database that includes an oplog, to create a point-in-time snapshot of the state of a mongod instance. To restore to a specific point-in-time backup, use the output created with this option in conjunction with mongorestore --oplogReplay.
Without --oplog, if there are write operations during the dump operation, the dump will not reflect a single moment in time. Changes made to the database during the update process can affect the output of the backup
I'm still having a very hard time to understand how Mongodb can backup and keep writing on the database and make a consistent backup, even with --oplog.
Should I lock my collections first or is it safe to run "mongodump --oplog ?
Is there anything else I should know about?
Thanks.
The following document explains how mongodump with –oplog option works to create a point in time backup.
http://docs.mongodb.org/manual/tutorial/backup-databases-with-binary-database-dumps/
However, using mongodump and mongorestore to back up and restore MongodDB can be slow. If file system snapshot is an option, you may want to consider using snapshot for MongoDB backup. Information from the following link details two snapshot options for performing hot backup of MongoDB.
http://docs.mongodb.org/manual/tutorial/backup-databases-with-filesystem-snapshots/
You can also look into MongoDB backup service.
http://www.10gen.com/products/mongodb-backup-service