Kafka backup: the complete guide for 2026

TL;DR: Kafka backup means storing an independent, point-in-time copy of your topic data, consumer offsets, and schemas outside the cluster, so you can recover from data loss that replication cannot fix: accidental deletes, corrupted writes, compliance requests, or a bad migration. Replication protects availability, not data integrity. A real backup strategy needs an isolated copy, a tested restore process, and RPO/RTO targets the business has actually agreed to.

What is Kafka backup?

A Kafka backup is a copy of your cluster's data that lives outside the cluster and outside its failure domain. Not a second broker. Not a mirrored topic on another live cluster. A stored, independent snapshot you can restore from after the original is gone, corrupted, or wrong.

A complete backup covers three things at minimum: the topic data itself (keys, values, headers, offsets), the consumer group offsets that tell each consumer where it left off, and the schemas referenced by the messages if you run Avro, Protobuf, or a similar format. Miss any one of the three and a restore looks like it worked while quietly breaking every consumer pointed at it.

This guide covers the what and why at a strategic level. For the mechanics of backing up and restoring a single topic, with working YAML examples, see how to backup and restore a Kafka topic.

Why isn't Kafka replication a backup?

This is the question that trips up more teams than anything else in this space, so it's worth being direct: replication factor 3, MirrorMaker 2, Cluster Linking, and Confluent Replicator all keep copies of your data moving between brokers or clusters. None of them give you a version of that data from before something went wrong. A bad write, an accidental delete, or a corrupted deploy replicates just as fast as a good one, which means every replica ends up holding the same mistake within milliseconds.

Anatoly Zelenin, who built one of the earliest open source Kafka backup tools and now advises teams through Kannika, compares it to RAID: it protects against a failed disk, not against a bad write. Kafka replication works the same way. It's an availability mechanism, not a recovery one. He unpacks this in more depth, including where teams usually get it wrong, in Kafka backup strategy: how to build one, by Anatoly Zelenin. For the full breakdown of why replication specifically fails as a backup, see replication is not a backup for Kafka.

What does a Kafka backup strategy require?

At a minimum, a Kafka backup strategy needs:

• Full scope: data, offsets, and schemas captured together, not piecemeal.
• Isolation from the source cluster's storage, account, and credentials.
• Point-in-time restore, not just a latest snapshot.
• A restore process that's actually been tested, by someone other than the person who built it.

That's the shape of it: full scope, isolated storage, and a restore path you have proven works before you need it under pressure.

How do you choose a Kafka backup tool?

Most tools in this space were built to solve a different problem than the one you actually have, and the split that matters most is continuous versus scheduled. A tool that only takes snapshots on an interval leaves everything produced since the last snapshot unprotected. With hourly snapshots, an incident can cost up to an hour of events, and an event stream can't be re-asked for what it already sent.

MirrorMaker 2 and Confluent Replicator mirror data to a second live cluster in real time. Both are replication tools built for multi-datacenter distribution, so neither gives you point-in-time recovery, and both mean running (and paying for) a second full cluster that inherits every mistake made on the first.

Confluent Cluster Linking with Schema Linking does the same job inside the Confluent ecosystem specifically: byte-for-byte replication between Confluent clusters, including schemas. It's easy to set up if you're already on Confluent, but it's still a mirror. Deletes and corruption propagate instantly, there's no point-in-time restore, and it only works between Confluent clusters.

Kafka Tiered Storage (KIP-405) offloads older log segments to object storage to cut broker disk cost. It's frequently mistaken for a backup because the data ends up in S3 or similar, but those segments are still owned by the live cluster. Delete the topic or hit a retention expiry, and the offloaded data goes with it.

OSO Kafka Backup is a purpose-built, MIT-licensed tool, but its free tier isn't a full backup. It runs scheduled, batch backups (every six hours in its own sample config) rather than continuous, real-time capture, so your exposure window is bounded by how often you schedule a run, not milliseconds. The free tier also skips Schema Registry entirely, so schemas aren't protected unless you move to the paid Enterprise tier.

