Course Outline (Part 16)

In the last module, we locked down our database against hackers. But what happens if a legitimate, authorized developer accidentally runs a script that deletes the entire users collection?

Security cannot protect you from human error or catastrophic hardware failures. That is why having a robust backup and restore strategy is the most critical responsibility of any database administrator.

If you are using MongoDB Atlas, backups are largely automated for you. But if you are managing your own servers, or if you need to migrate data between environments (e.g., pulling production data to your local machine for testing), you need to know how to use the MongoDB Database Tools.

(Note: The Database Tools are command-line utilities that you run from your computer’s terminal, not from inside mongosh!)

BSON Backups (The Best Way)

The most efficient way to back up a MongoDB database is to export the data in its native binary format: BSON. BSON backups are incredibly fast and preserve all of your rich data types perfectly.

1. mongodump

The mongodump command connects to your database, reads all the data, and writes it to a folder on your computer as BSON files.

To backup the entire local database server:

mongodump

(This creates a folder called dump in your current directory containing the backup data).

To backup a specific database (e.g., ecommerce):

mongodump --db=ecommerce --out=/backups/ecommerce_backup

To backup a remote Atlas cluster: You just need to provide the connection string!

mongodump --uri="mongodb+srv://user:pass@cluster0.mongodb.net/ecommerce" --out=/backups/cloud_backup

2. mongorestore

If disaster strikes, or if you just want to load a backup onto a new server, you use mongorestore. It reads the BSON files created by mongodump and writes them back into the database.

To restore an entire dump folder:

mongorestore /backups/ecommerce_backup

To restore a specific collection (e.g., products) to a specific database:

mongorestore --db=ecommerce --collection=products /backups/ecommerce_backup/ecommerce/products.bson

(Warning: By default, mongorestore only inserts data. It does not overwrite existing data. If a document already exists with the same _id, it will throw a duplicate key error unless you use the --drop flag to wipe the collection before restoring).

Human-Readable Exports (JSON / CSV)

Sometimes, you don’t want a full database backup. Maybe the Marketing team asked you for a spreadsheet of all user emails, or the Data Science team needs a JSON file of recent orders. For this, you use the export and import tools.

1. mongoexport

mongoexport connects to a specific collection and exports the data as human-readable JSON or CSV files.

Export to a JSON file:

mongoexport --db=ecommerce --collection=users --out=users_export.json

Export to a CSV file (Requires specifying the fields):

mongoexport --db=ecommerce --collection=users --type=csv --fields=name,email,signupDate --out=users_list.csv

2. mongoimport

mongoimport does the exact opposite. It reads a JSON or CSV file and inserts the data into a collection.

Import a JSON file:

mongoimport --db=ecommerce --collection=users --file=users_export.json

Import a CSV file (and treat the first row as field names):

mongoimport --db=ecommerce --collection=users --type=csv --headerline --file=users_list.csv

Note: While mongoexport is great for sharing data with humans, you should never use it for actual database backups. It only exports standard JSON, meaning you will lose all the rich BSON types (like Decimal128 and proper Dates) during the translation!

Backup Strategies

Knowing the commands is only half the battle. You need a strategy. A good backup strategy follows the 3-2-1 Rule:

  • Keep 3 copies of your data (1 active production copy, 2 backups).
  • Store them on 2 different types of media (e.g., one on the database server, one in AWS S3 storage).
  • Keep 1 copy offsite (in a different physical data center or cloud provider).

1. File System Snapshots

If you are managing your own hardware, running mongodump on a massive 500GB database might take hours and consume all your server’s CPU. The industry standard is to use Storage Volume Snapshots (like AWS EBS Snapshots). You briefly pause database writes, take a block-level snapshot of the physical hard drive, and resume. This takes seconds, regardless of database size.

2. Continuous Backups (Oplog)

Taking a snapshot once a day at midnight is great, but what if the database crashes at 11:59 PM? You just lost 24 hours of user data. To achieve “Point-in-Time Recovery”, you must continually back up the Oplog (the log of every single write operation) and ship it to secure storage. If a crash happens, you restore the midnight snapshot, and then “replay” the oplog up until the exact second before the crash.

3. Test Your Backups!

Schrödinger’s Backup: The condition of any backup is unknown until you actually try to restore it.

Countless companies have diligently backed up their data for years, only to discover during a catastrophic failure that the backup files were corrupted. You must schedule routine, automated tests to restore your backups to a staging server to prove they actually work.

Summary

Protecting your data is paramount.

  • Use mongodump and mongorestore (BSON) for fast, accurate database backups and migrations.
  • Use mongoexport and mongoimport (JSON/CSV) when you need to share human-readable data with other teams.
  • Follow the 3-2-1 Rule for backup redundancy.
  • Use Cloud Snapshots and Oplog backups for massive production databases.
  • Always test your backups!

Now that our data is safe, let’s learn how to make it fast! In Module 16: Performance Optimization, we will look at how to tune our database for maximum speed.

Discussion

Loading comments...