Offload is not backup
Kafka tiered storage (KIP-405) is a genuinely good feature: it moves older log segments to object storage, cuts broker disk costs, and makes long retention affordable — all transparently to clients. But the data still belongs to one cluster, under one set of retention rules. Here is where the two approaches differ.
Two different jobs
Kafka tiered storage splits each topic's log into a local tier and a remote tier. Once a
segment rolls, the broker offloads it to object storage and can delete the local copy after
local.log.retention.ms expires. Consumers read old data through the broker exactly as before.
The result is cheaper long retention without a second system — the main reason to use it.
OSO Kafka Backup takes point-in-time backups of topic data, consumer group offsets, and topic configuration to storage the cluster does not control, and restores any of it — to the same cluster or a different one — with millisecond precision.
The critical difference is independence. Tiered segments are still part of the live log: delete the topic, hit a retention boundary, or lose the cluster metadata, and the offloaded data goes with it. Reading the remote tier also requires running brokers. A backup is a separate copy with its own lifecycle, restorable even when the cluster that wrote it no longer exists — the full feature comparison covers this line by line.
| Feature | OSO Kafka Backup | Tiered Storage |
|---|---|---|
| Purpose | Backup / restore | Broker disk cost reduction |
| Point-in-time recovery | Yes | Limited |
| Independent from the cluster | Yes | No |
| Cross-cluster restore | Yes | No |
| Protects against deletes / bad data | Yes | No |
| Compacted topics | Supported | Not supported |
| Compression | Zstd, LZ4 | Kafka default |
| Availability | Any Kafka version | Kafka 3.9+ GA, or Confluent |
| Broker dependency for reads | None | Requires running brokers |
| Reversible per topic | N/A | No — enablement is permanent |
Operational details worth knowing
A few properties of KIP-405 matter when you evaluate it as a safety net rather than a cost tool.
Apache Kafka ships the RemoteStorageManager interface but no implementation, so you deploy and
operate a plugin yourself. Only closed segments are offloaded — the active segment always stays
on broker disk. Compacted topics and multiple log directories (JBOD) are not supported. And once
a topic has tiered storage enabled, it cannot be disabled; the documented path is migrating the
data elsewhere and deleting the topic.
None of this is a criticism of the feature. It is retention infrastructure, and it behaves like retention infrastructure: an accidental delete, a poisoned producer deploy, or an expired retention window removes data from the remote tier just as it does from local disk.
When to choose which
Choose OSO Kafka Backup when you need recovery from logical errors, restores into a different cluster, copies that survive cluster loss, compliance-grade retention outside Kafka, or you run compacted topics or Kafka versions before 3.9.
Choose tiered storage when your goal is cheaper long retention on the same cluster, your
consumers occasionally replay old data, and you are on Kafka 3.9+ or Confluent with a supported
RemoteStorageManager plugin.
Run both when you are protecting production: tiered storage keeps the live log affordable, backups make it recoverable. They store data in similar places for entirely different reasons — the disaster recovery use cases show the failure scenarios only a backup covers.
Frequently asked questions
Is Kafka tiered storage a backup?
No. Tiered storage offloads older log segments to object storage but they remain part of the live topic, owned by the cluster. Topic deletion, retention expiry, and corrupted writes all propagate to the remote tier. A backup is an independent copy with its own lifecycle.
Can Kafka tiered storage restore data to a different cluster?
No. KIP-405 has no cross-cluster restore or point-in-time recovery mechanism, and reading the remote tier requires the brokers that own the log. OSO Kafka Backup restores topics, offsets, and configuration to any cluster, including one built from scratch after a total loss.
Can I turn tiered storage off for a topic once it is enabled?
No. Per-topic enablement is permanent in Apache Kafka — the documented path is migrating the data to another topic or external storage and deleting the original. Disabling it cluster-wide first requires deleting every tiered topic.
Does tiered storage work with compacted topics?
No. Apache Kafka documents compacted topics as unsupported for tiered storage, along with multiple log directories (JBOD). OSO Kafka Backup backs up compacted topics like any other topic.
Should I use tiered storage and backups together?
Often, yes. Tiered storage lowers the cost of keeping a long live log; scheduled backups add point-in-time recovery, cross-cluster restore, and copies that survive cluster loss. They address cost and recoverability respectively, and neither replaces the other.
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.