Home / server / Questions / 284553
Accepted
James Simpson
Asked: 2011-06-28 08:15:40 +0800 CST

Is this a valid backup strategy for MongoDB?

  • 772

I've got a single dedicated server with a MongoDB database of around 10GB. I need to do daily backups, but I can't have downtime with the database. Is it possible to use a replica set on a single disk (with 2 instances of mongod running on different ports), and simply take the secondary one offline and backup the data files to an offsite storage such as S3 (journaling is turned on)? Or would using master/slave be better than a replica set?

Is this viable, and if so, what potential problems could I have? If not, how do I conceptualize this to work?

backup mongodb database-backup

3 Answers

  1. Best Answer

    ReplicaSet will work in this scenario. However, I cannot tell if having two MongoDB instances at the same server is a good idea -- this depends on the server hardware/software and load.

    To make sure your backup MongoDB node does not become master, set its priority parameter to 0, e.g.

    rs.add({_id: 1, host: "localhost:<port>", priority: 0})

    NOTE: if you cannot have downtime, you SHOULD have at least 2 primary MongoDB nodes in ReplicaSet, see article

    • 6

  2. One strategy to consider is using the "hidden" option on the backup node on your replicaset. From the MongoDB blog:

    Hidden servers won’t appear in isMaster() results. This also means that they will not be used if a driver automatically distributes reads to slaves. A hidden server must have a priority of 0 (you can’t have a hidden primary). To add a hidden member, run:

    rs.add({"_id" : num, "host" : hostname, "priority" : 0, "hidden" : true})

    • 2

  3. Replica sets are preferred in general but also in this case simply because of their auto-recovery and auto-resync functionality. The backup method you are describing sounds perfectly reasonable and has been used before with other databases as well.

    The only potential problem I see is that under certain circumstances your secondary may be promoted to your primary and you'll either a) need to take your backup from the new secondary, or b) make your backup script smart enough to tell that instance of MongoDB to step down.

    The good news is that it should be fairly trivial to

    1. Query your backup source to find out which instance is primary and which is secondary (db.isMaster())
    2. Convince backup instance to step down using the rs.freeze() and rs.stepDown() commands or reconnect to secondary
    • 1