0

There is a "LVM-solution" in MongoDB documentation: http://docs.mongodb.org/manual/tutorial/backup-sharded-cluster-with-filesystem-snapshots/

Can I do the same thing, but without using LVM snapshots, simply copy the files of my secondaries, and include a "mongodump" of my config data?

1

2 Answers 2

1

As the page you linked implies, any point in time snapshot technique that includes the data files and the journal will suffice, LVM is just one option. EBS snapshots in Amazon EC2 will also work, as will similar snapshot solutions on SAN, NAS etc. You are not limited to LVM, but that is generally a solution people can implement themselves.

In terms of whether you can copy files to perform a backup, the answer is yes, but only if you stop all writes to the node you are backing up (thereby guaranteeing no changes to the files during the copy). You can do this in a couple of ways:

The most straight forward way is to just shut the node (this should be a secondary) down, copy the files, then start the node back up and let it catch up to the primary (check optime using rs.status()). Rinse and repeat (if you wish) to cycle through all nodes in the set, though the nodes are all identical, so one copy should generally be enough.

The second way (mentioned by sysadmin1138) is to fsync (flush data to disk) and lock (prevent writes) the node but leave it running using the fsyncLock command (again, this should be a secondary). Once you have completed the copy, you unlock the database using the fsyncUnlock command. There are dangers inherent in this technique - for example (and particularly if you are using authentication), you should always lock and unlock on the same connection, otherwise you risk locking yourself out of the database and having to kill the process to recover.

As for other risks, it is common to use a hidden node for backups in each case, which prevents accidentally attempting reads from the node while it is behind, and/or while it is locked (depending on your methods).

Finally, there is one further (paid) option - MMS Backup. This service will essentially do all this for you (for a fee) and give you extras like point-in-time recovery and more - note: I work for MongoDB so I won't give you the hard sell here, but feel free to evaluate it yourself.

2
  • I want to keep for this task a separate node (ever-secondary replica), so it's no problem for me to stop writes by fsyncLock or completely shutdown mongod. So I'm going to "scriptyze" all operations you described and try it. I will write about the results. Thx!
    – pys
    Apr 10, 2014 at 8:16
  • great :) - just to note, others have done similar before you - I have seen scripts that have been released under the GPL, so you may not have to start from scratch here. The only reason I didn't link to them is that I have not personally used them - relatively easy to find by Googling though
    – Adam C
    Apr 10, 2014 at 9:14
1

The LVM method works they way it does because snapshots are really fast, and the outage is really small and easily within the replication-log window. Using file-copy methods extends how long the replica-member is not replicating, so how long you can take to back up is constrained by the maximum replication-log allowed on the master node.

Secondly, snapshotting takes a point-in-time backup of all files at the same time which improves the consistency of the backup. For a file-copy style backup the files will be read sequentially, so the use of db.fsyncLock() is massively important; if you don't, the chance you're backing up inconsistent files is really high. It's the use of db.fsyncLock() that starts causing the replica to fall behind and the replica-log to increase on master.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.