MongoDB in Production: Atlas, Monitoring, and Backups

Running MongoDB in production is an operational discipline, not just a configuration exercise. This final lesson covers MongoDB Atlas — the managed cloud service that handles replication, patching, and backups automatically — alongside the monitoring, alerting, and backup strategies you need regardless of whether you run managed or self-hosted deployments.

Previous: Lesson 9 — Replication & High Availability

MongoDB Atlas Overview

Atlas is MongoDB's fully managed cloud service, available on AWS, GCP, and Azure. It removes the operational burden of managing mongod processes, replica sets, OS patches, and storage provisioning.

Cluster Tiers

Creating a Cluster

1. Sign in at and create a project
2. Click Build a Database → choose cloud provider and region
3. Select cluster tier (M0 for this course)
4. Set cluster name and click Create

Connecting Your Application

Atlas generates connection strings for every driver. For mongosh:

mongosh "mongodb+srv://username:password@cluster0.abc123.mongodb.net/myapp"

For Node.js (Mongoose):

mongoose.connect("mongodb+srv://username:password@cluster0.abc123.mongodb.net/myapp?retryWrites=true&w=majority")

retryWrites=true: automatically retries single-statement write operations on transient network errors. Always include this in production connection strings.

Connection String Best Practices

mongodb+srv://<username>:<password>@<host>/<database>?retryWrites=true&w=majority&readPreference=primaryPreferred&connectTimeoutMS=10000&serverSelectionTimeoutMS=10000

Never hardcode connection strings — inject via environment variables:

export MONGODB_URI="mongodb+srv://app:${DB_PASSWORD}@cluster0.abc123.mongodb.net/myapp?retryWrites=true&w=majority"

Monitoring with Atlas

Real-Time Performance Panel

Atlas provides a real-time performance panel at Cluster → Real-Time Performance Panel:

• Opcounters: reads/s, writes/s, commands/s
• Connections: active connections vs available limit
• Replication lag: how far secondaries are behind
• Disk I/O: read/write throughput and utilisation
• Network: bytes in/out per second

Metrics and Charts

Under Cluster → Metrics, Atlas exposes 100+ time-series metrics with configurable time ranges. The most important for day-to-day operations:

Setting Up Alerts

Atlas → Cluster → Alerts → Add Alert

Critical alerts to configure:

• Replication lag > 60s → pages on-call
• Primary election → always notify
• Disk space > 80% → warning; > 90% → critical
• CPU > 80% for 10 minutes → investigate indexing
• Query targeting > 1000 → index missing; add immediately

The Performance Advisor

Atlas Performance Advisor analyses slow query logs and recommends indexes automatically. Access it at Cluster → Performance Advisor.

For each suggested index it shows:

• The query shape it would optimise
• Estimated improvement in query execution time
• The createIndex() command to run

// Suggested index from Performance Advisor
db.orders.createIndex({ customerId: 1, status: 1, createdAt: -1 },
  { name: "orders_customer_status_date" })

Backups

Atlas Continuous Backup

Atlas M10+ clusters include continuous backup with point-in-time restore:

• Snapshots taken every 6 hours by default (configurable)
• Oplog retained for up to 24 hours enabling restore to any second within the retention window
• Retained snapshots: daily (7 days), weekly (4 weeks), monthly (12 months) — configurable

Restore from Atlas UI:

Cluster → Backup → Restore → Select snapshot or point-in-time → Choose target cluster

mongodump / mongorestore (Self-Hosted)

For self-managed deployments:

# Dump an entire database
mongodump \
  --uri "mongodb://admin:password@localhost:27017" \
  --db myapp \
  --out /var/backups/mongodb/$(date +%Y%m%d)

# Dump a single collection
mongodump \
  --uri "mongodb://admin:password@localhost:27017" \
  --db myapp \
  --collection orders \
  --out /var/backups/mongodb/orders_$(date +%Y%m%d)

# Restore a database
mongorestore \
  --uri "mongodb://admin:password@localhost:27017" \
  --db myapp \
  /var/backups/mongodb/20260520/myapp/

# Restore with drop (replace existing collection)
mongorestore --drop \
  --uri "mongodb://admin:password@localhost:27017" \
  --db myapp \
  /var/backups/mongodb/20260520/myapp/

Backup as a Scheduled Job

#!/usr/bin/env bash
# /usr/local/bin/mongodb_backup.sh
set -euo pipefail

readonly BACKUP_ROOT="/var/backups/mongodb"
readonly DATE="$(date +%Y%m%d_%H%M%S)"
readonly DEST="${BACKUP_ROOT}/${DATE}"
readonly S3_BUCKET="${MONGODB_BACKUP_BUCKET:?'Must be set'}"

mongodump --uri "$MONGODB_URI" --out "$DEST"
tar -czf "${DEST}.tar.gz" -C "$BACKUP_ROOT" "$DATE"
aws s3 cp "${DEST}.tar.gz" "s3://${S3_BUCKET}/mongodb/"
rm -rf "$DEST" "${DEST}.tar.gz"

# Retain 30 days of backups
find "$BACKUP_ROOT" -name "*.tar.gz" -mtime +30 -delete

# Cron: daily at 1 AM
0 1 * * * root /usr/local/bin/mongodb_backup.sh >> /var/log/mongodb_backup.log 2>&1

Production Checklist

Before going live, verify:

• Replica set of at least 3 members (or Atlas M10+)
• Authentication enabled with scoped users per service
• TLS enabled for all connections
• Firewall restricts port 27017 to application servers only
• Write concern set to w: majority for critical writes
• Indexes created for all production query patterns (explain() verified)
• Atlas alerts configured for replication lag, elections, disk, and CPU
• Backup schedule tested — restore verified at least once
• Connection string includes retryWrites=true and serverSelectionTimeoutMS
• Oplog sized to cover planned maintenance windows (24h minimum)