MONGO DATABASE BACKUP AND RESTORATION

Srinivas Maddali
Backup Methods as described in Mongo docs (published by 10Gen.com)

http://docs.mongodb.org/manual/core/backups/

There are 2 methods of backups:

01. Binary database dumps are comparatively small, because they don’t include index content or pre-allocated free space, and record padding. However, it’s impossible to capture a copy of a running system that reflects a single moment in time using a binary dump.

02. Filesystem snapshots, sometimes called block level backups, produce larger backup sizes, but complete quickly and can reflect a single moment in time on a running system. However, snapshot systems require filesystem and operating system support and tools.

03. We can also use LVM on a Linux System using lvm CLI

lvcreate – size 100M –snapshot –name mdb-snap01
File system snapshots are not considered here as the databases are not large enough for such operations. In future, if the databases grow larger we may consider that methodology by splitting the mirror and then mounting the files systems on the backup server for backup to tape.
There is also NetBackup snapshot method of backups for the VMs, if that includes the current NetBackup licenses.
For now we have developed a strategy to dump the database to the file system and then back it up to the tape using NetBackup client file system backup methods defining a separate policy. This method is used in PostgreSQL database environment successfully.
Binary database dump method process
01. Deleting old backup from the previous backup directory i.e ,. /mongo/backup/previous
rm -rf /mongo/backup/previous/*
02. Moving the backup from current directory to previous directory i.e,./mongo/backup/current
mv /mongo/backup/current/* /mongo/backup/previous/.
03. Run the backup shell script that has the following options for talking backup binary dump
mongodump --host $HOSTNAME --port 27017 --out /mongo/backup/current/mongodump-$LOGDATE –-oplog

Note: Don’t use –oplog option with the database if we are relocate the backup as to create a snapshot of the database.

For each day a directory is created with date time stamp on it and dump files are created.
--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.

--oplog has no effect when running mongodump against a mongos instance to dump the entire contents of a sharded cluster. However, you can use --oplog to dump individual shards.

Note

--oplog only works against nodes that maintain a oplog. This includes all members of a replica set, as well as master nodes in master/slave replication deployments.

We are not able to determine if all mongo databases are created with oplog option enabled or not as we could not find show command with database options.
After the backup is completed the same is backed up to the tape using NetBackup file system backup client.
As we currently do not have NetBackup configured in stage, the same is not reflected in this Document.
The document created for production databases of Mongo, we will be including that part.
Restoring mongo database from the binary dump
01. To restore the database to database path:
mongorestore–dbpath

02. To restore mongo dump to a different server with a different port with different password use the following options with mongorestore

mongorestore --host stg-idmdb03.vrli.net--port 37017 --username
--password

03. To restore and recover the database to the point in time recovery when a production database is lost or crashed demanding a restore and recovery

mongorestore–-oplogReplay