Backup
& Restore

Required Roles for Backup Operations

// Minimum roles for mongodump user:
db.grantRolesToUser("backupUser", [
  { role: "backup",  db: "admin" },    // read all data + list collections
])

// Minimum roles for mongorestore user:
db.grantRolesToUser("restoreUser", [
  { role: "restore", db: "admin" },    // write all data + create collections
])

// Basic dump — entire cluster to ./dump/ directory
mongodump --uri "mongodb://user:pass@host:27017/?authSource=admin"

// Dump specific database
mongodump --uri "..." --db shopDb --out /backups/2024-03-01/

// Dump specific collection
mongodump --uri "..." --db shopDb --collection orders --out /backups/

// Dump with query filter (partial backup)
mongodump --uri "..." --db shopDb --collection orders \
  --query '{ "status": "completed", "year": 2024 }' \
  --out /backups/completed-orders/

// Compressed dump (gzip) — reduces size significantly
mongodump --uri "..." --gzip --out /backups/compressed/

// Archive mode — single file instead of directory tree
mongodump --uri "..." --gzip --archive=/backups/full-2024-03-01.gz

// Dump to stdout (pipe directly to S3)
mongodump --uri "..." --archive | gzip | aws s3 cp - s3://my-bucket/backup.gz

// Consistent backup with --oplog (captures oplog during dump for PITR)
// Run against PRIMARY of a replica set:
mongodump --uri "..." --oplog --out /backups/consistent/
// Creates dump/oplog.bson containing oplog entries applied during the backup
// Use mongorestore --oplogReplay to apply these entries after restore

// Dump specific collections with field exclusion (projection)
mongodump --uri "..." --db shopDb --collection users \
  --excludeFieldsForExport "password,creditCard" \
  --out /backups/redacted/

mongodump Limitations

// Restore entire dump directory
mongorestore --uri "mongodb://user:pass@host:27017/?authSource=admin" \
  /backups/2024-03-01/

// Restore to different database name (rename on restore)
mongorestore --uri "..." \
  --nsFrom "shopDb.*" --nsTo "shopDb_restored.*" \
  /backups/2024-03-01/dump/shopDb/

// Drop collections before restore (ensures clean state)
mongorestore --uri "..." --drop /backups/2024-03-01/

// Restore from compressed archive
mongorestore --uri "..." --gzip --archive=/backups/full-2024-03-01.gz

// Restore from stdin (from S3)
aws s3 cp s3://my-bucket/backup.gz - | mongorestore --uri "..." --gzip --archive

// Restore specific collection only
mongorestore --uri "..." --nsInclude "shopDb.orders" /backups/dump/

// Exclude collections during restore
mongorestore --uri "..." --nsExclude "shopDb.sessions" /backups/dump/

// Replay oplog for point-in-time consistency
// (use with dumps created using --oplog)
mongorestore --uri "..." --oplogReplay /backups/consistent/

// Replay oplog up to specific timestamp (partial rollforward)
mongorestore --uri "..." --oplogReplay \
  --oplogLimit "1709337600:1" \   // Unix timestamp:ordinal
  /backups/consistent/

// Control parallelism (default 4; increase for faster restore)
mongorestore --uri "..." --numParallelCollections 8 /backups/dump/

// Bypass document validation (if schema validation is applied)
mongorestore --uri "..." --bypassDocumentValidation /backups/dump/

Point-in-Time Recovery (PITR) uses a base snapshot plus the replica set oplog to replay operations up to an exact timestamp. This enables recovery to any second within the oplog window — critical for "recover to just before the accidental delete" scenarios.

// PITR Workflow:
// 1. Take base backup with --oplog (captures oplog during dump)
mongodump --uri "..." --oplog --out /backups/base-20240301T0000/

// 2. Separately, continuously backup the oplog
//    (or collect separate oplog archive at intervals)
mongodump --uri "..." --db local --collection oplog.rs \
  --query '{ "ts": { "$gt": { "$timestamp": { "t": 1709251200, "i": 1 } } } }' \
  --out /backups/oplog-incremental/

// 3. Restore base backup
mongorestore --uri "..." --drop --oplogReplay /backups/base-20240301T0000/

