DEV Community

Cover image for Automated MongoDB Backups — Production‑Ready Guide
Jagannath Shingne
Jagannath Shingne

Posted on

Automated MongoDB Backups — Production‑Ready Guide

#mongodb #node #tutorial #automation

Why Backups Matter (More Than You Think)

Production databases will fail — human error, cloud outages, bad deployments, or accidental deletes. The only real safety net is a reliable, automated backup system that you trust enough to restore from at 3 AM.

In this guide, we’ll walk through a battle‑tested MongoDB backup system built using:

  • mongodump / mongorestore
  • Node.js + node-cron
  • Amazon S3
  • MongoDB (as backup metadata store)

By the end, you’ll understand how to safely back up MongoDB, store it in S3, clean old backups, and fully restore your database if disaster strikes.

System Goals

We wanted a system that:

  • Backs up multiple MongoDB databases
  • Runs daily, weekly, and monthly automatically
  • Stores backups safely in S3
  • Tracks everything in MongoDB
  • Deletes expired backups automatically
  • Can fully restore a deleted database

No manual steps. No risky shortcuts.

Core Concept: MongoDB Dumps

MongoDB provides a native backup tool called mongodump.

We use it like this:

mongodump --uri="<MONGO_URI>" --archive --gzip --oplog
Enter fullscreen mode Exit fullscreen mode

What this does

  • --archive → outputs a single file (easy to store)
  • --gzip → compresses the backup
  • --oplog → ensures consistent snapshots for replica sets

Result: one .archive.gz file per backup.

This backup is read‑only — your original database is never modified.

Supporting Multiple Databases

Instead of hard‑coding one database, we define a generic list of MongoDB connections:

const databases = [
  { name: "app-db", uri: process.env.MONGO_URI_1 },
  { name: "analytics-db", uri: process.env.MONGO_URI_2 }
];
Enter fullscreen mode Exit fullscreen mode

These names are examples only and can represent any MongoDB database in any environment.

Each database:

  • Uses the same backup logic
  • Generates its own backup file
  • Stores metadata separately

This approach keeps the system *generic and reusable*.

Automated Cron Jobs

All backups run inside the Node.js app using node-cron.

Job Type Schedule
Daily Every day
Weekly Every Sunday
Monthly 1st day of month
Cleanup Every day

Each cron:

  1. Runs mongodump
  2. Uploads the file to S3
  3. Saves metadata in MongoDB

No external cron servers required.

S3 Storage Structure

Backups are uploaded as .archive.gz files to an S3 bucket.

A generic and recommended folder structure looks like this:

s3://mongo-backups/
  {dbName}/
    daily/
    weekly/
    monthly/
Enter fullscreen mode Exit fullscreen mode

Where:

  • {dbName} → sanitized MongoDB database name
  • daily | weekly | monthly → backup frequency

Production Safety Rules

  • Database names are sanitized (lowercase, no spaces)
  • Files are uploaded only after dump succeeds
  • Local files are deleted only after S3 upload succeeds

This structure works for any project or organization and scales cleanly.

Backup Metadata in MongoDB

MongoDB stores generic backup metadata, independent of any company or product:

{
  dbName: "app-db",
  backupType: "daily",
  storageProvider: "s3",
  storageKey: "mongo-backups/app-db/daily/backup.archive.gz",
  createdAt: ISODate(),
  expireAt: ISODate()
}
Enter fullscreen mode Exit fullscreen mode

Why this matters:

  • MongoDB becomes the source of truth
  • Every backup is auditable
  • Cleanup logic is safe and deterministic

Nothing is deleted unless it is explicitly tracked.

Automatic Cleanup of Expired Backups

A separate daily cron job:

  1. Finds backups where expireAt < now
  2. Deletes the file from S3
  3. Deletes the record from MongoDB

If it’s not in MongoDB → it’s not deleted.

This prevents:

  • Accidental data loss
  • Unlimited storage growth

Disaster Recovery (Restore Process)

If any MongoDB database is deleted or corrupted:

Step 1: Download the latest backup 

aws s3 cp s3://mongo-backups/{dbName}/daily/latest.archive.gz .
Enter fullscreen mode Exit fullscreen mode

Step 2: Restore using mongorestore 

mongorestore --gzip --archive=latest.archive.gz --drop
Enter fullscreen mode Exit fullscreen mode
  • --drop clears existing data
  • The database is rebuilt from the archive

This process works for any MongoDB deployment.

Safety Guarantees

✔ Original DB is never modified
✔ Backups are full & consistent
✔ Storage growth is controlled
✔ Every backup is tracked
✔ Restore is always possible

This is production‑grade, not a demo script.

Final Thought

This guide demonstrated a generic, production‑safe MongoDB backup strategy using mongodump, scheduled jobs, S3 storage, MongoDB‑tracked metadata, automated cleanup, and a reliable restore flow — adaptable to any project or organization.

Happy building 🚀

Top comments (0)