Replication-first DR, not Kafka backup

What Zerto does well — and at what layer​

A zerto kafka backup search usually comes from a team that already runs Zerto for VM disaster recovery. The short answer: Zerto replicates the machines Kafka runs on. It does not back up the data Kafka holds.

Zerto's continuous data protection is genuinely strong. A filter driver mirrors write I/O from VMware vSphere and Microsoft Hyper-V VMs as it happens, instead of taking periodic snapshots. Checkpoints land in a journal every few seconds. Virtual Protection Groups recover multi-VM applications to one consistent checkpoint, and failover, failover tests, and migrations are orchestrated workflows. Zerto 10 added real-time detection of encryption anomalies and a Cyber Resilience Vault for isolated recovery.

Zerto for Kubernetes brings the same journal-based replication to persistent volumes and Kubernetes objects, grouped into application consistency groups. That covers Kafka broker volumes on Kubernetes — at the block level, like every other volume.

OSO Kafka Backup works at the data layer instead. It connects to any Kafka cluster as a standard client and writes topic records, consumer group offsets, and topic configuration to object storage (S3, Azure Blob, GCS) or local disk. Restores are offset-consistent, work across clusters, and stop at a precise millisecond — the failure modes covered in the disaster recovery use cases.

Zerto Kafka backup: what the journal covers and what it cannot​

Zerto's journal does give point-in-time recovery — within its window and at its layer. Every checkpoint is block-level VM or volume state, kept for a configurable one hour to thirty days. Rewinding a broker VM to a checkpoint rewinds every topic, every partition, and every consumer offset on that machine together.

That scope is the problem for Kafka data. A poison message discovered after the journal window has rolled past is unrecoverable. A single corrupted topic cannot be restored without dragging the whole broker back in time. And replication is faithful by design: a bad deploy that writes garbage, or an accidental topic deletion, replicates to the recovery site in seconds. The replication-is-not-backup distinction applies to continuous replication exactly as it does to MirrorMaker.

Offsets make the gap concrete. Zerto preserves whatever offsets happened to be on disk at a checkpoint — a physical copy, consistent for that one VM. OSO Kafka Backup stores original offsets with each record and restores consumer group positions alongside the data, so applications resume where they left off, on any target cluster.

The structural gap is managed Kafka. Amazon MSK, Confluent Cloud, and Aiven expose no VMs, hypervisors, or volumes to replicate. Zerto has nothing to attach to. A client-level backup tool works against all of them.

When to choose which​

Choose Zerto when the job is infrastructure survival: whole-site failover with seconds of data loss, orchestrated recovery of multi-VM applications, DR testing without downtime, and ransomware detection at replication time.

Choose OSO Kafka Backup when the job is Kafka data: offset-consistent topic backups, millisecond point-in-time restore months after the fact, single-topic recovery, and coverage for managed services Zerto cannot reach. The RTO and RPO planning guide shows how the two objectives differ by failure mode.

Run both when Kafka matters to the business. Zerto fails the site over; OSO Kafka Backup restores logically consistent topic data at any point in its retention. The same layer split appears in the Veeam comparison and the Cohesity comparison — Zerto simply holds the strongest replication story of the three.