KAFKA BACKUP & RECOVERY

Backup und Restorefür Ihre Kafka-Plattform.

Topics, Schemas und
Consumer-Offsets.

Sichern Sie Ihre Kafka-Daten kontinuierlich im eigenen S3-Bucket. Stellen Sie Cluster und Schema Registry zu einem gewählten Zeitpunkt wieder her oder klonen Sie Produktionsdaten für Ihre Testumgebungen.

Demo anfragen Recovery entdecken

In Ihrem AWS-Account betrieben. Über Git verwaltet.

YOUR DATA. PRESERVED.

Recovery Point Objective: 60 SekundenStandardwert, pro Topic konfigurierbar
Skalierung: Tausende PartitionenHorizontal über Shards skalierbar
Backup-Umfang: Mehr als nur NachrichtenTopics, Schemas und Consumer-Offsets
Infrastruktur: In Ihrem AWS-AccountIhre Cluster, Ihr S3-Bucket, Ihre Schlüssel.

Betriebsfähigkeit beginnt vor dem Ernstfall

Mehr als Daten sichern.
Handlungsfähig bleiben.

Wenn Ihre Kafka-Plattform ausfällt, muss der Betrieb schnell weitergehen. Mit streamkeepr stellen Sie Daten, Schemas und Consumer-Offsets aus Ihrem Backup wieder her – damit Ihre Anwendungen wieder laufen.

01 / FAST RESTORE

Schnell wieder im Betrieb

Stellen Sie einzelne Topics oder einen ganzen Cluster zum gewählten Zeitpunkt wieder her – einschließlich Schema Registry und Consumer-Offsets.

02 / AUDIT-REPORTS

Bereit fürs nächste Audit

Testen Sie die Wiederherstellung in einem separaten Cluster. Der Restore-Report hält fest, welche Daten wiederhergestellt wurden und mit welchem Ergebnis. So haben Sie die Dokumentation für Ihr nächstes Audit bereits zur Hand.

03 / ENTWICKLUNG

Mit realistischen Daten testen

Klonen Sie Produktionsdaten aus dem Backup in Ihre Testumgebung. Ohne zusätzliche Last auf der Produktion und ohne deren Zugangsdaten.

01 / Recovery

Drei Situationen, ein Backup

Einen Cluster wiederherstellen, ein gelöschtes Topic zurückholen oder die Recovery im Audit belegen: So unterstützt streamkeepr Ihr Plattformteam.

Ein Cluster fällt aus oder wird kompromittiert

Eine Infrastrukturänderung löscht einen Cluster. Ein Angreifer erhält Administratorrechte. Oder fehlerhafte Daten werden auf die Replikate übertragen. Mit streamkeepr stellen Sie den gesicherten Stand aus Ihrem S3-Bucket wieder her: zuerst die Schema Registry, dann die Topics und Consumer-Offsets.

Die Schema Registry ist Teil des Backups: Subjects, Versionen und Schema-IDs werden unverändert wiederhergestellt.
Preflight-Checks prüfen den Restore, bevor Topics und Consumer-Offsets zum gewählten Zeitpunkt wiederhergestellt werden.
Ihre Consumer-Gruppen lesen an den zum gewählten Datenstand passenden Offsets weiter.

Recovery into prod-eu1-bComplete

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.

Ein Topic wurde gelöscht

Eine GitOps-Änderung löscht ein Topic oder eine falsche Retention-Einstellung leert ein kompaktiertes Stammdaten-Topic. Stellen Sie gezielt den Stand vor der Änderung wieder her, während der übrige Cluster weiterläuft.

Stellen Sie das Topic zum gewünschten Zeitpunkt wieder her, unter dem bisherigen oder einem neuen Namen.
Nur die zugehörigen Consumer-Gruppen erhalten die passenden Offsets.
Alle anderen Topics und Consumer-Gruppen bleiben unverändert.

Restore customers.masterPassed

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.

Recovery im Audit nachweisen

Beziehen Sie Kafka in Ihre Recovery-Tests ein. Stellen Sie die Daten aus dem Backup in einem isolierten Testcluster wieder her. Der Restore-Bericht dokumentiert das Ergebnis für Ihr Testprotokoll und das Audit.

Nutzen Sie dieselbe Restore-Definition wie im Ernstfall, mit einem isolierten Testcluster als Ziel.
Dokumentieren Sie Ergebnis, Umfang, Zeitfenster, Nachrichten und Consumer-Gruppen in einem druckbaren Bericht.
Wiederholen Sie den Test bei Bedarf mit derselben Konfiguration.

Restore report r-0922-drill22 Sep 2026

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

Printable as PDF, laid out for A4, with the details per topic, consumer group and check on the following pages. Example data.

