Kafka Backup Tools Compared: MirrorMaker 2, Connect S3, Replicator, and Point-in-Time Backup

Choosing the right Kafka backup tool is the difference between a five-minute recovery and a five-hour scramble. There is no single winner. Each tool solves a specific problem: MirrorMaker 2 and MSK Replicator keep a warm cluster for regional failover, Kafka Connect S3 Sink archives topics to cheap object storage, and point-in-time backup restores a topic to the moment before a bad deploy. This guide compares all four, shows where each fits, and gives you a decision matrix so you can match tools to requirements instead of the other way around.

Key takeaway

Replication tools (MirrorMaker 2, MSK Replicator) give you availability, not recoverability — they faithfully copy deletions and corruption to the target. Storage sinks (Connect S3) archive data but do not preserve offsets or support a clean restore. Point-in-time backup is the only category that recovers from corruption and accidental deletion. Most production setups combine two: a replication tool for failover and continuous backup for the cases replication cannot cover.

The Kafka backup tool categories

The tools people reach for when they say "Kafka backup" fall into three categories that solve different problems. Confusing them is the root of most Kafka data-loss incidents.

• Replication tools copy records from one live cluster to another in near real time. MirrorMaker 2, MSK Replicator, and Confluent Replicator live here. They protect against losing a broker, an availability zone, or a whole region.
• Storage sinks stream topic records into object storage as files. Kafka Connect S3 Sink is the common choice. They are built for long-term retention and analytics export, not fast operational restore.
• Point-in-time backup writes an independent, restorable copy of topics and consumer group offsets to object storage. This is the category that lets you rewind to a moment in time.

The distinction that matters most: replication is not backup. A replication tool mirrors every write — including the write that corrupted your data. If a producer bug emits malformed events for an hour, the replica holds an hour of malformed events. If an operator deletes a topic, the deletion propagates. Replication raises availability. Only backup gives you recoverability. Keep that split in mind as you read the tool-by-tool breakdown.

MirrorMaker 2 — cross-cluster replication for DR

MirrorMaker 2 (MM2) ships with Apache Kafka and runs on the Kafka Connect framework. It replicates topics, consumer group offsets, and ACLs from a source cluster to one or more targets, and it supports active-passive DR, active-active topologies, and cluster migration.

How it works. MM2 runs three connectors: MirrorSourceConnector copies records, MirrorCheckpointConnector translates and syncs consumer group offsets, and MirrorHeartbeatConnector emits heartbeats for lag monitoring. By default it prefixes remote topics with the source cluster alias, so a topic named orders on cluster us-east becomes us-east.orders on the target.

Pros. It is free and built into Kafka, works across any Kafka deployment and any cloud, syncs offsets so consumers resume near their last position, and supports active-active replication for multi-region reads.

Cons. You run and scale the Connect cluster yourself. Lag monitoring is your responsibility, topic prefixing complicates failover logic, and there is no point-in-time recovery — MM2 replicates deletions and corruption like any other write.

Best for. Active-passive DR, cluster migration, and multi-cloud replication where you need control and want to avoid managed-service lock-in.

For a deeper look at MM2 configuration and cross-datacenter topologies, see Kafka replication across data centers. For a direct comparison with point-in-time backup, see OSO Kafka Backup vs MirrorMaker.

Kafka Connect S3 Sink — topic archiving to cloud storage

The Kafka Connect S3 Sink connector reads records from topics and writes them as files to Amazon S3, GCS, or Azure Blob storage. It is the standard way to get Kafka data into a data lake or a long-term archive.

How it works. The connector consumes configured topics and flushes batches of records to object storage, partitioned by topic, partition, and time. You control format (Avro, JSON, Parquet), flush size, and partitioning.

Pros. Setup is simple, storage is cheap, and the partitioned output slots straight into analytics pipelines. It handles high volume and scales with the Connect cluster.

Cons. It backs up records, not consumer group offsets, so a restore cannot resume consumers where they left off. There is no built-in restore path — you write custom tooling to read the files back into Kafka — and its higher flush intervals mean a higher RPO than a purpose-built backup tool.

Best for. Long-term retention, compliance archives, and exporting topic data to a data lake. It is an archive, not an operational recovery tool.

For managed retention that pushes older segments to object storage automatically, Kafka tiered storage covers a related approach and how it differs from backup.

OSO Kafka Backup — open-source point-in-time recovery

OSO Kafka Backup is an open-source (MIT) tool built for the case replication and sinks cannot cover: restoring a topic to a specific point in time. It writes a continuous, independent copy of topic data and consumer group offsets to object storage, and restores with millisecond precision.

How it works. The tool streams topics to a storage backend — Amazon S3 and S3-compatible stores, Azure Blob, GCS, or a filesystem — with Zstd or LZ4 compression. Consumer group offset preservation is built in, so a restore brings back both the data and the position your consumers were reading from.

Pros. Point-in-time recovery to a chosen timestamp, offset preservation, open source, and cloud-native storage with compression. A Kubernetes operator is available and it is Strimzi compatible. Enterprise features add Schema Registry sync, encryption, RBAC, and audit logging.

Cons. It is a younger project than MirrorMaker 2, and it targets backup and restore rather than live replication — you pair it with a replication tool when you also need a warm cluster for regional failover.

Best for. Recovery from corruption or accidental deletion, compliance mandates for an independent copy, and selective topic restore. A minimal backup config looks like this:

mode: backup
backup_id: "prod-continuous"

kafka:
  bootstrap_servers:
    - broker-1.example.com:9092
    - broker-2.example.com:9092

storage:
  backend: s3
  bucket: kafka-topic-backups
  region: us-east-1
  compression: zstd

