Scalytics · Kafka Backup & Disaster Recovery

Kafka backup that survives the bad day. For Confluent, MSK and Redpanda.

Stop paying a storage tax for disaster recovery. Lascaris continuously copies your topics from Confluent, Apache Kafka, Redpanda or MSK into a locked backup on S3. Any Kafka source. Open core under Apache 2.0. Your production cluster stays untouched, and your retention becomes infinite for the price of object storage. We run it for you in your own cloud, or you run it yourself, on-prem or air-gapped.

▸ Book a briefing ▸ Get the one-pager

live backup · prod → Lascaris

streaming

production

CONFLUENT

untouched · real-time SLA

any kafka source-agnostic

lascaris

live sync

kafka · ordered · regex map

112 ms replication lag

locked backup

Lascaris backup

stateless brokers · segments to S3

412,803 segments

S3 · object lock · immutable 11 nines durability

Events secured

84,217,000

Retention

infinite

Open core

Apache 2.0

Kafka backup, disaster recovery, point-in-time restore

Kafka backup that survives the bad day.

Immutable. Point-in-time recoverable. Apache 2.0 on both ends. Production stays untouched. Insurance costs a fraction of a second cluster.

Talk with an Expert Get the one-pager

In plain terms

What is Lascaris backup?

What it is

Kafka backup and disaster recovery on S3. It continuously mirrors your topics into a locked, immutable copy on object storage.

Who it is for

Platform and compliance teams running Confluent, Apache Kafka, Redpanda, or MSK that need recoverable, off-vendor protection for the log.

The problem it solves

Hot replication mirrors your mistakes. A delete, a ransomware write, or a retention change propagates straight to the standby. Lascaris keeps a locked copy that production credentials cannot reach.

What it connects to

Any Kafka-protocol source (Confluent, Apache Kafka, Redpanda, MSK) writing immutable segments to S3 under object lock.

Why it is different

Open core under Apache 2.0, source-agnostic, production untouched. Retention measured in years for the price of object storage, and the same stack also serves SI agent replay workloads. Managed by Scalytics in your own cloud, or self-run on-prem or air-gapped.

If you can delete prod with one command, your DR cluster deletes with it.

Cluster Linking, MirrorMaker 2, and MSK Replicator are excellent at one thing: keeping a hot standby in sync with production. None of them protect against a misfired `kafka-topics --delete`, a ransomware attack that walks through the producer credentials, or a retention misconfiguration that drops three weeks of audit data overnight. The deletion replicates. The corruption replicates. The compromised credentials replicate. A Kafka backup and disaster recovery strategy needs something replication cannot provide: an immutable, time-indexed, off-vendor copy of the log living on a parallel recovery stack.

Check your Kafka against DORA and NIS2

The three failure modes

Where hot replication quietly fails you.

Every production Kafka incident postmortem we have read in the last two years sits in one of three buckets. None of them are solved by the standby cluster you already pay for. They are solved by an immutable, time-indexed copy of the log that lives outside the production blast radius.

01 · Operator error

The accidental delete propagates.

An engineer runs `kafka-topics --delete` against production thinking it is staging. A `terraform apply` removes 14 topics. MirrorMaker 2 and Cluster Linking do exactly what they were configured to do: mirror the deletion to the DR cluster. Now you have two copies of nothing. KIP-382 itself notes MirrorMaker is "insufficient for many use cases, including backup, disaster recovery, and fail-over scenarios."

02 · Ransomware in the stream

Credentials get compromised.

A producer key leaks. An attacker writes malformed events into a payments topic, or worse, deletes consumer offsets and resets retention to one hour. The standby mirrors the writes. Replication is not isolation. The only defense is a copy that the production credentials cannot reach, stored under different keys, under retention rules production cannot modify.

03 · No rewind

Replication shows current state. DR holds the history.

A bug ships at 09:14 and corrupts events for 47 minutes. You need the 09:13 events to inspect, replay, or rebuild downstream state without touching production. The hot standby is also corrupted, but the DR stack on S3 holds those segments immutably under object lock, indexed by commit time and replayable via standard Kafka.

Not sure your standby already covers you? Read Kafka backup vs replication.

The architecture

Production untouched. Disaster recovery at S3 prices.

