When deploying MongoDB in production, have a backup and restore strategy to protect against data loss.
This page covers backup methods for self-managed deployments.
To learn more about Backup Methods for deployments hosted in MongoDB Atlas, see Back Up, Restore, and Archive Data.
Back Up with MongoDB Cloud Manager or Ops Manager
MongoDB Cloud Manager is a hosted backup, monitoring, and automation service for MongoDB. MongoDB Cloud Manager supports backing up and restoring replica sets and sharded clusters from a graphical user interface.
MongoDB Cloud Manager
Important
To back up your replica sets and sharded clusters using MongoDB Cloud Manager, you must be using MongoDB Enterprise Server. For more information, see Install MongoDB Enterprise.
MongoDB Cloud Manager backs up replica sets and sharded clusters by reading oplog data from your MongoDB deployment. MongoDB Cloud Manager creates snapshots at set intervals and offers point-in-time recovery.
Tip
Sharded cluster snapshots are difficult to achieve with other MongoDB backup methods.
To get started with MongoDB Cloud Manager Backup, sign up for MongoDB Cloud Manager. For documentation on MongoDB Cloud Manager, see the MongoDB Cloud Manager documentation.
Ops Manager
With Ops Manager, MongoDB subscribers can install and run the same backup software as MongoDB Cloud Manager on their own infrastructure. Ops Manager is available with Enterprise Advanced subscriptions.
For more information about Ops Manager, see the MongoDB Enterprise Advanced page and the Ops Manager Manual.
Back Up by Copying Underlying Data Files
Note
Considerations for Encrypted Storage Engines using AES256-GCM
For encrypted storage engines that
use AES256-GCM encryption mode, AES256-GCM requires that every
process use a unique counter block value with the key.
For encrypted storage engine
configured with AES256-GCM cipher:
- Restoring from Hot Backup
- If you restore from files taken through "hot"
backup while the
mongodis running, MongoDB detects "dirty" keys on startup and automatically rolls over the database key to avoid IV (Initialization Vector) reuse.
- Restoring from Cold Backup
However, if you restore from files taken through "cold" backup while the
mongodis not running, MongoDB does not detect "dirty" keys on startup, and reuse of IV voids confidentiality and integrity guarantees.To avoid the reuse of the keys after restoring from a cold filesystem snapshot, MongoDB adds a new command-line option
--eseDatabaseKeyRollover. When started with the--eseDatabaseKeyRolloveroption, themongodinstance rolls over the database keys configured withAES256-GCMcipher and exits.
If using filesystem-based backups for MongoDB Enterprise, use the "hot" backup feature.
Back Up with Filesystem Snapshots
If the volume where MongoDB stores its data files supports point-in-time snapshots, use those snapshots to create backups at an exact moment in time. File system snapshots are an operating system volume manager feature and are not specific to MongoDB. The operating system takes a snapshot of the volume to use as a baseline for backup. The mechanics of snapshots depend on the underlying storage system. For example, on Linux, the Logical Volume Manager (LVM) can create snapshots. Similarly, Amazon's EBS storage system for EC2 supports snapshots.
To get a correct snapshot of a running mongod process, you
must have journaling enabled and the journal must reside on the same
logical volume as the other MongoDB data files.
To get a consistent snapshot of a sharded cluster, you must disable the balancer and capture a snapshot from every shard as well as a config server at approximately the same moment in time. To backup sharded clusters, see Back Up a Self-Managed Sharded Cluster with a Database Dump.
For more information, see the Back Up a Self-Managed Deployment with Filesystem Snapshots and Back Up a Self-Managed Sharded Cluster with File System Snapshots for complete instructions on using LVM to create snapshots.
Back Up with cp or rsync
If your storage system does not support snapshots, you can copy the
files directly using cp, rsync, or a similar tool. Since
copying multiple files is not an atomic operation, you must stop all
writes to the mongod before copying the files.
Backups produced by copying the underlying data do not support point
in time recovery for replica sets and are difficult to manage for
larger sharded clusters. Additionally, these backups are larger
because they include the indexes and duplicate underlying storage
padding and fragmentation. mongodump, by contrast, creates
smaller backups.
Back Up with mongodump
mongodump and mongorestore are
tools for backing up and restoring small MongoDB deployments. To learn
more, see Back Up and Restore a Self-Managed Deployment with MongoDB Tools.
To backup sharded clusters, see Back Up a Self-Managed Sharded Cluster with a Database Dump.
Compare Backup Methods
The following table compares backup methods for on-premises deployments.
Backup Considerations | Cloud Manager/Ops Manager | Filesystem Snapshot | |
|---|---|---|---|
Backup RTO | Low/depends on snapshot store type | Low | High |
Backup RPO | Low | High | High |
Backup storage cost | Low/depends on snapshot store type | Medium | High |
Staff Time to Manage Backups | None/depends on snapshot store type | High | High |
Continually Point-in-Time backup and restore | Yes | No | No |
Complexity of the restore | Low if deployment is under automation | High for a sharded cluster | Low |
Complexity of a sharded cluster backup | Low | High, requires extra steps | High, requires extra steps |
Impact of the backup to the source sharded cluster deployment | Low | High, requires write lock | High, requires write lock |
Consistencies in the sharded cluster backup | Guaranteed | Not guaranteed, use | Not guaranteed, use |
Incremental backup | Yes, daily incremental backup and weekly full backup | Depends on storage and tool | No |
Define scope of backups | Yes, with namespace filtering | No | Yes |