OSO Engineering

Kafka backup means copying topic data, consumer group offsets, and cluster metadata to independent storage — object storage or a filesystem — so you can restore it after an incident. Replication alone cannot do this: it faithfully copies deletions and corrupt records to every replica in real time. A complete Kafka backup strategy combines replication for hardware resilience with periodic or continuous backups for protection against logical errors, regional outages, and compliance obligations.

You cannot undo a deleted Kafka topic unless you have a backup. To backup a Kafka topic, you capture its records, partition layout, and offsets to durable storage outside the cluster; to restore, you produce that data back into the same or a different cluster. This guide walks through three ways to do it — from a purpose-built CLI to a bare consumer script — and how to verify the result actually restores. For the delete command itself, see how to delete a Kafka topic.

Kafka backup best practices come down to one principle: a backup you have not restored is a hope, not a backup. Retention deletes your data on schedule, replication copies your mistakes in real time, and neither can return a topic to the state it was in before an incident. These 10 rules turn Kafka backups from a checkbox into something you can bet an on-call shift on.

Kafka geo replication copies topics between clusters in different regions or datacenters, so a regional outage does not take your streaming platform with it. In-cluster replication (RF=3) protects against broker loss inside one failure domain; geo replication protects against losing the domain itself. This guide compares the four patterns, shows what MirrorMaker 2 setup looks like over a WAN, and covers the failure mode replication cannot solve.

Kafka replication across data centers comes down to one architectural decision: run a single stretched cluster spanning your datacenters, or run independent clusters connected by asynchronous replication. Stretched clusters give you zero data loss but demand low-latency links. Separate clusters tolerate WAN conditions but accept a non-zero recovery point. This guide covers both designs, when each wins, and how to build the second one with MirrorMaker 2.