Lascaris is built from open-source parts Scalytics already maintains. A fast replicator copies your topics live, with a dashboard, SI anomaly detection and built-in compliance reports. A stateless, Kafka-compatible stack writes immutable segments to S3. Together they give you a parallel recovery stack. No second production-sized cluster. No vendor lock-in. No doubled storage bill.

production · untouched

Source cluster

confluent / apache
msk / redpanda
real-time SLA preserved

→

lascaris · live sync

Replication engine

order and keys preserved
same-name or regex mapping
dashboard · si anomalies · audit

→

locked backup + s3 object lock

Locked backup

stateless brokers · etcd metadata
immutable segments
11 nines durability

Today, the DR stack gives you a durable, immutable copy of every mirrored topic with retention measured in years on S3 economics. Standard Kafka consumers read it through the normal wire protocol. Replay, batch reprocessing, agent workloads, and failover drills all run against the stack without touching production. Topic-level recovery runs on the DR side. Restore a mirrored topic as of a chosen time into a new topic for controlled validation and cutover: kafscale-cli restore --topic orders --target-topic orders-restored --to 2026-05-13T14:23:00Z. The restored topic is a new artifact on the stack, not a rollback of the source cluster. The target topic must be new, and offsets are preserved inside it. The safe pattern is restore, validate, then cut consumers over deliberately.

Three sources · one locked backup

Connect any Kafka. Same schema for every source.

Lascaris reads its base configuration from configs/default.yml and stores runtime job state in SQLite. The schema is identical for every Kafka-protocol source. What changes between Confluent, Apache, and Redpanda is the provider, the bootstrap address and the SASL mechanism. The target points at the Lascaris backup endpoint with idempotent writes switched off, because the backup stack does not implement InitProducerId. Set disable_idempotent_writes: true on the target, or start the process with KAFMIRROR_DISABLE_IDEMPOTENT_WRITES=true. Clusters and jobs are then created interactively with mirror-cli, or via the REST API. The schema below comes from the open-source repository.

Confluent Cloud → Lascaris backup

PLAIN SASL · API key auth · TLS required

configs/default.yml

# kaf-mirror · Confluent Cloud → Lascaris backup
# Confluent issues API keys over SASL/PLAIN.
# Production traffic on Confluent is unaffected.
 
clusters:
  confluent-prod:
    provider: "confluent"
    brokers: "pkc-xxxxx.eu-west-1.aws.confluent.cloud:9092"
    security:
      enabled: true
      protocol: "SASL_SSL"
      sasl_mechanism: "PLAIN"
      api_key: "<cc-api-key>"
      api_secret: "<cc-api-secret>"
 
  lascaris-backup:
    brokers: "kafscale-proxy.bdr.svc.cluster.local:9092"
    disable_idempotent_writes: true   # required for the backup target
    security:
      enabled: true
      sasl_mechanism: "SCRAM-SHA-256"
      username: "<backup-user>"
      password: "<backup-pass>"
 
replication:
  batch_size: 1000
  parallelism: 4
  compression: "zstd"

create the replication job

# Every step is interactive. mirror-cli prompts for the details.
./mirror-cli login admin --password <password>
./mirror-cli clusters add      # source: confluent-prod
./mirror-cli clusters add      # target: lascaris-backup
./mirror-cli jobs add          # pick source, target, topics: orders.*, payments.*, audit.*
./mirror-cli jobs start
./mirror-cli jobs status full

Apache Kafka (self-managed) → Lascaris backup

SASL/SCRAM-SHA-512 · TLS · on-prem or self-hosted

configs/default.yml

# kaf-mirror · Apache Kafka → Lascaris backup
# Self-managed Apache Kafka with SCRAM-SHA-512 over TLS.
 
clusters:
  prod-apache-kafka:
    brokers: "kafka-prod-1.internal:9093,kafka-prod-2.internal:9093,kafka-prod-3.internal:9093"
    security:
      enabled: true
      protocol: "SASL_SSL"
      sasl_mechanism: "SCRAM-SHA-512"
      username: "<kafka-user>"
      password: "<kafka-pass>"
 
  lascaris-backup:
    brokers: "kafscale-proxy.bdr.svc.cluster.local:9092"
    disable_idempotent_writes: true   # required for the backup target
    security:
      enabled: true
      sasl_mechanism: "SCRAM-SHA-256"
      username: "<backup-user>"
      password: "<backup-pass>"
 
