Kannika is a backup and restore platform for Apache Kafka. It backs topics and their schemas up to storage outside your cluster and restores them to a specific point in time, offset or timestamp. It also does environment cloning and cluster migration.
I've known the Kannika team for a couple of years. I read the material they were publishing, shared parts of it in talks, and it turned out some of their customers were already using EventCatalog and mentioning us to each other. As of today it's a partnership.
How Kannika complements EventCatalog
EventCatalog gets adopted when an architecture outgrows the person who used to hold it all in their head. What events do we have? Who's producing what? Who consumes this one? What breaks if I change this schema? At ten events you're fine. At a hundred you're not, and someone goes looking for a tool.
A different question arrives at the same moment, from the same growth:
Can we get this data back?
If a topic gets dropped or a retention policy gets set wrong, your catalog shows you the blast radius: every consumer that just lost its input, who owns each of them. Then you need the data.
That is what Kannika is built for. Kannika Armory backs Kafka topics and their schemas up to storage that sits outside the cluster, then restores them to a chosen point in time, offset or timestamp, one topic or the whole estate. The same mechanism handles environment cloning and migration between clusters, so the tool earns its keep on ordinary Tuesdays rather than only during incidents.
EventCatalog answers- What events do we have?
- Who's producing what?
- Who consumes this one?
- What breaks if I change this schema?
Kannika answers- Can we get this data back?
- Can we restore to before the bad deploy?
- Can we clone this environment?
- Can we move to a new cluster?
It works the other way too. A backup of a system nobody has mapped is a restore nobody knows how to sequence. Which topics matter, which consumers need replaying, in what order, from which offset. That part is catalog work.
Where replication ends and backup starts
Spend any length of time with the Kannika team and the conversation finds its way to the difference between replication and backup. It's the misconception they run into most, and by now they have the argument down to a fine art. It's worth reading in full, but here's the short version.
Nobody sits down and decides that replication is their backup strategy. You set a replication factor because the docs tell you to. You stand up a second cluster because somebody asked what happens if the region goes down. The risk starts to feel handled, and the backup question never gets asked, because the slot it would have gone in already has something in it.
A replica's job is to match the leader as closely as it can, and it has no opinion about whether what it's matching is correct. Delete the wrong topic and every replica agrees the topic should be gone. Ship a producer bug at nine and by lunchtime the corruption is consistent across all three copies. Let retention lapse and the data expires everywhere at once, on schedule, exactly as designed.
| What goes wrong | Replication | Backup |
|---|---|---|
| A broker or data centre goes down | ||
| Someone deletes the wrong topic | ||
| A producer bug corrupts messages | ||
| A retention policy expires data | ||
| Go back to a chosen point in time |
A backup covers the other half, and it does it by being two things a replica isn't. It lives outside the cluster, so nothing that happens inside can propagate into it. And it holds each topic as it stood at a chosen moment rather than only as it stands now. That combination is what lets you go back to five to nine, before the bad deploy, and carry on from there.
Why this partnership
Ask anyone building event-driven systems what tooling they use and you get a version of the same answer. A homegrown developer portal. An internal governance thing somebody built two years ago. A script that pushes topics to S3 that nobody has ever restored from. Smart teams solving identical problems in isolation.
Event-driven architecture is five or ten years behind the REST and database world on this. Not in capability, in maturity. Backing up Postgres is boring because specialists made it boring, and nobody writes their own API documentation format because OpenAPI exists. EDA gets there the same way: people going deep on their piece instead of everyone covering everything. My piece is documentation and governance. Kannika's is data protection.
Agents make both halves more urgent. Documenting your architecture used to be a favour to the next human; now it's context an agent can act on, which is why EventCatalog ships an MCP server. But agents won't stop at reading. They'll change retention settings, topic configuration and schemas faster than any review process catches everything.
Good context means fewer bad changes. Being able to rewind covers the rest.
Get started
If you're documenting an event-driven architecture, start with EventCatalog. If that side is handled and you're now wondering whether you could restore a critical topic, go and look at what Kannika do. They have a sandbox you can try.
Document your architectureMap your events, owners, producers and consumers with EventCatalog.Get started with EventCatalogProtect your Kafka dataWondering whether you could restore a critical topic? Try Kannika in their sandbox.Try the Kannika sandboxFrequently asked questions
Does EventCatalog back up my Kafka data?
No. EventCatalog holds documentation, schemas, ownership and relationships, never your event payloads. If you need the data itself to be recoverable, that's a different tool.
Is Kafka replication a backup?
No. Replication copies data faithfully, mistakes included. It protects against broker or data centre failure, not against deletion, corruption or expired retention, because those propagate to every replica.
Does Kafka have a built-in backup feature?
Not really. Most teams build something with Kafka Connect and an object storage sink. That gets the data out. The restore path is usually where it falls apart.
Is there an integration between EventCatalog and Kannika?
Not today. This is a partnership between the two teams rather than a shipped feature. If an integration would be useful to you, say so in Discord.
Questions about the partnership? Reach out at hello@eventcatalog.dev or find us on Discord.