Skip to main content
Kafka Backup for Strimzi

Back up Strimzi-managed Kafka on Kubernetes

Declare backups and restores as Kubernetes resources. The Strimzi Backup Operator resolves bootstrap servers, cluster CA certificates, and KafkaUser credentials straight from your Strimzi custom resources — no bootstrap or TLS wiring by hand.

Strimzi-native, not bolted on

If you run Apache Kafka on Kubernetes with Strimzi, the Strimzi Backup Operator fits your existing model. Instead of configuring bootstrap servers and TLS material by hand, it reads connection details, cluster CA certificates, and KafkaUser credentials directly from your Strimzi Kafka and KafkaUser resources.

Backups and restores are declared as custom resources — KafkaBackup and KafkaRestore in the kafkabackup.com/v1alpha1 API group — so they live in Git alongside the rest of your cluster config. The operator runs each one as a Kubernetes Job that executes the kafka-backup CLI, so every run is inspectable with kubectl get jobs,pods.

Install and take a scheduled backup

Install the operator with Helm, then apply a KafkaBackup that references your Strimzi cluster and a storage backend. A schedule.cron field turns it into a recurring backup.

Helm install
helm repo add oso-devops https://osodevops.github.io/helm-charts/
helm repo update

helm install strimzi-backup-operator oso-devops/strimzi-backup-operator \
--namespace kafka \
--create-namespace

Safe restores by default

A KafkaRestore runs exactly once. Because a restore appends to the target topics, the operator never re-creates a completed restore Job — you delete and recreate the resource to run it again. Backups default to backoffLimit: 3 because re-running a backup is safe, while restores default to a single attempt to avoid duplicating records. The restore Jobs and retry behavior reference covers backoffLimit, status conditions, and cleanup semantics in full.

Running Kafka outside Strimzi — MSK, Confluent, or self-managed? Use the generic OSO Kafka Backup Operator instead; it targets any Kafka reachable over the network.

Frequently asked questions

How does the operator connect to my Strimzi cluster?

You reference your Strimzi Kafka resource with strimziClusterRef. The operator resolves the bootstrap servers, cluster CA certificate, and KafkaUser credentials from your Strimzi custom resources, so you do not configure connection or TLS material by hand.

Can I schedule recurring backups of a Strimzi cluster?

Yes. Set schedule.cron on the KafkaBackup resource and the operator runs the backup on that cron schedule as a Kubernetes CronJob. Omit it for a one-shot backup.

What happens if a restore fails partway through?

A KafkaRestore runs exactly once and is not retried automatically, because re-applying a partial restore could duplicate records. The CR reports RestoreFailed; to try again you delete the resource and create a new one. You can opt into pod retries with spec.backoffLimit when the restore is idempotent.

Which storage backends can I back a Strimzi cluster up to?

The operator writes to S3, Azure Blob, GCS, or filesystem storage, set under spec.storage. The same backends are available from the OSO Kafka Backup CLI, so backups are portable across deployment models.

Do I need this operator if I already run the generic OSO operator?

Use the Strimzi Backup Operator (kafkabackup.com/v1alpha1) when your cluster is managed by Strimzi, because it reads Strimzi Kafka and KafkaUser resources directly. For Kafka outside Strimzi, use the generic OSO Kafka Backup Operator (kafka.oso.sh/v1alpha1).

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.