Why replication is not backup
Four incidents a standby will not save you from.
Cluster Linking and MirrorMaker 2 do their job well: they keep a second cluster in step with production, so you stay online when a site or region fails. That same job is why they cannot protect you from the incidents below. They copy what production does, good or bad.
01 · Deleted topic
One wrong command
An engineer deletes a production topic thinking it is staging, or an infrastructure change removes topics nobody meant to touch. Replication mirrors the delete to the standby.
Result: two clusters, no data.
02 · Bad producer write
A bug corrupts events
A release ships with a bug and writes broken events into a payments or orders topic. The standby receives the same broken events. You need the data from before the bug, and the standby only shows the current state.
Result: no clean point to go back to.
03 · Compromised credentials
A stolen key
A leaked producer or admin key lets an attacker write junk, reset consumer offsets or shorten retention. If the same credentials or automation can reach the standby, it is exposed too.
Result: the attacker reaches your recovery copy.
04 · Ransomware
Damage that spreads by design
Ransomware that reaches the stream writes or destroys data in production. Replication carries the damage to every connected cluster, because that is what it is built to do.
Result: recovery depends on a copy the attacker cannot touch.