replication:
  batch_size: 1000
  parallelism: 4
  compression: "zstd"

create the replication job

./mirror-cli login admin --password <password>
./mirror-cli clusters add      # source: prod-apache-kafka
./mirror-cli clusters add      # target: lascaris-backup
./mirror-cli jobs add          # topics, batch size, parallelism, compression
./mirror-cli jobs start
 
# Inspect job state at any time
./mirror-cli jobs status full

Redpanda → Lascaris backup (regex namespace)

SCRAM-SHA-256 · regex topic mapping

configs/default.yml

# kaf-mirror · Redpanda → Lascaris backup
# Redpanda speaks the Kafka wire protocol natively.
# Mapped topics are namespaced under bdr.* on the target.
 
clusters:
  redpanda-prod:
    provider: "redpanda"
    brokers: "seed-0.redpanda-prod.internal:9092,seed-1.redpanda-prod.internal:9092,seed-2.redpanda-prod.internal:9092"
    security:
      enabled: true
      protocol: "SASL_SSL"
      sasl_mechanism: "SCRAM-SHA-256"
      username: "<rp-user>"
      password: "<rp-pass>"
 
  lascaris-backup:
    brokers: "kafscale-proxy.bdr.svc.cluster.local:9092"
    disable_idempotent_writes: true   # required for the backup target
    security:
      enabled: true
      sasl_mechanism: "SCRAM-SHA-256"
      username: "<backup-user>"
      password: "<backup-pass>"
 
replication:
  batch_size: 1000
  parallelism: 4
  compression: "zstd"

create the replication job (regex mapping)

./mirror-cli login admin --password <password>
./mirror-cli clusters add      # source: redpanda-prod
./mirror-cli clusters add      # target: lascaris-backup
./mirror-cli jobs add          # topics: events.*, then choose regex target mapping
                               # pattern: events\.(.*)   target: bdr.events.$1
./mirror-cli jobs start
./mirror-cli jobs status full
 
# events.orders   on Redpanda
# bdr.events.orders   on the backup

Cost reality · planning estimate

Disaster recovery insurance for the cost of an S3 bucket.

Reference workload: 3 TB per day ingest, 30-day retention (90 TB), one mid-size mirrored estate. Storage and replication line items only. Networking egress and support contracts excluded. Source: vendor public pricing and AWS public pricing as of April 2026. The point is the ratio, not the exact dollar figure. Your numbers will move with throughput and region, but the column ordering does not.

Approach	Storage cost / month	DR-stack recovery	Source lock-in	License
Confluent Cluster Linking (Enterprise → Enterprise)	~$38,000 (doubles primary)	Hot standby only	Confluent both ends	Proprietary
MSK Replicator (cross-region)	~$22,500 + cross-region transfer	Hot standby only	MSK both ends	Proprietary
Redpanda Shadowing + WCR	~$18,000 (Enterprise license required)	Whole-cluster only	Redpanda source	Source available, Enterprise paywall
MirrorMaker 2 → second open Kafka cluster	~$12,000 (second cluster + ops)	Hot standby only	None, but offset drift	Apache 2.0
Lascaris locked backup on S3 (this page)	~$2,100 (90 TB at $0.023/GB)	Immutable stack with point-in-time topic restore	None, any Kafka source	Open core, Apache 2.0

▸ Confluent figures derived from published eCKU pricing and the cluster-linking line item.
▸ MSK figures from the AWS MSK pricing page, kafka.m5.large × 3 brokers, 30-day retention.
▸ S3 storage at $0.023 per GB-month (us-east-1). API charges trivial at this scale.
▸ Compute for Lascaris is a small Kubernetes deployment, typically under $300 per month.

Two outcomes · one deployment

Backup today. Agent stack tomorrow.

The same Lascaris deployment you run for backup and disaster recovery is what SI agent workloads actually need. Production Kafka serves real-time SLAs in single-digit milliseconds. Agents need months of history, replayable decision logs, and long-retention prompt traces. Those two access patterns cannot share a cluster without one starving the other. So the backup copy already solves the second problem: it is durable, queryable, isolated from production, and built for retention measured in years instead of hours. One Kubernetes deployment. One S3 bucket. Two strategic capabilities.