See the config reference for every option and the getting started guide for a full walkthrough.

Managed service replicators — MSK Replicator and Confluent Replicator

If you run a managed Kafka platform, the vendor offers its own replication service so you skip operating Connect yourself.

MSK Replicator is a fully managed Amazon MSK feature that replicates topic data, consumer group offsets, and topic configuration between MSK clusters, across regions or accounts. It uses identity replication — topic names stay the same on the target, which keeps failover logic simple. AWS runs the compute and networking; pricing is per GB processed plus cross-region transfer. See the MSK Replicator complete guide for setup and failover detail, or OSO Kafka Backup vs MSK Replicator for the backup comparison.

Confluent Replicator is Confluent's managed connector for copying topics and configuration between clusters, with offset translation for consumers. It fits teams already on Confluent Platform or Cloud. Compare it with point-in-time backup at OSO Kafka Backup vs Confluent Replicator.

Pros. Zero replication infrastructure to operate, built-in monitoring, and tight integration with the managed platform.

Cons. Vendor lock-in, less configurability than self-managed MM2, and cost that scales with volume. Like all replication, neither one is a backup — both copy deletions and corruption to the target.

Comparison matrix

Feature	MirrorMaker 2	Connect S3 Sink	OSO Kafka Backup	MSK Replicator
Real-time replication	Yes	No	No	Yes
Point-in-time recovery	No	No	Yes	No
Offset preservation	Yes	No	Yes	Yes
Cloud storage backup	No	Yes	Yes	No
Restore tooling included	Partial	No	Yes	Partial
Open source	Yes	Yes	Yes	No
Operational complexity	High	Low	Medium	Low
Cloud scope	Any	Any	Any	Amazon MSK only
Best for	DR failover	Long-term archive	PITR recovery	AWS cross-region DR

Read the matrix by column, not by row. No column wins outright, because the tools answer different questions. The right build combines the columns that match your failure modes.

How to choose: a decision guide

Match the tool to the failure you are protecting against, not to a feature list.

• Need regional failover with a warm cluster? Use a replication tool. MirrorMaker 2 for any Kafka or multi-cloud, MSK Replicator when both clusters are on Amazon MSK, Confluent Replicator on Confluent Platform.
• Need cheap long-term retention or a data-lake feed? Use Kafka Connect S3 Sink. Accept that restore is a custom job and offsets are not preserved.
• Need to recover from corruption, accidental deletion, or a compliance audit? Use point-in-time backup. This is the only category that rewinds.
• Running production at any real scale? Combine two. A replication tool for availability plus continuous backup for recoverability is the standard pattern.

Start with backup if you have nothing today — it is the layer that prevents permanent data loss. Add replication when your RTO for a regional outage drops below what a restore-from-storage can meet. The order matters: a warm replica of corrupted data recovers nothing, but a backup always gives you a floor.

For the full strategy view — schedules, retention, and how these layers fit together — see Kafka backup strategies and the Kafka disaster recovery architecture guide.

Conclusion

No single Kafka backup tool covers every need, and treating one as if it does is how teams lose data. Replication tools like MirrorMaker 2 and MSK Replicator protect against losing a region but faithfully copy corruption and deletions. Connect S3 Sink archives data cheaply but skips offsets and clean restore. Point-in-time backup is the only category that rewinds to a moment before things broke.

Match the tool to the failure mode, and expect to run more than one. The common production build pairs a replication tool for fast failover with continuous point-in-time backup for corruption, deletion, and compliance. When you are ready to add the backup layer, the getting started guide has the exact steps, and the integrations pages cover S3, Azure Blob, GCS, and Kubernetes with Strimzi.

Frequently asked questions

What is the best tool for backing up Kafka?

There is no single best tool — it depends on the failure you are protecting against. For recovery from corruption or accidental deletion, use a point-in-time backup tool that preserves consumer group offsets and supports timestamped restore. For regional failover, use a replication tool such as MirrorMaker 2 or MSK Replicator. Most production setups combine a replication tool for availability with continuous backup for recoverability.

How do you back up Kafka topics to S3?

Two common approaches exist. The Kafka Connect S3 Sink connector streams topic records into S3 as partitioned files for long-term archiving, but it does not preserve consumer offsets or include a restore path. A dedicated point-in-time backup tool writes topics and offsets to S3, S3-compatible stores, Azure Blob, or GCS with compression and supports millisecond-precision restore, which makes it suitable for operational recovery.

What is the difference between MirrorMaker and Confluent Replicator?

MirrorMaker 2 ships with Apache Kafka, runs on the Kafka Connect framework, is free and open source, and works across any Kafka deployment or cloud — but you operate and scale it yourself. Confluent Replicator is a managed connector from Confluent with built-in offset translation, best suited to teams already on Confluent Platform or Cloud. Both replicate data and offsets, and neither is a backup: both copy deletions and corruption to the target.

Can you restore Kafka to a specific point in time?

Yes, but only with a point-in-time backup tool. Replication tools and storage sinks cannot rewind — replication mirrors every write including corrupt ones, and Connect S3 Sink has no clean restore path. A point-in-time backup tool that captures topic data and consumer group offsets continuously can restore a topic to a chosen timestamp, which is what you need after a bad deploy or accidental deletion.

Is there an open-source Kafka backup tool?

Yes. OSO Kafka Backup is open source under the MIT license. It writes a continuous, independent copy of topic data and consumer group offsets to object storage — Amazon S3 and S3-compatible stores, Azure Blob, GCS, or a filesystem — with Zstd or LZ4 compression, and restores with millisecond precision. A Kubernetes operator is available and it is Strimzi compatible.