For small MongoDB deployments, mongodump is simple but slow to restore with no point-in-time recovery. Filesystem snapshots restore fast but only to the snapshot moment. Managed or oplog based backup is the route to low RPO and point-in-time recovery. Sharded clusters add consistency steps whichever you choose.
The options
The MongoDB manual lists these self-managed methods.
Oplog based backup (Cloud Manager or Ops Manager). Reads oplog data and takes snapshots at intervals, with point-in-time recovery. The manual rates it as low RPO and RTO with low impact on the source, and notes it needs a subscription and MongoDB Enterprise Server for the self-hosted version.
Filesystem snapshots. Volume manager snapshots such as LVM or EBS capture an exact moment. Restores are fast, but RPO is high and there is no point-in-time recovery. Journaling must be on, with the journal on the same logical volume as the data files.
cp or rsync. Copying data files directly. You must stop all writes first, because copying many files is not atomic. The backups are larger and this gets hard with big sharded clusters.
mongodump and mongorestore. Logical backups for small deployments. Smaller output, but the manual lists high RPO and RTO and no point-in-time recovery.
Choosing by what you can afford to lose
- Can lose a day, dataset is small: nightly mongodump, copied off host. Simple, and the restore is slow but understandable.
- Can lose some hours, restore speed matters: scheduled snapshots, plus a tested restore procedure.
- Cannot lose more than minutes, or you need to rewind to before a bad deploy: oplog based or managed backup with point-in-time recovery.
Set the target first. Our post on RPO and RTO shows how.
Sharded clusters are different
The manual warns that consistency is not guaranteed with snapshots or file copies of a sharded cluster. The procedure it describes is to disable the balancer, then capture snapshots of every shard and a config server at about the same moment, using fsync or a write lock to cut inconsistency. This is easy to get wrong in a hurry, so write the steps into a runbook and rehearse them.
Encryption at rest and restores
If you use encrypted storage, restoring from a hot backup is handled automatically, since MongoDB detects the dirty keys and rolls over the database key. A cold backup taken while the server was stopped is not detected. The manual says to start with the key rollover option to avoid IV reuse, which would undermine confidentiality and integrity. Keep this in the restore runbook, and make sure the encryption keys are themselves backed up, see backup encryption keys.
Prove it
Whichever method you choose, restore into a scratch cluster, run a count and a few known queries, and record how long it took.
Safeguard's compliance automation can hold the dated test record, and the free scan at gold.safeguard.sh/scan checks dependencies.
Quick check
Does mongodump give point-in-time recovery?
No. The MongoDB manual lists no point-in-time recovery for mongodump, and high RPO and RTO.
Can I copy data files while mongod runs?
Not safely with cp or rsync. Stop writes first, or use a snapshot method that captures one moment.
Sources
Last reviewed: 19 October 2026.