use case · backup

Disaster recovery and compliance.

The reason this pattern gets budget approval. Immutable S3 segments on a parallel recovery stack, DORA Article 12 and NIS2 Annex II evidence packs from the same dashboard, audit trail across every state-modifying action. Production stays untouched. The backup has no shared credentials with production.

Immutable segments under S3 object lock
Replay through the standard Kafka protocol
Compliance reports daily, weekly, monthly
Topic-level recovery as-of time: roadmap

shared infrastructure

Same operator. Same bucket. Same credentials boundary.

Both outcomes deploy on the same Kubernetes operator, write to the same S3 bucket under different prefixes, and run under the same separation-of-duties model. No second platform team. No second procurement cycle. The backup investment buys the agent platform at zero marginal infrastructure cost.

One Lascaris operator on Kubernetes
One S3 bucket, prefix-namespaced workloads
One etcd ensemble for metadata
One audit trail across both use cases

use case · SI agents

Replay, retention, reasoning over history.

Agent workloads cannot run on the same brokers that serve real-time. Replay over months of history burns broker disk, fights production retention policies, and exposes the cluster to slow-consumer failure modes. Lascaris segments live in S3 and are read directly by agents, processors, and replay tools, bypassing brokers entirely. The same data that protects you also powers the experimentation.

Decision logs, tool calls, prompt history
Replay any agent run from any point
Years of retention on S3 economics
Zero broker contention with production

Why this matters now. Most platform teams are being asked to support SI agent workloads on infrastructure designed for real-time streaming. Putting agent replay traffic on a Confluent or Apache cluster that also serves sub-10ms production paths is how you get on-call pages at 2 AM. The Lascaris backup is already isolated, already durable, already on S3. Pointing agent workloads at it requires no new procurement and no new architecture review. See the Lascaris agent runtime that runs on top of this stack.

Honest comparison · May 2026

Where this pattern fits, and where others fit better.

The Kafka backup market is small but real, and every option has a niche where it is the right answer. Kannika Armory is the most direct comparison: a mature, purpose-built commercial product with strong DORA and NIS2 positioning. OSO kafka-backup is the closest open-source equivalent, although it is a CLI tool rather than a platform. The hyperscaler-native and Kafka-vendor-native options each work well when you are already committed to the matching ecosystem. The table below is what an honest procurement evaluation looks like.

Solution	License	Point-in-time recovery	Source flexibility	Compliance UI	Doubles as agent platform	Best for
Kannika Armorycommercial · EU	Commercial	Yes, native	Confluent, Apache Kafka	Yes, mature	No	Regulated EU teams who want a single-purpose, sales-supported backup product and accept closed-source.
OSO kafka-backupMIT · Rust CLI	MIT	Yes, ms precision	Any Kafka	No, CLI only	No	Single-team backups, manual runbooks, no compliance reporting requirement.
Confluent Cluster Linkingproprietary	Proprietary	No, replication only	Confluent both ends	Confluent Console	No	Confluent-to-Confluent active-passive failover for the existing customer base.
MSK Replicatorproprietary	Proprietary	No, replication only	MSK both ends	AWS Console	No	Single-AWS-account, same-region or cross-region MSK replication.
MirrorMaker 2Apache 2.0	Apache 2.0	No, KIP-382 acknowledges this	Any Kafka	No	No	Migration, geo-replication, and hot-standby where offset drift is acceptable.
Redpanda Shadowing + WCRBSL + Enterprise	BSL with Enterprise paywall	Whole-cluster only	Redpanda source	Redpanda Console	No	Redpanda-native teams already on Enterprise tier.
Lenses Stream Reactor S3Apache 2.0 connector	Apache 2.0	No, batch sink	Any Kafka via Connect	No	No	Teams already operating a Kafka Connect cluster who want raw archive to S3.
Scalytics LascarisOpen core, Apache 2.0	Open core, Apache 2.0	Topic recovery in the DR environment	Any Kafka wire protocol	Yes, with SI anomalies	Yes, same infrastructure	Teams who want an open core, backup from any Kafka source on a parallel stack, and one deployment that also serves SI agent workloads.

