DEV Community

Cover image for MongoDB Backup and Restore Strategy on AWS
Shashi Kant
Shashi Kant

Posted on

MongoDB Backup and Restore Strategy on AWS

#mongodb #aws #devops #database

Whether you're running a side project or managing enterprise-scale applications, having a reliable backup strategy for MongoDB is essential. I've seen teams invest months building systems but spend only a few minutes thinking about disaster recovery.

In this article, I'll walk through a production-ready MongoDB backup and restore strategy using AWS that is reliable, secure, and cost-effective.

Why Backups Matter

Imagine these scenarios:

  • Someone accidentally runs deleteMany({}) on production.
  • A deployment corrupts important collections.
  • Your EC2 instance crashes permanently.
  • Ransomware encrypts your server.
  • An application bug overwrites critical data.

Without backups, recovery may be impossible.

A good backup strategy should satisfy three goals:

  • Automatic
  • Secure
  • Quick to Restore

Architecture 

MongoDB
     │
     │ mongodump
     ▼
Compressed Archive (.gz)
     │
     ▼
AWS S3 Bucket
     │
Lifecycle Policy
     ▼
Glacier Archive
Enter fullscreen mode Exit fullscreen mode

The workflow is simple:

  1. Create a backup using mongodump
  2. Compress the archive
  3. Upload it to Amazon S3
  4. Automatically move older backups to Glacier
  5. Restore whenever necessary

Prerequisites

  • MongoDB installed
  • AWS Account
  • IAM User with S3 permissions
  • AWS CLI configured
  • Linux server (Ubuntu/Amazon Linux)

Install MongoDB Database Tools

sudo apt install mongodb-database-tools
Enter fullscreen mode Exit fullscreen mode

Configure AWS CLI

aws configure
Enter fullscreen mode Exit fullscreen mode

Step 1 — Create a Backup 

mongodump \
  --uri="mongodb://username:password@host:27017/database" \
  --gzip \
  --archive=/backup/mongodb_$(date +%F_%H-%M).gz
Enter fullscreen mode Exit fullscreen mode

This command creates a compressed archive of the database.

Example output:

mongodb_2026-07-17_02-00.gz
Enter fullscreen mode Exit fullscreen mode

Step 2 — Upload to Amazon S3 

aws s3 cp \
/backup/mongodb_2026-07-17_02-00.gz \
s3://company-backups/mongodb/
Enter fullscreen mode Exit fullscreen mode

Your backups are now safely stored outside your production server.

This protects you even if the EC2 instance is completely lost.

Step 3 — Automate with Cron

Create a shell script.

#!/bin/bash

DATE=$(date +%F_%H-%M)

mongodump \
--uri="$MONGO_URI" \
--gzip \
--archive=/backup/mongodb_$DATE.gz

aws s3 cp \
/backup/mongodb_$DATE.gz \
s3://company-backups/mongodb/

find /backup -type f -mtime +7 -delete
Enter fullscreen mode Exit fullscreen mode

Make it executable.

chmod +x backup.sh
Enter fullscreen mode Exit fullscreen mode

Schedule it.

crontab -e
Enter fullscreen mode Exit fullscreen mode

Daily at 2 AM

0 2 * * * /home/ubuntu/backup.sh
Enter fullscreen mode Exit fullscreen mode

Now backups happen automatically every night.

Step 4 — Configure S3 Lifecycle Rules

Instead of paying premium storage forever, configure lifecycle policies.

Recommended policy:

Backup Age Storage Class
0–30 Days Standard
31–90 Days Standard-IA
90+ Days Glacier
365+ Days Delete

This significantly reduces storage costs.

Step 5 — Encrypt Everything

Never store backups in plain text.

Use:

  • Server-side encryption (SSE-S3)
  • SSE-KMS for enterprise environments

Enable encryption directly on the bucket.

Also:

  • Block public access
  • Enable bucket versioning
  • Enable MFA Delete (where applicable)

Step 6 — Test Your Restores

Many teams create backups.

Very few verify them.

A backup that cannot be restored is useless.

Restore using:

mongorestore \
--gzip \
--archive=mongodb_2026-07-17_02-00.gz
Enter fullscreen mode Exit fullscreen mode

Or restore a specific database.

mongorestore \
--db=mydatabase \
--gzip \
--archive=backup.gz
Enter fullscreen mode Exit fullscreen mode

Schedule periodic restore tests in a staging environment.

Point-in-Time Recovery

If your application processes financial transactions or critical business data, daily backups may not be enough.

Enable MongoDB replication.

Then archive the oplog.

This allows recovery to almost any point in time.

Monitoring Backup Jobs

A backup process should notify you when it fails.

Recommended options:

  • CloudWatch Logs
  • CloudWatch Alarms
  • SNS Notifications
  • Slack Webhooks
  • Email alerts

Never assume backups are working.

Monitor them.

Security Best Practices

  • Store MongoDB credentials in AWS Secrets Manager.
  • Use IAM roles instead of long-lived AWS access keys.
  • Restrict S3 bucket access to the backup server.
  • Enable S3 Versioning.
  • Enable Bucket Encryption.
  • Rotate credentials regularly.
  • Keep backup servers updated.

Common Mistakes

❌ Keeping backups on the same server

❌ Never testing restore

❌ No encryption

❌ No lifecycle policy

❌ No monitoring

❌ Manual backups only

Sample Recovery Workflow

Imagine production fails.

  1. Launch a new EC2 instance.
  2. Install MongoDB.
  3. Download the latest backup from S3.
  4. Run mongorestore.
  5. Point your application to the restored database.
  6. Resume normal operations.

A well-prepared recovery can take minutes instead of hours.

Final Thoughts

Backups are one of those things nobody appreciates until they're desperately needed.

A reliable MongoDB backup strategy isn't just about creating dump files—it's about ensuring you can recover quickly, securely, and with confidence. By combining mongodump, Amazon S3, lifecycle policies, encryption, and automated scheduling, you can build a robust disaster recovery process without excessive complexity.

Remember: The value of a backup is measured by how quickly and successfully you can restore it.

What backup strategy do you use?

  • Native MongoDB tools?
  • MongoDB Atlas backups?
  • AWS Backup?
  • Snapshot-based backups?
  • Something else?

Share your experience in the comments—I'd love to learn how others handle production backups.

If you found this helpful, consider following me for more articles on Backend Engineering, DevOps, Data Engineering, and Flutter.

Top comments (0)