Get back up and running
Restore individual topics or an entire cluster to a chosen point in time, including Schema Registry and consumer offsets.
KAFKA BACKUP & RECOVERY
Backup and restore
all of Kafka.
Topics, schemas and
consumer offsets.
Continuous point-in-time backup in your own S3. Restore a cluster, clone production data into test environments or bring back the Schema Registry.
Self-hosted in your AWS account. Operated as code.
- Recovery point objective
- 60 secondsby default, configurable per topic
- Scale
- Thousands of partitionsScales out across shards
- Complete coverage
- Beyond the recordsTopics, schemas and consumer offsets
- Infrastructure
- Entirely yoursYour Kafka. Your S3. Your AWS account.
Recovery readiness starts before an incident
More than backup.
Keep your business running.
When your Kafka platform goes down, you need to get back up and running quickly. With streamkeepr, you restore data, schemas and consumer offsets from your backup so your applications can run again.
Ready for your next audit
Test recovery in a separate cluster. The restore report records which data was restored and the outcome, giving you documentation to bring to your next audit.
Test with realistic data
Clone production data from your backup into a test environment. No additional load on production and no production credentials required.
01 / Recovery
Three situations, one backup
Three situations every Kafka platform team meets sooner or later, each with the evidence streamkeepr produces.
The cluster is lost or compromised
A cluster deleted by an infrastructure change, an attacker with admin rights, or a mistake that reached the replica too. Mirroring copies the mistake; a backup lets you go back. streamkeepr rebuilds the cluster from the backup in your S3 bucket, in order.
- The Schema Registry is part of the backup: subjects, versions and schema IDs come back unchanged.
- After the preflight checks pass, every topic is restored to the chosen point in time, with its consumer offsets.
- Services resume where they were.
Schema Registry, restored first1,180 subjects, same IDsPassed
Cluster restore740 topics, 2,960 partitions
- Planningto 05:50:00 UTC
- Preflight0 errors
- Creating topics740 topics
- Restoring2,960 partitions
- Offsets418 groups
- Done
- Records restored
- 29,640,118,207
- Records skipped
- 0
- Consumer offsets applied
- 418 of 418 groups
Point in time 29 Sep 05:50:00 UTC. Offsets applied only to stopped groups, with a rollback saved first. Example data.
A topic is gone
A GitOps change deletes a topic, or a wrong retention setting empties a compacted master-data topic. The rest of the cluster keeps running, and so should it. Restore just that topic to the point in time before the change.
- One topic, one point in time, under the same name or a new one.
- Only the consumer groups that read it are moved to their offsets.
- Everything else stays untouched.
- Cause
- retention set to 1 h on a compacted topic
- Point in time
- 29 Sep 14:20:00 UTC
- Records restored
- 48,112,330 · 12 partitions
- Consumer groups affected
- 14 of 418
- Resumed at their offsets
- 14 of 14
- Other topics
- 739, untouched
Example data.
Prove you can recover
The yearly recovery test or the audit has to include Kafka, and a slide is not evidence. Restore into an isolated test cluster from the same backup, and hand in the report.
- The same restore definition as in an emergency, pointed at a test cluster.
- A report with result, scope, window, records and consumer groups, printable.
- Repeat it whenever the auditor asks.
prod-eu1 into drill, recovery test 2026
Passed
All 29,640,118,207 planned records of 740 topics were restored into drill. No records were skipped.
- Window
- 1 Jul to 22 Sep
- 00:00 to 06:00 UTC
- Topics
- 740 of 740
- 2,960 partitions
- Records restored
- 29,640,118,207
- all planned records
- Records skipped
- 0
- none
- Preflight
- 0 errors
- 1 warning, 0 info
- Consumer offsets
- Applied
- 418 of 418 groups
- Schema Registry
- Restored
- IDs unchanged
- Backup integrity
- Verified
- all files checked
Topic map740 topics, one square each
Restored completely 740
02 / Production clones
Realistic test data, without touching production
Clone a time window of production topics into a test or integration cluster, as often as you need. Your pipeline starts each run; the clone reads only the backup.
- Topics and consumer groups are renamed for the target environment.
- Schema IDs are translated to the target Schema Registry; no connection to the production registry is needed. A schema missing in the target stops the run before anything is written.
- Records are spread over the target’s partition count exactly as a producer would place them, with the order per key kept.
- Production sees no extra load, and the job never gets production credentials.
PRODUCTION DATA → TEST ENVIRONMENTFROM YOUR BACKUP
- Topics
- prod.* → int.*
- Partitions
- 12 → 4 per topic
- Schema IDs
- prod registry → int registry
- Consumer groups
- prod-* → int-*
| Started | Window | Records | Groups |
|---|---|---|---|
| 28 Sep 02:00 | 24–27 Sep | 612,480,117 | 212 |
| 24 Sep 02:00 | 21–23 Sep | 418,906,355 | 212 |
| 22 Sep 15:10 | 15–21 Sep, orders.* only | 96,114,702 | 41 |
| 21 Sep 02:00 | 17–20 Sep | 603,211,480 | 211 |
| 17 Sep 02:00 | 14–16 Sep | 401,772,936 | 211 |
| 14 Sep 02:00 | 10–13 Sep | 588,064,219 | 208 |
Twice a week from the pipeline, plus ad-hoc runs for one domain. Each run empties its target topics first and writes its own report.
03 / Operations
Run it like the rest of your platform
One Helm chart in your EKS cluster. Backups and restores are configuration in Git, restores run as Kubernetes Jobs, and the status shows up where your team already looks.
- Deploy
- One Helm chart installs the backup next to Kafka in EKS, with an IAM role that can write to your bucket but not delete from it. New topics are picked up automatically.
- Backup as Code
- The backup and every restore are configuration in Git, reviewed like any other change. Restores run as Kubernetes Jobs in a release of their own, started by Argo CD, Flux or your CI pipeline, with their own credentials.
- Your data stays yours
- Backups are written to an S3 bucket in your account, encrypted with your KMS key, in a documented format. streamkeepr connects to your Kafka, your bucket and your Schema Registry, nothing else: no hosted service, no telemetry, no licence server.
- Evidence
- Every restore produces a report for sign-off: result, time window, records planned and restored, and consumer groups. One file that opens offline and prints, ready for the recovery test record.
- Observe
- Prometheus metrics, Grafana dashboards and alert rules with runbooks ship with the chart. The web dashboard shows the live state of backups and restores, what is restorable per topic and from when to when, and every restore with its report.
streamkeepr
Dashboard cluster prod-eu1
OverviewBackupRestores
14:03:12 UTC
Backup running. 2,952 of 2,960 partitions current; 6 catching up, 2 above RPO target.
Cluster prod-eu1. Restorable from 1 Jul 00:00, except where listed below.
Needs attention2 topics, 8 partitions
- Warningorders.placed.v36 partitions catching up after a broker restart.since 13:58
- Warningreporting.daily2 partitions above the 5 min RPO target, worst 6 min.since 13:51
BackupRPO target 60 s, reporting.* 5 min
- Topics
- 740
- 2 with problems
- Partitions
- 2,960
- 6 catching up
- Lag
- 412,806 records
- not yet backed up
- Worst RPO
- 6 min 02 s
- reporting.daily
- Throughput
- 118k rec/s
- 118k rec/s committed
Every partitionone square each, by topic name
- OK 2,952
- Catching up 6
- Gap 0
- RPO above target 2
- Paused or error 0
Restoreslast 3 of 14
- r-0929-dr29 Sep 09:35, into prod, 112 topicsPassed
- r-0929-int29 Sep 02:00, clone into int, 212 groupsPassed
- r-0922-drill22 Sep 20:00, into drill, 740 topicsPassed
04 / Integrations
Requirements and integrations
What streamkeepr runs on today, and what it does not cover. Tell us if you run something else.
| Kafka | Apache Kafka or Amazon MSK, SASL/SCRAM over TLS |
|---|---|
| Storage | Amazon S3 or an S3-compatible store, encrypted with your KMS key |
| Kubernetes | Amazon EKS with Helm; AWS access through IRSA or Pod Identity, no static keys |
| Schema Registry | Confluent-compatible, optional |
| Observability | Prometheus, Grafana, alert rules with runbooks, web dashboard |
| Automation | Argo CD, Flux or any CI/CD that can apply a Helm release |
| Not included | ACLs, quotas and broker configuration; MSK IAM authentication; continuous mirroring between clusters |
05 / Licensing
Pricing
One yearly licence per project, for every cluster and every environment. Pricing on request, tailored to your project.
- Scope
- one project or program; all its Kafka clusters and environments: production, integration, test, recovery
- Metric
- per project and year, independent of broker count
- Operation
- you install and run streamkeepr in your own AWS account; support for setup, rehearsals and incidents is included
- Price
- on request; tell us about your landscape and we send a quote
06 / Good to know
Questions
Can we pass our recovery test with Kafka included?
Yes. You restore the topics to a chosen point in time, into the recovered or a new cluster, together with the consumer group offsets and the Schema Registry, so every consumer group resumes where it was. Every restore produces a report with the result, the window, the records and the consumer groups, which goes into the test record. Rehearse on a test cluster first.
How do we get realistic test data without touching production?
Clone a time window from the backup into the test cluster. Topics and consumer groups are renamed, schema IDs are translated to the test registry, and partitions are adapted. The clone reads only the backup, so production sees no load and the job never holds production credentials.
Do our services resume at the right offset after a restore?
Consumer group offsets are part of the backup. streamkeepr translates each group’s offset at the chosen point in time into the restored topics, so the group resumes where it was; you review the plan, apply it to stopped groups and roll it back if needed. Offsets that your services keep outside Kafka are yours to adjust.
What does our team have to operate?
Little. One Helm release in your EKS cluster runs the backup on its own. Restores are not a service you keep running: each one is a Kubernetes Job that starts when you need it and ends when it is done. Metrics, dashboards and alerts plug into your existing Prometheus and Grafana, and support is included in the licence.
Does any data leave our AWS account?
No. streamkeepr runs in your cluster and connects to your Kafka, your S3 bucket and your Schema Registry. There is no hosted service, no telemetry and no licence server. The backup stays in your bucket in a documented format.
Can we rehearse a recovery?
Yes. Point the same restore definition at an isolated test cluster and keep the report as evidence for your recovery test.
Isn’t replication already a backup?
Replication copies a faulty write or a deletion to every replica within milliseconds, and retention removes old data on a schedule. It protects against a failed broker, not against a bad release or a lost cluster.
How is it licensed?
One yearly licence per project or program, covering all of its clusters and environments, independent of broker count, with support included. Pricing is on request: send us a note on your landscape and you get a quote.
Let’s talk
See it on a cluster like yours
We show a backup, a point-in-time restore with consumer groups and a production data clone on a test cluster, and answer your recovery questions. Tell us about your landscape, and we schedule the demo, send a quote or rehearse in your own environment.
Request sentThank you
We have your request and will get back to you by e-mail. If you do not hear from us, write to sales@streamkeepr.io.
Good fit if you run
- Kafka
- Apache Kafka or Amazon MSK with SASL/SCRAM
- Kubernetes
- Amazon EKS with Helm
- Storage
- an S3 bucket and a KMS key in your account
- Schemas
- a Confluent-compatible Schema Registry (optional)