▸ Kannika Armory ships a polished commercial product with strong DORA and NIS2 framing. Where Scalytics differs: an open core under Apache 2.0, source-available before procurement, and the backup target is also the agent platform.
▸ OSO kafka-backup is the closest open-source equivalent on the backup side and is excellent at its scope. Where Scalytics differs: live mirror instead of batch, web dashboard, compliance reports, and an integrated streaming target.
▸ MirrorMaker 2 is the right tool for replication. KIP-382 itself states it is insufficient for backup and disaster recovery.
▸ Cluster Linking, MSK Replicator, Redpanda Shadowing are vendor-native and require the matching vendor on both ends.
▸ DR-stack recovery model. The Lascaris backup is a parallel recovery stack, not an in-place rollback of the primary. DR-stack recovery model. The Lascaris backup is a parallel recovery stack, not an in-place rollback of the primary. Topic-level recovery into a new topic is available today with kafscale-cli restore.
Information current as of May 2026. Vendor product pages reviewed, public pricing referenced where available.

DORA · NIS2 · ISO 27001

Evidence regulators ask for. Built into the stack, mapped to your control set.

DORA Article 12 requires financial entities to maintain immutable backups with rigorously tested recovery procedures. NIS2 Annex II requires comparable controls for essential and important entities. Both frameworks require evidence: the audit trail, the retention proof, the recovery test. Lascaris generates compliance reports daily, weekly or monthly with full audit trails, and stores the actual log segments in S3 under object lock. The combination produces regulator-grade evidence without a separate audit pipeline.

DORA · Article 12

Backup and restoration of ICT systems

Article 12(1) · Immutable backupsS3 Object Lock in compliance mode prevents deletion and modification regardless of credentials. Retention rules enforced at the bucket policy layer.
Article 12(2) · Restoration procedurePer-topic point-in-time restore via documented kafscale-cli restore command. Reproducible. Tested via the Lascaris compliance scheduler.
Article 12(3) · SegregationThe backup runs on separate credentials, separate keys, separate cluster, separate bucket. Production credentials cannot reach backup storage.
Article 12(4) · TestingThe Lascaris Compliance tab generates monthly restore-test reports with timestamps and recovered offsets.

NIS2 · Annex II

Cybersecurity risk-management measures

Annex II(1)(d) · Business continuityAir-gappable backup in a separate availability zone, region, or on-premises cluster. Lascaris runs without internet egress.
Annex II(1)(e) · Supply chain securityThe Lascaris core is open source under Apache 2.0, source available, no proprietary control plane that can revoke access or change pricing.
24-hour incident notificationLascaris anomaly detection surfaces replication lag spikes, schema drift, and credential failures as alertable signals before they become incidents.
Audit trailRole-based access (admin/operator/monitor/compliance). Every state-modifying action is logged with actor, timestamp, and outcome.

Architecture commitments

Red lines, in plain text.

A buyer running backup for a regulated process reads architectural commitments more carefully than they read marketing claims. Each line below is enforced in the build pipeline, documented in the source, and visible at the protocol layer.

Production traffic is never affected. Lascaris reads via a read-only credential. The writer to the backup is a separate process. Production brokers see one more consumer, nothing else.
The backup is reachable only from Lascaris. Network policies, distinct credentials, distinct encryption keys, distinct S3 bucket. A compromised producer key on prod cannot reach the backup copy.
S3 segments are immutable under object lock. Compliance mode prevents deletion until the retention clock expires. Not even the bucket owner can override.
DR-stack recovery is additive, not destructive. Topic-level recovery as-of a chosen time restores into a new topic or namespace on the stack. It does not roll back the source cluster, which is by design.
The segment format is part of the public specification. If Lascaris ever disappears, the segments in your bucket remain readable by any conformant reader.
No vendor control plane. Lascaris runs on your Kubernetes, your S3, your network. There is no external service to revoke access or rate-limit operations.
The core license is Apache 2.0. No BSL conversion clauses, no per-GiB usage fees, no commercial-use restrictions. Now and after a hypothetical acquisition.

Honest limits

What this pattern is not.

The same architectural choices that make this backup pattern cheap also make it the wrong choice for a small set of workloads. We name them here because the cost of finding out after deployment is high.

not this

Sub-10ms latency failover

For synchronous trading or fraud-detection paths that require RPO=0 and millisecond failover, run a stretch cluster with synchronous replication across availability zones. Lascaris write latency is 200 to 500ms because writes commit to S3 before acknowledgement.