Kafka Connect based solutions, usually an S3 sink connector plus custom scripts, copy data continuously but don't produce a restorable backup on their own. Schema registry backup, offset preservation, and point-in-time restore all need to be built and maintained separately, and every restore becomes a bespoke pipeline your team writes under pressure.

Kannika Armory is the only option here purpose-built as a Kafka backup and restore product, capturing data, offsets, and schemas continuously for a near-zero recovery point, with point-in-time, selective restore capability.

For how Kannika Armory stacks up against a Connect sink or a custom script at the mechanics level, see how to backup and restore a Kafka topic. The full, regularly updated version of this comparison lives on our product page. If you're specifically evaluating Confluent Cloud or Confluent Platform, see Confluent Kafka backup.

How do backups fit with DORA, NIS2, and MiFID II?

If your Kafka cluster carries data in scope for European financial or critical-infrastructure regulation, backup stops being an engineering preference and becomes a documented requirement. DORA Article 11 requires financial entities to test continuity and recovery plans at least yearly, and Article 12 requires that restoration from backups is tested periodically, not just assumed to work. NIS2 Article 21 places backup management and disaster recovery directly inside the required risk-management measures for essential and important entities. We cover both in full in NIS2, DORA and Apache Kafka.

MiFID II targets a different problem but touches Kafka in the same way. Firms must retain trading and communication records for a minimum of five years, extendable to seven on regulatory request, in a form that's complete, immutable, and retrievable even if the system that generated it no longer exists. Kafka's own retention is usually measured in days, tuned for throughput rather than years of auditable history. If a topic carries order or transaction events in scope for MiFID II, the backup strategy is what actually satisfies the retention obligation, not the cluster's default settings.

Across all three, regulators want proof of recoverability, not a claim of it: a tested restore, a documented process, and a copy that exists independently of the cluster it protects. See how this plays out for financial services teams specifically on our finance solutions page.

How does Kannika Armory approach Kafka backup?

Kannika Armory runs as a Kubernetes operator inside your own cluster, with backups and restores defined as Custom Resources so they fit into GitOps pipelines instead of a cron job only one person understands.

It continuously captures topic data, consumer group offsets, and Schema Registry schemas for a near-zero recovery point, writes them to storage you control (S3-compatible, Azure Blob, GCS, or your own PersistentVolumes) compressed to roughly 10% of their original size, and restores point-in-time and selectively, remapping schema IDs and translating consumer offsets so applications resume where they left off. It supports 10+ Kafka-compatible platforms, including Apache Kafka, Confluent, MSK, Azure Event Hubs, and Redpanda.

For the full mechanics, including the Kubernetes resources involved, see how to backup and restore a Kafka topic. Full product detail is on the backup and restore solutions page.

Book a 30-minute demo and we'll walk through your setup, your RPO and RTO targets, and where the gaps are.

What are the most common Kafka backup mistakes?

• Treating replication as backup: the one that causes the most damage, covered above.
• A single RPO for the whole cluster: not every topic needs millisecond recovery, but treating them all the same either overspends on low-value data or under-protects the topics that actually matter.
• Backups sharing a blast radius with the source: a backup that lives in the same account, cluster, or credentials as the data it protects fails for the same reason the original did.
• Losing offsets during migration: consumers either reprocess the entire topic from the start or connect at the high watermark and silently miss everything that happened before the restore.
• Restoring with a different partition count: key-based ordering guarantees depend on consistent partition counts, and changing it during a restore breaks them.
• Never testing a restore: a backup job running successfully for months tells you nothing about whether the restore path works. The only way to know is to run a restore, on a real topic, before you need to.

Kafka backup done right

Backup and recovery for Kafka isn't complicated once you separate it from replication and treat it as its own discipline: full scope, isolated storage, tested restores.

Start a free trial and back up your first topic today, or book a demo and we'll map this to your own cluster and compliance requirements.