02 / Production Clones

Realistische Testdaten aus Ihrem Backup

Übertragen Sie Produktionsdaten aus einem gewählten Zeitfenster in einen Test- oder Integrationscluster. Ihre Pipeline startet den Klon bei Bedarf oder nach Zeitplan. Er liest ausschließlich aus dem Backup und belastet die Produktion nicht zusätzlich.

Topics und Consumer-Gruppen erhalten die Namen der Zielumgebung.
Schema-IDs werden den IDs in der Ziel-Registry zugeordnet. Eine Verbindung zur produktiven Schema Registry ist nicht erforderlich. Fehlt ein Schema im Ziel, stoppt der Lauf, bevor Daten geschrieben werden.
Nachrichten werden nach derselben Logik wie bei einem Producer auf die Zielpartitionen verteilt. Die Reihenfolge pro Key bleibt erhalten.
Der Job arbeitet ohne Zugangsdaten zur Produktionsumgebung.

PRODUCTION DATA → TEST ENVIRONMENTFROM YOUR BACKUP

Clones into intExample data

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

In Ihre Plattform integriert

Sie installieren streamkeepr per Helm in Ihrem EKS-Cluster und verwalten Backups und Restores über Git. Jeder Restore läuft als Kubernetes-Job. Metriken und Alarme fließen in Ihr bestehendes Monitoring ein.

Bereitstellung: Ein Helm-Chart stellt streamkeepr in Ihrem EKS-Cluster bereit. Die IAM-Rolle für das Backup darf in Ihren S3-Bucket schreiben, aber keine Daten daraus löschen. Neue Topics werden automatisch gesichert.
Backup as Code: Backup- und Restore-Konfigurationen liegen in Git und durchlaufen Ihre üblichen Reviews. Argo CD, Flux oder Ihre CI-Pipeline starten jeden Restore als Kubernetes-Job in einem eigenen Helm-Release mit separaten Zugangsdaten.
Ihre Daten bleiben bei Ihnen: Ihre Backups bleiben in Ihrem S3-Bucket, verschlüsselt mit Ihrem KMS-Schlüssel und in einem dokumentierten Format. streamkeepr greift ausschließlich auf Ihre Kafka-Cluster, Ihren Bucket und Ihre Schema Registry zu. Es gibt keinen von uns gehosteten Dienst, keine Telemetrie und keinen Lizenzserver.
Nachweise: Jeder Restore liefert einen Bericht für die Prüfung und Freigabe: Ergebnis, Zeitfenster, geplante und wiederhergestellte Nachrichten sowie Consumer-Gruppen. Der Bericht lässt sich offline öffnen und ausdrucken und ergänzt die Dokumentation Ihres Recovery-Tests.
Monitoring: Das Helm-Chart enthält Prometheus-Metriken, Grafana-Dashboards sowie Alarmregeln mit Runbooks. Im Web-Dashboard sehen Sie den Status Ihrer Backups, den wiederherstellbaren Zeitraum jedes Topics und alle Restores mit ihren Berichten.

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

The streamkeepr dashboard, overview. Read-only: it never starts, stops or deletes anything. Example data.

04 / Integrationen

Voraussetzungen und Integrationen

Diese Systeme und Schnittstellen unterstützt streamkeepr derzeit. Wenn Sie andere Komponenten einsetzen, sprechen Sie uns an.

Technische Voraussetzungen und Funktionsumfang
Kafka	Apache Kafka oder Amazon MSK, SASL/SCRAM über TLS
Speicher	Amazon S3 oder S3-kompatibler Speicher, verschlüsselt mit Ihrem KMS-Schlüssel
Kubernetes	Amazon EKS mit Helm; AWS-Zugriff über IRSA oder Pod Identity, ohne statische Schlüssel
Schema Registry	Confluent-kompatibel, optional
Monitoring	Prometheus, Grafana, Alarmregeln mit Runbooks, Web-Dashboard
Automatisierung	Argo CD, Flux oder jede CI/CD-Pipeline, die ein Helm-Release bereitstellen kann
Nicht enthalten	ACLs, Quotas und Broker-Konfiguration; MSK-IAM-Authentifizierung; kontinuierliche Spiegelung zwischen Clustern

05 / Lizenzierung

Preise

Eine Jahreslizenz deckt alle Kafka-Cluster und Umgebungen Ihres Projekts ab. Die Anzahl der Broker spielt für die Lizenzierung keine Rolle. Ein Angebot erhalten Sie auf Anfrage.

Angebot anfragen