not this

In-place rollback of production

Backup and recovery is additive: restore puts a mirrored topic into a new topic, which you validate and then cut over to. Production is never rolled back.

not this

Confluent feature replacement

ksqlDB, Schema Registry mirroring, Stream Designer, Connect-managed connectors. Lascaris backup is transport and storage only. If those features are why you run Confluent, this is a backup that runs alongside Confluent, not a replacement for it. Scalytics is a Confluent partner.

Frequently asked before a briefing

The questions your CISO and your VP of Engineering will both ask.

Answered here so the briefing can go to your actual constraints. Repository links resolve to the upstream Apache 2.0 source. Architecture references map to public documentation.

Does this replace our Confluent or Apache Kafka cluster?

No. The pattern is explicitly additive. Lascaris sits next to your production cluster as one more read-only consumer and keeps the backup on a parallel stack. Production traffic, ksqlDB, Connect, Stream Governance, and every other feature you rely on continues to work exactly as before. The first deployment can be one mirrored topic in a single namespace; the production team is not required to change a single line of producer code.

How does recovery work?

Lascaris backup is a parallel recovery stack, not in-place rollback of production. The backup on S3 is an immutable, durable copy of every mirrored topic. Standard Kafka consumers read it through the normal wire protocol. Replay, batch reprocessing, failover drills, and agent workloads all run against the stack without touching the source cluster. Topic-level recovery runs on the DR side today: restore a mirrored topic as of a chosen time into a new topic for controlled validation and cutover. The restored topic is additive, not a rollback of the source cluster. Every segment carries its commit timestamp in S3 metadata, which is what makes point-in-time restore possible.

What happens during a long target-cluster outage?

Lascaris does not require a separate disk buffer. The internal franz-go producer has an in-memory buffer with retries for transient interruptions. If the backup target is unavailable for an extended period, the consumer applies backpressure and stops advancing the offset on the source cluster. The source cluster itself acts as the durable buffer through its existing retention. When it returns, replication resumes from the last committed offset, no data lost. This is documented in the Resilience section of the source.

Can this run air-gapped?

Yes. Lascaris runs without internet egress. Container images mirror to your registry. The only requirements are a reachable S3-compatible endpoint (MinIO, Ceph, or on-prem object store) and a reachable etcd ensemble. Both can sit inside your network boundary or inside a classified enclave. The data path makes no external calls.

What is the realistic ingestion ceiling?

A single Lascaris replication job handles up to roughly 250 MB/s sustained with zstd compression and a 50 MB fetch batch. Larger estates run multiple jobs in parallel, partitioned by topic prefix. The backup side scales horizontally with stateless broker pods, and S3 is effectively unbounded for the throughput tier most backup workloads need. The bottleneck is almost always source-cluster egress, not the backup side.

What does Scalytics provide on top of the open source?

Lascaris managed by Scalytics in your own cloud, or support while you run it yourself. Architecture review for backup and DR strategy, hardening for regulated environments, DORA and NIS2 evidence packs mapped to your specific topics and retention, integration with Apache Wayang for federated analytics over the backup data, and 24/7 enterprise support contracts. The repositories remain Apache 2.0. The product roadmap is independent of any specific support engagement.

Will offsets match between source and backup?

For recovery, exact offset preservation across vendors is not the design goal. Lascaris preserves order within a partition, preserves message keys, and uses production to keep duplicates rare. The mirrored topic in the backup has its own offset space, which is the expected behavior for a backup target. If your workload requires offset-preserving replication for active-active or hot failover, that is a different pattern with different tradeoffs and we will say so on the briefing call.

How long does a full pilot take?

Two weeks for a working pilot in a non-production environment, including Lascaris deployment on your Kubernetes, three to five topics mirrored, and one recovery-test report generated. Four to six weeks for a production rollout with compliance evidence aligned to your specific DORA or NIS2 control set. The architecture sprint covers both phases.

Next step

Replace your expensive standby cluster with a locked backup and an SI agent plane.

Forty-five minutes. Architecture review, backup pattern mapped to your topology, Lascaris configuration for your specific source, compliance evidence pack for DORA or NIS2. Bring the failure scenario that keeps your on-call team awake.

▸ Pricing and Services ▸ Read the source ▸ About Lascaris