A great data-lake sink is not a backup
The Kafka Connect S3 Sink Connector is a mature, widely deployed tool that streams topic records into S3 as Avro, JSON, or Parquet. It does that job well. But it was built to feed a data lake, not to restore Kafka — and that difference matters the day you need your data back. Here is where each one fits.
Built for two different outcomes
The Kafka Connect S3 Sink consumes topics and writes them to S3 as partitioned object files, usually for analytics: query the data in Athena, Spark, or a warehouse. It is schema-aware, supports exactly-once delivery to S3, and partitions output by time or field. For landing streaming data in a lake, it is the standard choice.
OSO Kafka Backup captures topic records, consumer group offsets, and topic configuration to object storage (S3, Azure Blob, GCS) or local disk, and 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 it covers.
The gap shows up at restore time. The S3 sink gives you files that are excellent for querying and awkward to replay: there is no first-class path to recreate topics, re-apply consumer group offsets as a logical unit, and stop at the moment before a bad deploy. A backup tool treats the restore as the point of the exercise.
| Feature | OSO Kafka Backup | Kafka Connect S3 Sink |
|---|---|---|
| Primary purpose | Backup / restore | Stream to data lake |
| Restore back into Kafka | Built-in | Not a first-class path |
| Point-in-time recovery | Yes | No |
| Consumer offset preservation | Built-in | Not captured |
| Topic config captured | Yes | No |
| Output layout | Restore-oriented | Query-oriented (partitioned files) |
| Storage backends | S3, Azure, GCS, local | S3 / S3-compatible |
| Compression | Zstd, LZ4 | Format codec |
| Runs without Kafka Connect | Single CLI | Needs Connect cluster |
| Best for | DR, migration, compliance | Analytics ingestion |
What the sink leaves you to build
Restore. The connector writes objects; it does not read them back into Kafka. To recover you would write and maintain a consumer that recreates topics from the file layout — the hard half of any backup system.
Offsets. Sink output records the messages, not the consumer group offsets. After a restore assembled from sink files, consumers have no consistent position to resume from. Offset preservation is built into a backup tool.
Point in time. Recovering from a bad deploy means restoring the topic to the moment before it. Sink files are partitioned for querying, not for a windowed restore back into a cluster.
When to choose which
Choose the Kafka Connect S3 Sink when your goal is analytics: landing topic data in a lake or warehouse for querying, with schema evolution and time-based partitioning.
Choose OSO Kafka Backup when your goal is recovery: point-in-time restore, offset-consistent topic recovery, cross-cluster migration, or a compliance copy outside the cluster. The full feature comparison sets this against replication and DIY approaches too.
Run both when you already stream to a lake but have no restore story. The sink feeds analytics; the backup gets your topics back. They serve different days.
Frequently asked questions
Can I use the Kafka Connect S3 Sink Connector as a Kafka backup?
It covers the write path — it streams topic records into S3 as partitioned files. It does not restore topics back into Kafka, preserve consumer group offsets as a logical unit, or support point-in-time recovery, so you would still build and maintain the entire restore side yourself.
Why can I not just replay the S3 sink files back into Kafka?
The sink writes objects partitioned for querying (by time or field), in Avro, JSON, or Parquet. There is no first-class tool to recreate the original topics, re-apply consumer group offsets, and stop at a precise timestamp. Assembling that restore path is the work a purpose-built backup tool does for you.
Does OSO Kafka Backup also need a Kafka Connect cluster?
No. It is a single CLI driven by a YAML config. You point it at your brokers and a storage backend and run one command, so there is no Connect cluster, worker, or connector configuration to operate.
Should I run the S3 sink and OSO Kafka Backup together?
Often, yes. Many teams already run the S3 sink to feed a data lake but have no way to restore Kafka. The sink handles analytics ingestion; OSO Kafka Backup handles offset-consistent, point-in-time restore. They protect different needs.
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.