How long does a Kafka backup actually take? Results from our benchmarks

TL;DR: Kafka backup speed is set by the platform, not by the backup tool. A 50-topic, 2TB cluster on Confluent Cloud took 8 hours, capped at 10 parallel workers by Confluent's own limits, not by the backup engine. On a self-hosted cluster with fewer restrictions, the same engine moved data at gigabytes per second.

Methodology

These numbers come from production backup runs on Kannika, Cymo's realtime backup and restore engine for Apache Kafka. The primary run backed up a 50-topic cluster holding 2TB of data on Confluent Cloud, writing to S3-compatible object storage. A second data point comes from a different customer running Kafka on self-hosted infrastructure, using the same backup engine. Kannika supports 10+ Kafka-compatible platforms, and this comparison holds the software constant while the environment underneath changes.

Finding 1: Backup duration and recovery point are two different questions

Backup duration measures how long a full export takes. Recovery point objective (RPO) measures how much data a team would lose if the source cluster died right now. The two sound related, but they get answered by different mechanisms.

Kannika replicates continuously, which is why it's built for realtime rather than batch. In one deployment, that continuous stream kept RPO down to about 0.1 seconds, independent of how long the periodic full backup job took to run. If your backup solution is batch-driven instead, RPO is set by how often those batch jobs fire, so the time between backups is also the time of what could be lost.

That sub-second figure isn't a universal number. RPO depends on network conditions, cluster load, and how the deployment is configured, and it will vary from one environment to the next. What holds across environments is the mechanism: continuous replication decouples recovery point from backup job duration. Batch doesn't.

Finding 2: The infrastructure sets the speed limit, not the backup engine

The 8-hour number is easy to misread on its own. "2TB took 8 hours" sounds like a statement about how fast Kannika can move data. It isn't. On the Confluent Cloud run, the backup used 10 parallel workers, the maximum Confluent Cloud allowed for that job. Kannika never became the bottleneck at any point, and 8 hours is what that quota produced.

The self-hosted customer makes the point harder to miss: same backup engine, throughput climbed into gigabytes per second before the job wrapped, and no sign of Kannika throttling there either. Do the math on the Confluent Cloud run and the average works out to roughly 250GB per hour, well under 0.1GB per second. The self-hosted run measured throughput in whole gigabytes per second, easily ten times faster and possibly more, depending on the hour.

A managed Kafka service enforces its own connection and throughput quotas. A self-hosted cluster hands over more control, and the ceiling moves with it. Ask any vendor about Kafka backup performance, and the answer starts with a question of its own: what does your platform's own throughput cap allow? If you run on Confluent specifically, our Confluent Kafka backup guide covers what those platform limits mean for backup in that environment.

Finding 3: More topics didn't mean more time

The Confluent Cloud cluster held 50 topics. It's reasonable to assume that backing up 50 topics takes proportionally longer than backing up 5. That's not what happened here. Job duration tracked with the throughput cap, not with topic count. Once the 10 parallel workers were running, adding more topics to the queue barely moved the total.

That's a useful reference point for anyone running their own Kafka backup speed benchmark. Topic count is a reasonable proxy for job complexity, but it's a weak predictor of backup duration once parallelism becomes the actual constraint.

Finding 4: What actually lands in storage

Backups still need somewhere to live, and at current storage prices, compression is often worth a second look before the bill arrives. Kannika supports realtime compression, and in this benchmark the 2TB source dataset landed on S3-compatible storage at roughly 222GB, about 11% of the original size.

Kannika supports several compression algorithms, and according to our benchmark, most of them land on a similar compression ratio without adding to total transfer time.

What this means for Kafka architects

The RPO gap matters most for clusters carrying financial transactions, audit trails, or anything where losing even a few minutes of events has a real cost. Continuous replication closes that gap in a way a scheduled batch job can't, no matter how tightly the schedule is set.

Full backup duration is a separate question, and it's gated by whatever the underlying platform allows, whether that's Confluent Cloud's worker limits or a self-hosted cluster's raw throughput. Worth asking a vendor about parallelism limits and platform quotas before asking about their own engineering. How those numbers translate into RPO and RTO targets your business signs off on is covered in our Kafka backup best practices guide.

That also means a vendor's published benchmark, this one included, is a starting point rather than a guarantee. The number that matters is the one measured against your own topics, on your own platform, with your own worker limits.

Across both runs in this benchmark, on Confluent Cloud and on a self-hosted cluster, Kannika never showed up as the constraint. That's the claim we've made about the product all along. This time, the numbers back it up.

Try it on your own cluster

The benchmark numbers above come from real production clusters, not a lab setup. A few ways to see it for yourself: run your own topics through the Kannika Console sandbox, start a free trial, or request a demo.