Why SVA, a top Confluent partner, chose Kannika for Kafka backup

SVA, a 3,800-person German system integrator and one of the largest Confluent partners in EMEA (named Confluent Enablement Partner of the Year), partnered with Kannika for Kafka backup and recovery. Their lead architect explains why replication isn't backup and what teams get wrong about compliance.

"Replication is not a backup" is a line we have written on this blog more times than we care to admit. So rather than say it again, we asked someone who has to make Kafka recoverable in real production environments what that actually takes, and why SVA added Kannika to a partner list it keeps short.

‍

Why isn't Kafka replication a backup?

This is the misconception Axel sees most. A team notices that Kafka keeps several copies of every partition and decides the data is safe. Replication handles fault tolerance, he explains, but it does nothing for accidental topic deletion or data corruption. "Kafka data is immutable. Deleted is deleted." If someone drops the wrong topic, or a service produces garbage for six hours before anyone notices, replication copies the mistake to every replica.

Axel learned this early. A colleague was asking him about Kafka and eventually brought up backup. He started to say replication does this and that, "and then I realized: wait, no. That's high availability. That's fault tolerance. It is not a backup."

‍

What does a Kafka disaster recovery strategy require?

The recovery copy has to live outside Kafka. Sometimes you can reload from an upstream system like a database, Axel says. But in many cases Kafka is the single source of truth, and then you need external storage, an S3 bucket or another object store, where the data is parked and can be re-imported later.

That single source of truth case is where teams underestimate their risk. Axel gives an automotive example. Sensor data goes straight into Kafka, often through an MQTT broker, with no buffer in the sensor. "If that data is gone in Kafka, the sensor will not send it again. You cannot reproduce it." The same goes for microservice events that exist nowhere else. Lose them, and there is no second database to fall back on.

Getting data out of Kafka is the easy part. There are plenty of Kafka Connect sink connectors. Getting it back in cleanly, to the right offsets and the right point in time, is where most setups have nothing.

‍

Where do existing Kafka backup tools fall short?

The tools that exist are built for one narrow case and break when reality changes. A connector writes to AWS S3, then a customer has an S3-compatible store instead, and it crashes. Even when you can export the data, there is usually no way to import it back, and no point-in-time recovery. So teams build their own backup tooling and end up maintaining it themselves, when they should be focused on the real-time use cases.

That gap is why SVA looked for a partner, and Axel is clear about why Kannika fit. For SVA it is the missing piece in a lot of Kafka architectures. It supports different storage systems, so there is no lock-in to one object store. It handles recovery, including point-in-time recovery. It has a usable UI, a GitOps approach, and CI/CD pipelines because it runs on Kubernetes. "And it is easy enough to explain that customers understand the value immediately. That is what made the partnership an obvious choice for us." SVA keeps its partner list short, so that endorsement carries weight.

Kannika is also not SaaS-only. SVA can deploy it inside a client's own Kubernetes environment with no external connection. Some customers are happy with a managed service, Axel says, but plenty of German organizations want it on premises, run by their own team. "It is good that both options exist."

One more thing he values: because Kannika moves data in and out reliably, the same tool covers jobs that used to need separate ones. You can pull production data into test and mask it on the way, or migrate between clusters and between on premises and cloud. "So it can actually shrink your tech stack, because you no longer need a separate replicator next to your backup tool."

‍

How do DORA and NIS2 apply to Kafka backup?

For regulated clients, backup is becoming something you have to prove. SVA has a team focused on financial regulation, and the questions come from both sides. Despite the pressure from DORA and NIS2, Axel says, Kafka backup is still a blind spot for many organizations, even in regulated sectors. He keeps finding two data center setups with no real backup in place. And compliance is about more than having a backup. "You need auditability, you need to prove it, and increasingly you need to prove you have tested it."

Several regulations no longer accept a recovery plan as a PDF on a shared drive. They want repeated recovery tests with measurable results. Kannika maps onto this with built-in audit logs and the ability to mask sensitive data when production data moves into lower environments.

‍

One piece of advice for Kafka architects

We closed with the question Axel thinks teams should ask first:

"If your most important topic disappeared right now, could you get it back, correctly, at 2 a.m. after an alert?"

A disaster will not happen when you have planned for it. It will happen at 2 a.m., under bad conditions, when you do not want it to. So be confident your recovery process works, because that is when you will have to run it.

It is a simple test for any platform team. For a lot of Kafka setups, the honest answer is no.

Protect the Kafka data you cannot afford to lose. Kannika gives you real backup, point-in-time recovery, and flexible storage for Apache Kafka, on premises or in the cloud. Request a demo or start a free trial to see what recovery looks like before you need it at 2 a.m.