Disaster Recovery: Backups & Replica Sets
Welcome to Day 4! 🚑
Servers die. Disks fail. Interns drop tables. You need a plan.
1. High Availability (Replica Sets)
A single MongoDB node is a Single Point of Failure.
A Replica Set is a group of mongod instances that maintain the same data.
- Primary: Receives all Writes. Replicates to Secondaries.
- Secondary: Replicates data. Can serve Reads (if configured).
- Arbiter: No data. Just votes in elections.
Failover: If the Primary dies, the Secondaries hold an election. One becomes the new Primary automatically. Your app just reconnects.
2. Backup Strategies
Replication is NOT a backup. If you delete a collection on the Primary, it deletes on the Secondary instantly.
You need Point-in-Time backups.
A. mongodump & mongorestore
Standard logical backups.
# Backup
mongodump --uri="mongodb://..." --out=/backups/date
# Restore
mongorestore --uri="mongodb://..." /backups/date
Pros: Simple. Cons: Slow on large datasets.
B. Filesystem Snapshots (LVM / EBS)
If you run on AWS/GCP, snapshot the disk volume. Pros: Instant. Cons: Requires OS-level access.
C. Atlas Backups
Continuous Cloud Backups. You can restore to any specific minute in the last 7 days.
3. Testing Restores
A backup is useless if you can’t restore it. The “Schrödinger’s Backup” Rule:
A backup is neither good nor bad until you attempt to restore it.
Perform a Dry Run restore every month to a staging environment.
🧠 Daily Challenge
- Create a dummy folder
backup_test. - Use
mongodumpto backup your local database. - Drop a collection! 😱
- Use
mongorestoreto bring it back.
See you on Day 5 for our Mini Project: A Secure Notes App with Encryption! 🔐