Confluent Kafka backup: what Confluent doesn't cover

TL;DR: Confluent doesn't ship a backup product. Replicator and Cluster Linking replicate data between live clusters for availability, migration, and failover, not point-in-time recovery. A real Confluent backup needs topic data, consumer offsets, Connect state, and Schema Registry captured independently, on Cloud or Platform.

What options does Confluent provide for Kafka backup?

Confluent doesn't sell a built-in backup solution. What it offers instead are pieces that get combined into a disaster recovery architecture. Cluster Linking mirrors topics between Confluent clusters and is Confluent's current recommendation for most multi-cluster scenarios. Confluent Replicator does the same job through Kafka Connect and is still fully supported, particularly for use cases Cluster Linking doesn't cover. Schema Linking replicates Schema Registry content between registries. Tiered Storage offloads older log segments to object storage to cut broker disk cost. And Confluent ships a set of Kafka Connect connectors explicitly named "Backup and Restore," source connectors for S3, GCS, and Azure Blob Storage that read data back into Kafka after a matching sink connector wrote it out.

None of these, on its own or combined, produces an independent, point-in-time copy of your data. Section 9.4 of the Confluent Cloud Security Addendum states: "Customer is responsible for managing a backup strategy regarding Message Content." The same document notes that Message Content is retained only per the customer's configured retention period, and that Confluent's own business continuity and disaster recovery plan covers the availability of the Cloud Service, not a customer's data recovery strategy.

For the general case against treating any replication mechanism as a backup, see our Kafka backup guide.

Why isn't Confluent Replicator a real backup?

Confluent's own documentation files Replicator and Cluster Linking under multi-datacenter architecture, not backup. Confluent frames use cases as active-active geo-localized deployments, active-passive disaster recovery through failover, cloud migration, and centralized analytics. Cluster Linking's own description says it "creates perfect copies of Kafka topics, which keep data in sync across clusters." That's the problem. A perfect copy includes the accidental delete and the corrupted write, copied to the target just as fast as everything else, and neither tool has a mechanism to hand you the state from before that happened.

Replicator has supported consumer offset translation since Confluent Platform 5.1.0, so a failover cluster can pick up where the source left off. That solves continuity, keeping applications running after infrastructure failure. It doesn't solve recovery, undoing a mistake that already happened.

How do you back up a Confluent Cloud cluster?

Confluent Cloud is fully managed, so there's no broker filesystem, no ZooKeeper or KRaft quorum, and no storage layer to reach into directly. Every path out of Confluent Cloud runs through the Kafka protocol itself: a fully-managed Connect connector (including the Backup and Restore S3, GCS, or Azure Blob Storage connectors), a client application consuming and writing elsewhere, or a purpose-built backup tool authenticating with API keys the same way any Kafka client would.

Retention on Confluent Cloud is bounded by whatever you've configured per topic. Anything you need beyond that window has to already be captured somewhere else by the time it expires. Schema Registry on Confluent Cloud is fully managed too, and runs on separate infrastructure from your cluster, which changes how it gets backed up (more on that below).

Kannika Armory connects to Confluent Cloud the same way: bootstrap servers and API key credentials, no proprietary integration required. In production, that connection method backed up a 50-topic, 2TB Confluent Cloud cluster in 8 hours, a duration capped by Confluent Cloud's own 10-worker limit rather than by the backup engine.

How do you back up Confluent Platform on-premises?

Self-managed Confluent Platform gives you more surface area to think about. Brokers, the KRaft controller quorum that replaced ZooKeeper as of Confluent Platform 8.0, Schema Registry, Connect workers, and any ksqlDB or Flink jobs all carry state worth protecting. KRaft stores cluster metadata inside Kafka itself now, which means that metadata is subject to the same replication-isn't-backup logic as topic data.

The building blocks are the same ones available on Confluent Cloud, plus a few that only make sense on-prem. Cluster Linking or Replicator for cross-datacenter DR, carrying the same caveats above. Tiered Storage (KIP-405) to move older segments to cheaper storage without actually removing them from the live cluster's ownership. And a dedicated backup tool, which on Confluent Platform can write to your own object storage or, since you control the infrastructure, to local PersistentVolumes for air-gapped setups.

