Oops... something went wrong!

A few words about backup strategies for MongoDB

"There are two types of people in this world, those who have lost data, and those who are going to lose data"

Theory

Backup and DR testing

Real life

Database backup has been failing for the last week

mongodump

• basic method
• well-designed dump structure
• dump data to BSON/JSON
• time-consuming

mongodump useful options

• --dbpath --journalto dump without running MongoDB instance
• --oplog / --oplogReplayto dump / restore specific point-in-time backup

snapshots

• very fast
• use journaling!
• only partial backup solution
• complex solution

snapshots examples

• Disk array snapshots
• LVM snapshots (from LVM2 rw)
• ZFS snapshots
• BTRFS subvolume snapshots

Replication-based

• secondary member
• hidden member
• delayed member

Secondary member example

KMUG:SECONDARY> db.fsyncLock()
{
	"info" : "now locked against writes, use db.fsyncUnlock() to unlock",
		"seeAlso" : "http://dochub.mongodb.org/core/fsynccommand",
		"ok" : 1
}
KMUG:SECONDARY> exit
bye
root@KMUG:/tmp/backup-dir# mongodump
(...)
root@KMUG:/tmp/backup-dir# mongo
MongoDB shell version: 2.4.8
connecting to: test
KMUG:SECONDARY> db.fsyncUnlock()
{ "ok" : 1, "info" : "unlock completed" }

MongoDB Management Service Backup

• Cloud or on-premises software
• Paid option
• Flexible snapshot schedule and retention policy
• Requires additional agent
• 3 copies of data in at least 2 geographically dispersed locations
• Closed source

Tayra

• Still beta release
• Oplog-based incremental backup
• Not so popular
• Open source

Any questions?

Thank you for your attention