Backup and Restore in MongoDB

From Training Material
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.


Backup and Restore

  • backups generally should be done on secondaries
  • or on standalone servers at an off time


Method #1: Filesystem Snapshot

  • the simplest way to make backup
  • filesystem must support snapshotting
  • mongod must run with journaling enabled
  • stop mongod before restoring


# Create the snapshot volume
lvcreate -L128M -s -n dbbackup /dev/ops/databases

# Mount the snapshot volume
mkdir /mnt/ops/dbbackup
mount /dev/ops/dbbackup /mnt/ops/dbbackup

# Do the backup
tar -cf /dev/rmt0 /mnt/ops/dbbackup

# Remove the snapshot
umount /mnt/ops/dbbackup
lvremove /dev/ops/dbbackup


Method #2: Copying Data Files

  • use fsyncLock() before copying files
    • fsycnLock() prevents all databases against any further write
    • saves all dirty data to disk
    • queues all write operations
  • now files are consistent and copying of all files is possible
  • fsyncUnlock() releases the lock and brings back database to normal operations
  • if using authentication do not log out from the console between fsyncLock() and fsyncUnlock()
  • stop mongod before restoring
    • do not restore single database if crash or hard shutdown occurs


> db.fsyncLock()
> db.fsyncUnlock()


Method #3: Using mongodump and mongorestore

  • mongorestore is slower than previous methods and has other downsides
  • good way to backup individual databases or collections
  • it will create a dump directory (with subdirectories for each database) in current directory
  • data is stored in .bson files
  • mongodump can be used when mongod is not running
    • do not use --dbpath when mongod is running
  • when mongodump is running writes are allowed so already backuped data may change before mongodump will finish
    • do not use fsyncLock() when using mongodump
    • use --oplog if you are running mongod with --replSet
  • mongodump will choose secondary when connected to replica set
  • use mongodump and mongorestore in the same version
  • try to avoid this type of backup if you have unique indexes other than _id


mongodump --help
mongodump --port 27017
mongodump --dbpath /var/lib/mongodb
mongorestore --port 27017 --drop
mongodump --port 27017 --oplog
mongorestore --port 27017 --oplogReplay dump/
mongorestore -d dstDB -c dstCollection dump/srcDB/scrColl.bson


Backup of Replica Set

  • all previous methods are OK but 1st and 2nd are recommended (without any modifications)
  • when using mongodump use --oplog
  • when restoring with mongorestore:
    1. start a server as a standalone and
    2. restore the data with --oplogReplay and
    3. restore the oplog collection
    4. restart the server as a member of replica


> use local
> db.createCollection("oplog.rs", {"capped" : true, "size" : 1000000})
$ mongorestore -d local -c oplog.rs dump/oplog.bson


Backup of Sharded Cluster

  • usually it can not be done perfectly
  • instead of backing up everything at once, backup servers separately
  • turn off balancer before making backup
  • run mongodump through mongos to backup entire cluster
  • problems with restoring single shard