// 4. Apply incremental oplog up to target timestamp
//    Target: 1709337600 = 2024-03-01 08:00:00 UTC (just before the bad operation)
mongorestore --uri "..." --oplogReplay \
  --oplogLimit "1709337600:1" \
  /backups/oplog-incremental/

// Check the oplog timestamp of a specific event (to find your target):
use local
db.oplog.rs.find({ "o.dropCollection": { $exists: true } })
  .sort({ ts: -1 }).limit(5)
// Look at 'ts' field: Timestamp(1709337595, 1) → use 1709337594:1 to stop just before

Filesystem snapshots (LVM, AWS EBS, Azure Managed Disk) copy the block device at a point in time. For MongoDB with WiredTiger, the journal and data files must be on the same volume for a consistent snapshot — WiredTiger uses the journal to bring data to a consistent state on recovery.

// Verify journal and data are on the same volume (required for snapshot consistency)
// mongod.conf should have dbPath and storage.wiredTiger.engineConfig.journalPath
// on the SAME mountpoint

// Option A: flush and lock (safer, brief pause)
// Connect to a SECONDARY (to avoid pausing the primary)
use admin
db.fsyncLock()              // flush writes to disk + lock further writes
// NOW take the filesystem snapshot (EBS, LVM, etc.)
db.fsyncUnlock()            // resume writes (run immediately after snapshot initiated)

// Option B: snapshot secondary (preferred — no production impact)
// 1. Identify a secondary that is caught up
rs.printSecondaryReplicationInfo()  // confirm lag is near 0
// 2. Take filesystem snapshot of that secondary's data volume
// 3. No lock needed — WiredTiger journal provides consistency

// AWS EBS snapshot (run from EC2 or AWS CLI after fsync+lock):
// aws ec2 create-snapshot --volume-id vol-xxx --description "mongo-backup-$(date +%Y%m%d)"

// Restore from snapshot:
// 1. Stop mongod on target server
// 2. Restore data volume from snapshot
// 3. Start mongod — WiredTiger replays journal to reach consistent state
// 4. mongod joins replica set and syncs missing oplog entries automatically

MongoDB Atlas provides two backup tiers: Cloud Backup (snapshot-based) and Continuous Cloud Backup (point-in-time). Both are managed, requiring no operational setup.

// Atlas backup is configured in the Atlas UI / Atlas CLI — not mongosh

// Atlas CLI: list snapshots
atlas backups snapshots list --clusterName MyCluster --projectId <id>

// Trigger an on-demand snapshot:
atlas backups snapshots create MyCluster --desc "pre-migration snapshot"

// Create restore job from snapshot to new cluster:
atlas backups restores start automated \
  --clusterName MyCluster \
  --snapshotId <snapshotId> \
  --targetClusterName MyClusterRestored \
  --targetProjectId <targetProjectId>

// Point-in-time restore (continuous backup only):
atlas backups restores start pointInTime \
  --clusterName MyCluster \
  --pointInTimeUTCSeconds 1709337600 \
  --targetClusterName MyClusterPITR

// Download backup as compressed archive (restores to local mongod):
atlas backups restores start download \
  --clusterName MyCluster \
  --snapshotId <snapshotId>

RPO & RTO

Backup Selection by Use Case

// Backup verification checklist (automate this as a scheduled job):
// 1. Restore most recent backup to a staging/verify cluster
// 2. Run document count verification on critical collections
db.orders.countDocuments()
db.users.countDocuments()
// 3. Run spot checks on specific documents
// 4. Check oplog replay integrity (if PITR backup)
// 5. Record restore duration → validates RTO is achievable
// 6. FAIL LOUDLY if restore fails — backups that haven't been tested don't exist

// Production backup checklist:
// ✓ Backup frequency meets RPO (hourly PITR for RPO < 1 hour)
// ✓ Backups stored offsite / in different cloud region
// ✓ Backup encryption at rest enabled
// ✓ Backups tested monthly via restore-and-verify
// ✓ Oplog window >= backup interval + expected recovery time
// ✓ Backup user has minimum required roles (backup/restore only)
// ✓ Restore runbook documented and accessible during incident