Separate live storage from recovery history
AutoMQ runs a Kafka-compatible streaming platform on shared object storage. OSO Kafka Backup creates independent recovery points for restoring earlier topic state.
What AutoMQ Kafka does well
AutoMQ Kafka uses shared object storage as the durable home for live stream data. Its brokers provide Kafka protocol compatibility while compute and storage remain separate.
That design suits teams that want to replace or scale compute without moving broker-local partition data. A write-ahead log supports fast writes and fault recovery before data reaches shared object storage.
OSO Kafka Backup reads records, consumer group offsets, and topic configuration from a Kafka endpoint. It writes independent recovery points to S3, Azure Blob, GCS, or a filesystem.
These systems solve different problems. AutoMQ stores and serves the current stream. Backup preserves earlier states when the current log contains unwanted writes or deletions. The disaster recovery guide maps both roles to failure scenarios.
| Feature | OSO Kafka Backup | AutoMQ |
|---|---|---|
| Primary job | Backup and restore | Kafka-compatible streaming platform |
| Data state | Timestamped recovery points | Current live log |
| Object storage role | Independent backup target | Primary shared stream storage |
| Kafka client interface | Reads and writes through Kafka APIs | Serves Kafka protocol clients |
| Compute replacement | Not a broker platform | Shared data avoids broker-local partition moves |
| Point-in-time restore | Millisecond timestamp | Not the primary storage role |
| Logical error recovery | Restore an earlier known-good state | Depends on retained live state and platform controls |
| Consumer group offsets | Captured for recovery | Maintained as live Kafka group state |
| Restore target | Same or different Kafka cluster | Applications connect to AutoMQ |
| Storage backends | S3, Azure Blob, GCS, filesystem | S3-compatible object storage |
| Best fit | Historical recovery and portability | Elastic live stream processing |
When to choose AutoMQ or Kafka backup
Choose AutoMQ when you want a Kafka-compatible platform built around shared object storage. Its architecture fits elastic compute and long live-data retention without broker-local data movement.
Choose OSO Kafka Backup when you need independent recovery points, millisecond-precision restore, preserved consumer offsets, or a copy outside the running platform.
Run both when you want AutoMQ for live streaming and separate history for recovery. Shared storage protects live durability. Backup protects the ability to return to an earlier state. See the Kafka backup tools guide for the wider decision model.
Frequently asked questions
Is AutoMQ object storage the same as a Kafka backup?
No. AutoMQ uses object storage as the durable layer for its current live log. A backup keeps separate recovery points that can restore an earlier known-good state.
What does AutoMQ do well?
AutoMQ provides Kafka client compatibility with shared object storage. Its design separates compute from data and avoids broker-local partition movement when compute nodes change.
Can OSO Kafka Backup connect to AutoMQ?
AutoMQ exposes the Kafka protocol, so OSO Kafka Backup can connect as a Kafka client. Test the required Kafka APIs and security settings against your AutoMQ release.
Should I use AutoMQ and OSO Kafka Backup together?
Use both when you need elastic live streaming plus independent historical recovery. AutoMQ serves the current stream, while backup retains earlier states for restore.
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.