Backup, Restore, and Disaster Recovery
What this domain covers
Backup, Restore, and Disaster Recovery tests whether you can meet RPO and RTO targets with logical, physical, and continuous backups, and restore correctly.
Core rules
- mongodump is logical: portable, slower, and not point-in-time consistent across a sharded cluster unless coordinated. mongorestore recreates indexes and data.
- For consistent backups, use filesystem snapshots on a journaled filesystem or db.fsyncLock() and fsyncUnlock() around the copy. On a replica set, snapshot a secondary.
- Oplog replay gives point-in-time recovery. mongodump --oplog captures oplog entries during the dump; mongorestore --oplogReplay applies them.
- Sharded cluster backups must include the config server replica set and every shard. Stop the balancer before backup and restore.
- Ops Manager and Cloud Manager provide continuous backup with oplog and snapshot scheduling.
Worked example
RPO is five minutes and RTO is one hour. Take hourly snapshots and retain the oplog, or use Ops Manager continuous backup. To restore, provision a new host, restore the snapshot, replay the oplog to the target timestamp, then point the application at the restored set. For a sharded cluster, stop the balancer, restore the config servers first, then each shard, then restart mongos.
Traps
Treating mongodump as point-in-time; forgetting the config servers in a sharded backup; restoring with --drop without verification; and assuming snapshots are consistent without journaling.