Broker-native replication vs point-in-time backup
Cluster Linking is a clean piece of engineering: it mirrors topics between clusters at the broker level, with no Connect cluster to run and offsets preserved exactly. But a mirror is still a mirror — it copies bad data as faithfully as good. Here is how the two approaches differ.
Two different jobs
Confluent Cluster Linking creates a direct link between a source and destination cluster and mirrors topics byte-for-byte, preserving offsets and syncing topic configuration. It runs inside the brokers — no separate Kafka Connect cluster — and is part of Confluent Platform and Confluent Cloud. It is a strong fit for cluster migration, hybrid-cloud data sharing, and low-RPO standby clusters.
OSO Kafka Backup takes point-in-time backups of topic data, consumer group offsets, and cluster metadata to object storage (S3, Azure Blob, GCS) or local disk, then restores any of it — to the same cluster or a different one — with millisecond precision. See the disaster recovery use cases for the failure scenarios each approach covers.
The critical difference is the same one that separates backup from every replication tool: when a producer bug poisons a topic, a cluster link mirrors the poison to the destination almost immediately. A backup holds the state of the topic from before the incident, so you can roll back to it.
| Feature | OSO Kafka Backup | Confluent Cluster Linking |
|---|---|---|
| Purpose | Backup / restore | Real-time replication |
| Point-in-time recovery | Yes | No |
| Protects against bad data / deletes | Yes | No |
| Licensing | Open source (MIT) | Commercial (Confluent) |
| Storage backends | S3, Azure, GCS, local | Kafka only |
| Offset preservation | Built-in | Byte-for-byte |
| Runs on any Kafka distribution | Yes | No |
| Network requirement | One-time transfer | Continuous connection |
| Compression | Zstd, LZ4 | Kafka default |
| Infrastructure cost | Object storage | A second live cluster |
| Recovery time (RTO) | Minutes–hours | Instant (already mirrored) |
| Data loss window (RPO) | Since last backup | Near-zero |
When to choose which
Choose OSO Kafka Backup when you need point-in-time recovery, you are not on Confluent Platform or Confluent Cloud, compliance requires immutable copies outside the cluster, or a second live Kafka cluster is not in the budget.
Choose Confluent Cluster Linking when you are already on Confluent, need low-RPO cross-cluster mirroring or a warm standby, and want offset-preserving replication without running a Connect cluster.
Run both when you are protecting production. Cluster Linking keeps a standby ready for infrastructure failure; backups get your data back after logical corruption. As with MirrorMaker 2 and Confluent Replicator, replication and backup protect against different failure modes — the full feature comparison sets every option side by side.
Frequently asked questions
Is Confluent Cluster Linking a backup?
No. Cluster Linking mirrors live topics between clusters byte-for-byte, so accidental deletes and corrupted records propagate to the destination. It cannot restore a topic to an earlier point in time. Backups keep immutable copies outside the cluster that you can restore from.
Does Cluster Linking preserve consumer offsets like OSO Kafka Backup?
Yes — offset preservation is a genuine strength of Cluster Linking, which mirrors topics byte-for-byte and can sync consumer group offsets. OSO Kafka Backup also preserves consumer group offsets, capturing them alongside topic data so restored consumers resume from the right position.
Do I need Confluent Platform to use OSO Kafka Backup?
No. OSO Kafka Backup uses standard Kafka client protocols, so it works with any distribution — self-managed Apache Kafka, Strimzi on Kubernetes, Amazon MSK, or Confluent. Cluster Linking is a Confluent Platform and Confluent Cloud feature.
Can I use OSO Kafka Backup and Cluster Linking together?
Yes, and many Confluent estates should. Cluster Linking provides low-RPO availability with a mirrored standby cluster, while scheduled backups provide point-in-time recoverability from logical errors. They cover different failure modes.
Ready to protect your Kafka data?
Take your first backup in minutes with the open source CLI, or talk to us about Enterprise features like encryption, RBAC, and audit logging.