Shadowing for DR
Disaster recovery for enterprise streaming with Redpanda Shadowing
Shadowing powers Redpanda’s built-in disaster recovery (DR) feature that creates a byte-for-byte, offset-preserving replica of your production cluster in another region. So your applications keep running, even when an entire region fails — with far less DR complexity than traditional Kafka stacks.
Enterprise-grade DR in minutes, not quarters.
Shadowing lives inside the Redpanda broker — no MirrorMaker, no Kafka Connect, no schema-linking sidecars, and definitely no 37-step failover runbook.
Shadowing advantages at a glance:
- Near-instant recovery: RPO & RTO measured in milliseconds & minutes, not hours-old backups.
- Apps don’t break: preserves offsets, ACLs, configs, schemas — everything.
- Built-in simplicity: part of the broker, not bolted on.
- Low overhead: pull-based async replication keeps load minimal on prod.
- SecOps approved: runs on standard Kafka APIs & ports, no new firewall rules.
Keep revenue streaming, even when whole regions fail.
Cloud providers deliver high availability within a region. But risk, compliance, and the board are asking a different question:
"What happens when the entire region goes dark?"
Regional outages are more common than you'd think. In 2025, each hyperscaler had a regional outage, leading to hours of downtime for businesses. [GCP, AWS, Azure]
What is your team's plan?
Mitigating business risk with Shadowing
Protect revenue and customer trust
Every minute of downtime can cost thousands of dollars per hour. Shadowing prevents outages from becoming headlines.
Meet RPO, RTO, and regulatory expectations
When compliance asks, “How do you fail over across regions?”, you’ll finally have an answer they’ll approve, and technology that teams can easily and repeatedly test.
Reduce DR complexity and toil
Replace a spaghetti pile of DR components with one integrated feature in the broker. That means less infrastructure babysitting and more building for engineers.
Where customers use Shadowing
Capital markets and trading platforms
Continuous trading, market data, and risk pipelines where lost events become lost trading opportunities.
E-commerce and retail
Order management, inventory, and personalization services that must remain online during peak demand events.
Gaming and online betting
Real-time odds, wagers, and in-play experiences where failures directly impact revenue and user trust.
Architected for performance and reliability
Designed for mission-critical environments, Shadowing uses an asynchronous, pull-based architecture that decouples disaster recovery from production throughput.
Passive asynchronous replication
The shadow cluster operates as a passive consumer, pulling data from the primary cluster. This ensures that disaster recovery processes do not compete for resources with active production workloads, minimizing impact on throughput.
Consistent failover mechanics
Because Shadowing preserves consumer offsets exactly byte-for-byte, failover procedures are deterministic. Operations teams can update bootstrap server endpoints, and consumers will resume consumption from the precise point of interruption without "rewinding" or complex state translation — issues that risk creating gaps or duplicating data.
Standardized security & networking
Shadowing operates entirely over the standard Kafka wire protocol. This simplifies network security posture by using existing firewalls and access controls, without requiring additional open ports, proprietary VPNs, or complex sidecar proxies.
Unified metadata & schema sync
True resilience requires more than just data. Shadowing automatically replicates schemas, Access Control Lists (ACLs), and topic configurations alongside the event stream. This eliminates the need for separate schema linking tools or manual configuration drift management, ensuring the shadow cluster is functionally identical to production.
Shadowing in Redpanda Console
Quickly configure a shadow link in Redpanda Console, and easily monitor its status.
Evaluating your DR options
Compare how Shadowing in Redpanda is different from other approaches from across the Kafka ecosystem.
Redpanda Shadowing | Proprietary Broker Linking | Managed Replication Services | Open Source Replication Tools | |
|---|---|---|---|---|
| Architecture Type | Native (Broker-integrated) | Native (Broker-integrated) | Sidecar (Obscured/Managed) | Sidecar (Self-Managed Infra) |
| Replication Model | Async Pull (Low prod impact) | Async Pull (Low prod impact) | Push/Pull (Varies by implementation) | Push & Pull (Active producer load) |
| Offset Handling | Preserved (Byte-for-byte exact) | Preserved (Byte-for-byte exact) | Translated (Auto re-mapping) | Translated (Manual config re-mapping) |
| Schema Synchronization | Integrated (Built-in) | Separate (Requires additional tool & costs) | Separate (Requires external registry sync) | Manual (Not included) |
| Operational Complexity | Low (Single Platform) | Medium (Complex config options) | Medium (Additional managed resource) | High (Requires dedicated engineering) |
FAQ: Redpanda Shadowing & Disaster Recovery
A shadow link is the mechanism Redpanda uses to replicate data asynchronously between clusters in different cloud regions (active-passive DR), as opposed to Tiered Storage, which moves data vertically to object storage services like S3.
No. Shadowing is native to the Redpanda broker and is built using the standard Kafka API. It does not require MirrorMaker 2, separate DR connectors, schema bridges, or nonstandard access to internal cluster protocols. Because Shadowing preserves schemas, ACLs, and consumer group offsets automatically, applications can reconnect seamlessly without the offset translation issues common in external DR tools.
Not today, but in the future, yes. Currently, Shadowing is optimized specifically for enterprise DR (active-passive architectures). It creates a one-way, offset-preserving replica for failover scenarios. Support for additional use cases — such as simplified cluster migration and other complex geo-replicated topologies — is currently on the product roadmap.
If you have specific use cases you'd like to see supported in Shadowing, please contact us to connect with our product team.
No. Use Tiered Storage for long-term retention. Shadowing for DR is designed for high-availability and business continuity. It maintains a "hot standby" clone of your production cluster to minimize RPO (Recovery Point Objective) and RTO (Recovery Time Objective) requirements. While Shadowing preserves data byte-for-byte, including consumer offsets, its primary goal is failover readiness, not archival storage.
No. These are two distinct features with different purposes and separate configuration flags:
- Redpanda Shadowing is a disaster recovery (DR) feature. It provides active-passive replication (Region A → Region B) that fully preserves offsets and other metadata, to keep your business online during a regional outage.
- Tiered Storage (formerly known as Shadow Indexing) is a storage feature. It offloads log segments to object storage (Broker → S3/GCS/Azure Blob) for infinite retention and cost reduction.
Disaster recovery can’t be a theory.
It must be a switch.
Stop betting your business on scripts, tasks, and complex configurations. Enable Shadowing in Redpanda Enterprise Edition, and move to a verified architectural DR strategy for your event-driven applications.