In this lesson, you will learn why relying on replication for data safety is a dangerous misconception and why traditional archival backups remain non-negotiable.
The Replication Fallacy
At this stage in your journey, you are intimately familiar with replication patterns. You know that replication—whether single-leader, multi-leader, or leaderless—is designed for High Availability (HA). Its primary goal is to ensure that if a node crashes, another can take its place to keep the system online.
However, replication is not a safety net against data corruption or human error. Because replication is near-instantaneous, it is "too good" at its job: if you accidentally run a DROP TABLE users; or an application bug executes an UPDATE that wipes out critical values, that disastrous state is propagated to all followers in milliseconds. Your replicated cluster is now collectively corrupted.
Why Backups are Different
A backup is a point-in-time capture of the database state, decoupled from the active replication stream. Unlike replication, which keeps your secondary nodes "current," a backup keeps your data "frozen" at a specific moment.
If a malicious actor or a faulty script modifies your data, you cannot use your replicas to recover, as they contain the exact same corrupted data. To recover, you must reach into your archival storage (e.g., an S3 bucket or off-site tape) to perform a Point-in-Time Recovery (PITR).
Consider this workflow:
- Replication: Protects against hardware failure (disk crashes, node death).
- Backups: Protect against logical failure (dropped tables,
DELETEstatements withoutWHEREclauses, or ransomware).
The Recovery Gap
Think of your infrastructure like this:
-- Replication handles this:
-- Node A (Leader) fails -> Failover to Node B (Replica) -> Service continues.
-- Backups handle this:
-- App bug runs: DELETE FROM orders;
-- Replication propagates the DELETE globally.
-- Data is gone everywhere.
-- Restore from last night's full backup + replay transaction logs to 1 second before the bug.
If you only use replication, you have high availability but zero protection against logical data destruction. Always maintain immutable, archival backups to provide the "undo" button that replication cannot offer.
Key Takeaway: Replication provides availability by keeping your data live, while backups provide durability by keeping your data recoverable from catastrophic logical failures.