Learning MongoDB - Backup, Restore & Change Streams

#Introduction

There's no better rating for backup success than a data-loss test. Production applications always face bad scenarios: human error deleting a collection, a bug overwriting thousands of documents, or a server burning out. In that situation, you don't need excuses — you need a backup that can be restored. Episode 18 prepares you for that moment.

The roadmap: first the backup/restore strategy — mongodump/mongorestore for logical backups, second filesystem snapshots for physical backups, third point-in-time restore in Atlas, and fourth change streams for listening to data changes in real time — a skill that opens the door to event-driven architecture. Let's get started.

#Backup and Restore Strategy

#mongodump / mongorestore: Logical Backup

mongodump produces a logical backup — data exported as BSON files containing documents and metadata. It's the most flexible because you can choose the level: a whole database, specific collections, even with a query filter:

mongodump --uri "mongodb://localhost:27017" --db app --out /backup/app-2026-08-03

mongodump --uri "mongodb://localhost:27017" \
  --db app --collection orders \
  --query '{ "status": "paid" }' \
  --out /backup/orders-paid

The result is a folder containing .bson and .metadata.json files per collection. Restoration uses mongorestore — you can restore everything, or a single collection:

mongorestore --uri "mongodb://localhost:27017" --drop /backup/app-2026-08-03

mongorestore --uri "mongodb://localhost:27017" \
  --db app --collection orders \
  /backup/app-2026-08-03/app/orders.bson

The --drop option deletes the collection before restoring — be careful, use it only when you really want to replace existing data.

It's important to understand: mongodump takes a consistent snapshot when run against a replica set (with --oplog for point-in-time consistency), but this is not a continuous backup — there's a window of data arriving after the dump completes that isn't captured.

#Filesystem Snapshots: Physical Backup

A filesystem snapshot is a physical copy of the entire data directory at the OS/disk level — using LVM, ZFS, or cloud disk snapshots. Its advantages:

• Super fast — snapshots on many systems are nearly instantaneous and don't lock the data.
• Fully consistent — copies the datafiles exactly as they are; the recovery point is clear.
• Ideal for large datasets — no need to read all the data like mongodump does.

lvcreate -L 20G -s -n mongo-snap /dev/vg/mongodata
mount /dev/vg/mongo-snap /mnt/backup

For perfect consistency, take snapshots on a replica set and grab them from a secondary — so the primary isn't disturbed and the data is guaranteed in sync from the same point in time.

#MongoDB Atlas Continuous Backup

If you use MongoDB Atlas (SaaS), backups are managed automatically: continuous backup captures data changes almost in real time, enabling Point-in-Time Restore — restoring a cluster to its state at a specific minute (even second). This is invaluable when you need to rewind to just before a mistake happened, without losing the data that arrived afterward.

Atlas also performs routine snapshots (e.g. every 6 hours) with varying retention, and the entire process is managed via the UI or API without manual scripts. The trade-off: you pay for the service, and the data isn't available as freely portable files.

#Change Streams: Listening to Changes in Real Time

#Concept

Change streams let applications listen to data changes on a collection, database, or the entire deployment in real time — inserts, updates, replaces, and deletes. This is the bridge from a "passive" database to an "active" one that tells the application when data changes.

Change streams work through a tailable cursor over the oplog: the application opens a stream, and each new data change is sent as an event document. This feature is only available in replica sets.

#Use Case Studies

Change streams open the door to event-driven architecture. The most common real cases:

• Real-time notifications — when an order's status changes, the application sends a push notification to the user without polling.
• Cache invalidation — when a product document is updated, the Redis cache is invalidated or refreshed.
• Data sync to a search engine — every data change is pushed to Elasticsearch/OpenSearch so the search index always stays in sync.
• Audit log — recording all data changes for compliance.

Listening to changes on the orders collection (Node.js)

const pipeline = [
  {
    $match: {
      operationType: { $in: ["insert", "update"] },
      "fullDocument.status": "paid"
    }
  }
];
 
const changeStream = ordersCollection.watch(pipeline);
 
changeStream.on("change", (event) => {
  sendNotification(event.fullDocument);
});

The example above only reacts to inserts/updates where the status becomes paid — then sends a notification. Compare that to a polling pattern checking the database every second: change streams save resources and provide near-zero latency.

#Update Lookup

Note that on update operations, the full document isn't always available in the event. To retrieve the latest document, enable the fullDocument option:

Getting the full document on updates

const changeStream = ordersCollection.watch([], {
  fullDocument: "updateLookup"
});

With "updateLookup", MongoDB includes the current document version in fullDocument every time there's an update — making synchronization easy without an additional query.

#Conclusion

In episode 18 you put together a data rescue strategy: mongodump/mongorestore for flexible logical backups at the database, collection, or filter level; filesystem snapshots via LVM/ZFS for fast and consistent physical backups; point-in-time restore in Atlas for precise rewinding; and change streams to listen to data changes in real time — opening event-driven architecture like notifications, cache invalidation, and sync to search engines.

Key takeaways:

• mongodump for flexible logical backups; snapshots for large physical backups.
• Always test restores — a backup that can't be restored is the same as having none.
• Atlas continuous backup provides automatic point-in-time restore.
• Change streams turn MongoDB into a source of real-time events.
• Synchronization and notifications can be built without repeated polling.

In the next episode, episode 19, we keep the system healthy: Monitoring, Maintenance & Troubleshooting. You'll check health with db.serverStatus, db.currentOp, mongostat, and mongotop, monitor via Prometheus and Grafana, perform maintenance like compact and reIndex, and handle common issues like slow queries, memory pressure, and replication lag. See you in episode 19!