I've got a mongo cluster with three nodes, running 2.6, but probably going to 3.2
What is the best method to back-up a database in a replica set of three mongodb servers?
Should I use mongodump --db [dbname] --out [path]?
And do I back-up from the primary node, or the slaves? The database is about 30GB, so will the performance decrease during the backup of the other nodes?
I looked at the documentation here and here, but could not find my answer.
You could use:
For option 2, make sure to use mongodump with the --oplog option. If you need to restore, then use mongorestore with the --oplogReplay option.
With option 3, stop the secondary member, and copy the the data out. Or, if you do not desire to stop the secondary, use db.fsyncLock(), backup and then use db.fsyncUnlock().
Secondaries replica set members are ideal for reporting and backup use cases.
Reference: https://docs.mongodb.com/v3.2/core/backups/
Few months before I had to upgrade my production replica set of 3 servers from 3.0 to 3.2. But 3.0 used to use mmvpa1 storage engine so the file system was different in 3.2 than 3.0. So in the migration I used mongodump and mongorestore. I used my slaves for mongodump. But I do have a daily backup in AWS EBS volume. Which keeps a backup of the while machine everyday. And I think that is the best option. If you keep one of your replica sets slaves in daily backup it will do the job. With MongoDB 3.2 and more you can restore the database from this machine backup and make this server as a replica set member very easily.
Performance will decrease for sure. Under what circumstances ?
You should only be doing backups on SECONDARY nodes. The PRIMARY already has enough work performing inserts and writes. If your read preference is PRIMARY or PRIMARY Preferred, mongodump will compete with all find() and findOne() operations.
If your read preference is SECONDARY or SECONDARY Preferred, you need to designate one of the SECONDARY nodes as a hidden member. This should make this node not be selected to perform any queries but would still just perform replication. This makes a hidden node a prime candidate for doing backups.
If you do not change the SECONDARY into a hidden member and you launch a mongodump against it, all queries to that node will slow each other down for sure.
Please read the MongoDB Docs on Hidden Secondary Members on how to set up a hidden secondary.
I also run a three node replica set. We back up the entire instance, not just one database, but conceptually there's no real difference. We use a scripted mongodump pointing to a secondary replica and writing out to a network storage location. Do you have any performance metrics on how long your backup usually takes? Also, the CPU, memory, and network speed of the replicas will affect the time to back up and performance, so the impact of your 30 gig DB backup will depend heavily on these specs. Also, if you have readable secondaries that will impact backups depending on read only traffic to them during dump operations if you backup from a secondary replica. In any case dumping from the replica will isolate your production primary from the network load of the dump operation.
It depends what you want to achieve.
Generally yes, mongodump --db [dbname] --out [path], is the common way to perform backups.
If you need a point in time restore, you should use opsmager or cloud manager that keep both snapshots and tail the oplog as well.
Obviously you can arrange the same manually with mongodump, but you need to build scripts and orchestrate them. Furthermore opsmanager verify continuosly that the backup is restorable, applying to a sort of hidden replica all backups and trying to access them.
If you want to make a snapshot of your replica sets as backup you can use the MongoDB Cloud Manager Backup. Alternatively you can use the OpsManager, it has similar functions as the Cloud Manager but requirieres an Enterprise Advanced subscription. Also you can use mongodump to backup your data. However, for replica sets, the MongoDB Cloud Manager or OpsManger should eb your first choise.
The best method to backup your database depends on what you have available to you. If you have ops manager, by all means, it is the best option.
If you don't have access to ops manager, mongodump is a great next choice. It will affect your performance, so be sure to do your dump on off hours.
Another option if you are using vmware is a veem backup of each node. This would allow you to upgrade each node one at a time and if you run into any issues, roll back the entire vm. If you aren't using vmare, this isn't an option at all.
The worst option is to backup the entire /data directory, it can be done, but I wouldn't recommend it. Especially once you upgrade and are using wired tiger as it's a bit more complicated to restore from a directory dump in my experience.
Overall, your question is asking for opinions. That is what my post is, opinions. I think the fact is, any backup is better than no backup and I'll leave it there.