What about the Schema Registry and Connect state?

Two things get missed constantly, and both break restores.

Schemas are the contract between producers and consumers. If a restored topic's messages reference schema IDs that don't exist in the target registry, deserialization fails, even if the message data itself came back intact. Confluent's own tools handle schema replication between live registries, Schema Linking for real-time sync, Replicator's schema translators for migration, but neither one is an independent backup of registry content on its own.

How you back up the registry itself depends on which Confluent deployment you're on, and the two paths aren't the same. On a self-managed Schema Registry, schemas live on a regular Kafka topic (usually _schemas), so they're captured the same way any other topic is, no special handling required. On Confluent Cloud, the registry runs on separate infrastructure and that topic isn't reachable at all. Kannika Armory handles this case with two dedicated resources, SchemaRegistryBackup and SchemaRegistryRestore, which talk to the Schema Registry REST API directly instead of reading a Kafka topic. Worth knowing: this path polls the API on an interval rather than streaming continuously, defaulting to once an hour unless you configure it tighter. Restored schemas also don't keep their original ID or version by default, they get patched with new ones, though Confluent Cloud's registry supports an "import mode" that Armory can use to preserve the originals when that matters for compatibility.

Connect state is the other blind spot, and it's easy to miss because it's split in two. Source connectors, the ones pulling data into Kafka from an external system, track their own position in an internal Kafka Connect topic (commonly named connect-offsets), separate from Kafka's consumer group mechanism. Sink connectors, which push data out of Kafka, use ordinary consumer groups just like any other consumer. Lose the internal offsets topic and a source connector doesn't know where it left off in the source system. Lose consumer group state and a sink connector reprocesses or skips messages on restart. A backup strategy that only covers topic data misses both.

How do you meet DORA and NIS2 requirements with Confluent?

The Security Addendum language covered above matters most here. DORA and NIS2 both require financial and critical-infrastructure entities to prove they can restore from backups, tested, documented, on a schedule. Confluent's own Section 7 confirms their business continuity and disaster recovery plan is tested annually and covers the Cloud Service's availability. Section 9.4 confirms backup of your Message Content is your responsibility, not theirs.

Running on Confluent Cloud or Confluent Platform doesn't change what DORA Article 11 and 12 or NIS2 Article 21 require. It just means the independent, tested, point-in-time backup those regulations expect has to come from somewhere other than Confluent's own infrastructure. For the full regulatory breakdown, including MiFID II, see NIS2, DORA and Apache Kafka and our Kafka backup guide.

How Kannika Armory complements Confluent

Kannika Armory doesn't replace Cluster Linking, Replicator, or Tiered Storage. It runs alongside them. Where those tools keep two live clusters in sync or keep old segments cheap to store, none of them produce an independent, point-in-time copy that exists outside the cluster's own failure domain, which is the gap Kannika Armory fills. It connects to Confluent Cloud or Confluent Platform the same way any Kafka client does, continuously captures topic data and consumer group offsets, and writes them to storage you control rather than storage Confluent manages. Schema Registry is captured too, continuously if it's self-managed and reachable as a Kafka topic, or on a polling interval against the Schema Registry API if it's Confluent Cloud. Confluent Cloud and Confluent Platform are two of the 10+ Kafka-compatible platforms it supports. Full detail is on the backup and restore solutions page.

If you're weighing Confluent's tools against the wider field, including MirrorMaker 2 and OSO Kafka Backup, the full comparison is in our Kafka backup guide. For why a Connect sink specifically falls short as a backup strategy, see why Kafka Connect backups become a trap.

Book a 30-minute demo and we'll walk through how Armory fits alongside your existing Cluster Linking or Replicator setup.

Confluent's tools do what they're built for

Confluent's replication and failover tools do what they're built for. None of them are a backup, and Confluent's own terms say so.

Start a free trial and back up your first Confluent topic today, or book a demo and we'll map this to your Cloud or Platform setup.