Umfang: Ein Projekt oder Programm mit allen zugehörigen Kafka-Clustern: Produktion, Integration, Test und Recovery.
Abrechnung: Pro Projekt und Jahr, unabhängig von der Anzahl der Broker.
Betrieb: Betrieb in Ihrem AWS-Account. Support für Einrichtung, Recovery-Tests und Störungen ist in der Lizenz enthalten.
Preis: Auf Anfrage. Beschreiben Sie uns Ihre Kafka-Landschaft und wir erstellen ein Angebot.

06 / Gut zu wissen

Häufige Fragen

Können wir Kafka in unseren Recovery-Test einbeziehen?

Ja. Stellen Sie Topics, Consumer-Offsets und Schema Registry zum gewählten Zeitpunkt in einem bestehenden oder neuen Cluster wieder her. Die Consumer-Gruppen setzen die Verarbeitung an den zugehörigen Offsets fort. Ein Bericht dokumentiert das Ergebnis, das Zeitfenster, die Nachrichten und die Consumer-Gruppen für Ihr Testprotokoll. Erproben Sie den Ablauf zunächst in einem isolierten Testcluster.

Wie erhalten wir realistische Testdaten, ohne die Produktion zu belasten?

Klonen Sie Daten aus einem gewählten Zeitfenster des Backups in Ihren Testcluster. streamkeepr passt Topic- und Gruppennamen, Schema-IDs und die Verteilung auf die Zielpartitionen an. Der Klon liest ausschließlich aus dem Backup und benötigt keine Zugangsdaten zur Produktionsumgebung.

Lesen unsere Consumer nach einem Restore am richtigen Offset weiter?

Die Offsets Ihrer Consumer-Gruppen sind Teil des Backups. streamkeepr ordnet die zum gewählten Zeitpunkt gesicherten Offsets den wiederhergestellten Topics zu. Sie prüfen den Plan und wenden ihn auf gestoppte Consumer-Gruppen an. Bei Bedarf können Sie die Offset-Änderungen zurücknehmen. Offsets, die Ihre Services außerhalb von Kafka speichern, passen Sie selbst an.

Was kommt im Betrieb auf unser Team zu?

Das kontinuierliche Backup läuft als Helm-Release in Ihrem EKS-Cluster. Jeder Restore ist ein separater Kubernetes-Job, der bei Bedarf startet und nach Abschluss endet. Metriken, Dashboards und Alarmregeln binden Sie in Ihre bestehende Prometheus- und Grafana-Umgebung ein. Support ist in der Lizenz enthalten.

Verlassen unsere Kafka-Daten den AWS-Account?

Nein. streamkeepr läuft in Ihrem EKS-Cluster und greift auf Ihre Kafka-Cluster, Ihren S3-Bucket und Ihre Schema Registry zu. Ihre Backups bleiben in Ihrem Account und liegen in einem dokumentierten Format vor. Es gibt keinen von uns gehosteten Dienst, keine Telemetrie und keinen Lizenzserver.

Können wir die Recovery vor dem Ernstfall testen?

Ja. Verwenden Sie dieselbe Restore-Definition wie im Ernstfall und wählen Sie einen isolierten Testcluster als Ziel. Der Bericht dokumentiert das Ergebnis Ihres Recovery-Tests.

Warum reicht Replikation als Backup nicht aus?

Replikation schützt vor dem Ausfall einzelner Broker. Sie überträgt aber auch fehlerhafte Schreibvorgänge und Löschungen auf die Replikate. Retention begrenzt zusätzlich, wie lange Daten verfügbar bleiben. Ein separates Backup ermöglicht es, nach einem fehlerhaften Release oder dem Verlust eines Clusters zu einem früheren Datenstand zurückzukehren.

Wie wird streamkeepr lizenziert?

Sie erhalten eine Jahreslizenz pro Projekt oder Programm. Sie umfasst alle zugehörigen Kafka-Cluster und Umgebungen sowie Support, unabhängig von der Anzahl der Broker. Für ein Angebot benötigen wir eine kurze Beschreibung Ihrer Kafka-Landschaft.

Demo und Beratung

Sehen Sie streamkeepr im Einsatz

In der Demo zeigen wir das Backup, einen Point-in-Time-Restore einschließlich Consumer-Offsets und das Klonen von Produktionsdaten in einen Testcluster. Beschreiben Sie uns Ihre Kafka-Landschaft und Ihre Anforderungen. Wir stimmen die Demo auf Ihre Fragen ab, erstellen ein Angebot oder begleiten einen Recovery-Test in Ihrer Umgebung.

Das benötigen Sie

Kafka: Apache Kafka oder Amazon MSK mit SASL/SCRAM
Kubernetes: Amazon EKS mit Helm
Speicher: S3-Bucket und KMS-Schlüssel in Ihrem AWS-Account
Schemas: Confluent-kompatible Schema Registry (optional)