Kafka backup vs replication

Your Kafka is replicated. Is it backed up?

Replication keeps you online. Backup gets your data back.

A standby cluster copies everything production does, including the mistakes. A deleted topic, a bad write or a stolen key reaches the standby within seconds. If your recovery plan is "fail over to DR", ask what happens when DR holds the same damage. This page explains the difference in plain terms, what a real Kafka backup needs, and how auditors under DORA and NIS2 will look at it.

  • Keep your Cluster Linking or MirrorMaker 2 setup as it is
  • Locked backup copy that production credentials cannot reach
  • Works with Confluent, Apache Kafka, Redpanda and MSK
Kafka backup vs replication

Your Kafka is replicated. Is it backed up?

Replication keeps you online. Backup gets your data back.

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.

What a real backup needs

Four tests for your Kafka backup.

If your current setup fails any of these, you have availability, not backup. Use them as a checklist for your next risk review.

  • 1. An immutable copy

    Once written, the backup cannot be changed or deleted before its retention ends, not even by an admin. Object storage with object lock is the standard way to get this.

  • 2. Separate credentials

    The keys that run production cannot reach the backup. A stolen production key, a script or a careless command should stop at the boundary.

  • 3. Point-in-time history

    You can go back to the data as it was before the incident, not just the latest state. That is what lets you recover from a bad write that ran for an hour.

  • 4. Tested recovery

    You have restored from it, on a schedule, without touching production. A backup nobody has recovered from is a hope, not a plan, and it is the first thing an auditor will ask about.

DORA and NIS2 in plain terms

Regulators ask whether you can recover, not whether you replicate.

DORA applies to EU financial firms. NIS2 applies to operators of essential and important services such as energy, transport and digital infrastructure. Both expect you to plan for serious incidents, back up critical data and prove you can restore it. For event streams that carry payments, orders or grid data, that puts Kafka in scope. This is general guidance, not legal advice.

Board question

Can we recover from a cyber attack?

A standby that mirrors the attack is not an answer. A locked copy outside the reach of production credentials is.

Auditor question

When did you last test a restore?

Recovery drills against a parallel copy give you evidence, without putting production at risk.

Risk question

How much data could we lose, and for how long are we down?

Point-in-time history lets you return to the moment before the incident, and a ready recovery stack shortens the time to get there.

Cost question

Do we need a second full cluster just for safety?

No. Backup history can live on low-cost object storage instead of a second production-sized cluster.

How Lascaris handles it

Keep your replication. Add a backup it cannot break.

Lascaris includes backup and recovery as part of the platform. It sits next to the Kafka you already run, so production stays untouched and your Cluster Linking or MirrorMaker 2 setup keeps doing its job.

Question Replication (Cluster Linking, MirrorMaker 2) Backup with Lascaris
Built for Staying online when a cluster, site or region fails. Getting data back after deletes, bad writes and attacks.
Deleted topic The delete is copied to the standby. The locked copy is kept.
Stolen production key Can reach the standby if access is shared. Production credentials cannot reach the copy.
History Current state only. Time-indexed history, kept for years on object storage.
Recovery Fail over to the standby. Recover into a parallel environment and run drills there, without touching production.
  • Works with any Kafka-protocol source: Confluent, Apache Kafka, Redpanda and MSK.
  • Backup data is stored on S3 under object lock, as an immutable copy.
  • Standard Kafka consumers read the backup, so replay and reprocessing work with tools you already have.
  • Runs inside your own cloud account, on-premise or air-gapped. We can run it for you, or your team runs it with our support.
  • Restoring a single topic as of a chosen time into a new topic is planned, not yet available.
FAQ

Common questions.

Is Kafka replication the same as backup?

No. Replication keeps a second cluster in step with production so you stay online during an outage. It also copies deletes, bad writes and changes made with stolen credentials. A backup is a separate, locked copy with its own history that production cannot change.

Are Cluster Linking and MirrorMaker 2 good tools?

Yes. They are the right tools for availability, disaster failover and moving data between sites. Scalytics is a Confluent partner and supports teams that use them. They are not designed to be a backup, so most teams need both.

What does a real Kafka backup need?

Four things: an immutable copy that cannot be changed or deleted early, credentials that are separate from production, history you can go back to from before an incident, and recovery that you test on a schedule without touching production.

Does Kafka backup matter for DORA and NIS2?

Yes, if your event streams carry critical business or operational data. Both frameworks expect you to back up critical data, protect it from attacks and prove you can restore it. A tested, locked backup gives you that evidence.

Do we have to replace our Kafka cluster to add backup?

No. Lascaris works with any Kafka-protocol source, including Confluent, Apache Kafka, Redpanda and MSK. Your production cluster and your replication stay as they are.

Can we restore a single topic to a point in time?

Today the backup keeps a time-indexed, immutable copy that standard Kafka consumers can read for replay and recovery drills. Restoring a single topic as of a chosen time into a new topic is planned, not yet available.

Next step

Find out if your Kafka would survive a bad day.

Book a call and we will walk through your current replication, where the gaps are and what a recovery drill would look like for your setup. Or start with the AI Architecture Score to see where your stack stands today.