# Explore Shadow Linking for Disaster Recovery > For the complete documentation index, see [llms.txt](https://docs.redpanda.com/llms.txt). Component-specific: [labs-full.txt](https://docs.redpanda.com/labs-full.txt) --- title: Explore Shadow Linking for Disaster Recovery latest-operator-version: v26.1.4 latest-console-tag: v3.7.3 latest-connect-version: 4.93.0 latest-redpanda-tag: v26.1.9 docname: shadow-linking page-component-name: labs page-version: master page-component-version: master page-component-title: Labs page-relative-src-path: shadow-linking.adoc page-edit-url: https://github.com/redpanda-data/redpanda-labs/edit/main/docs/modules/kubernetes/pages/shadow-linking.adoc description: Deploy two Redpanda clusters on Kubernetes and configure shadow linking to continuously replicate topics, consumer group offsets, and Schema Registry data. page-git-created-date: "2026-04-13" page-git-modified-date: "2026-04-13" --- Shadow linking is a built-in disaster recovery mechanism that continuously replicates topics, consumer group offsets, and Schema Registry data from a source cluster to a shadow cluster running on Kubernetes. This lab demonstrates how shadow linking works and how you can use it to fail over to a shadow cluster. In this lab, you deploy two single-node Redpanda clusters on Kubernetes and configure a shadow link between them. You then explore basic topic shadowing, Schema Registry shadowing, and consumer group failover. ## [](#prerequisites)Prerequisites You must have the following: - [kubectl](https://kubernetes.io/docs/tasks/tools/) CLI installed - [Helm 3+](https://helm.sh/docs/intro/install/) installed - [rpk](https://docs.redpanda.com/streaming/current/get-started/rpk-install/) CLI installed - [kind](https://kind.sigs.k8s.io/docs/user/quick-start/#installation) installed (for local testing) - [Docker](https://docs.docker.com/get-docker/) installed and running ## [](#what-gets-deployed)What gets deployed The setup script installs the following components: - **cert-manager** (namespace: `cert-manager`): Manages TLS certificates - **Redpanda Operator** (namespace: `rp-operator`): Manages Redpanda cluster lifecycle - **Source cluster** (namespace: `source`): Primary cluster where you write data - **Shadow cluster** (namespace: `shadow`): Replication target cluster - **ShadowLink resource**: Defines the replication relationship between clusters The shadow link configuration mirrors all topics using wildcard filtering, replicates consumer group offsets, and synchronizes the Schema Registry, all at 5-second intervals. ## [](#run-the-lab)Run the lab 1. Clone this repository: ```bash git clone https://github.com/redpanda-data/redpanda-labs.git cd redpanda-labs/kubernetes/shadow-linking ``` 2. Create a local Kubernetes cluster using kind: ```bash kind create cluster --name redpanda-shadow ``` 3. Run the setup script to deploy both clusters and configure shadow linking: ```bash ./setup.sh ``` The script installs cert-manager, deploys the Redpanda Operator, creates the source and shadow clusters, configures the shadow link, sets up port forwarding for local access, and creates rpk profiles for both clusters. 4. Verify both clusters are healthy: ```bash rpk --profile source cluster health rpk --profile shadow cluster health ``` ## [](#explore-basic-topic-shadowing)Explore basic topic shadowing This section shows how topics and messages automatically replicate from the source to the shadow cluster. 1. Create a topic on the source cluster: ```bash rpk --profile source topic create basic -p1 -r1 ``` 2. Produce a message to the source cluster: ```bash echo "Hello, world" | rpk --profile source topic produce basic ``` 3. Wait a few seconds for replication, then list topics on the shadow cluster: ```bash rpk --profile shadow topic list ``` You should see the `basic` topic appear on the shadow cluster. 4. Consume messages from both clusters to verify data replication: ```bash rpk --profile source topic consume basic -n1 rpk --profile shadow topic consume basic -n1 ``` The same message appears on both clusters. ## [](#explore-schema-registry-shadowing)Explore Schema Registry shadowing This section shows how Avro schemas registered on the source cluster replicate to the shadow cluster, allowing shadow-side message deserialization. 1. Register an Avro schema on the source cluster: ```bash rpk --profile source registry schema create syslog-value --schema resources/syslog.avsc --type avro ``` 2. Create a topic for schema-encoded messages: ```bash rpk --profile source topic create syslog -p1 -r1 ``` 3. Produce Avro-encoded syslog records to the source cluster: ```bash cat resources/syslogs.json | rpk --profile source topic produce syslog --schema-id=topic ``` 4. Wait a few seconds, then list schemas on both clusters: ```bash rpk --profile source registry subject list rpk --profile shadow registry subject list ``` The `syslog-value` schema appears on both clusters. 5. Consume decoded messages from the shadow cluster using the replicated schema: ```bash rpk --profile shadow topic consume syslog -n1 --use-schema-registry -f'%v\n' | jq ``` The shadow cluster can deserialize messages using the replicated schema. ## [](#explore-consumer-group-failover)Explore consumer group failover This section shows how consumer group offsets replicate to the shadow cluster, allowing consumers to resume from their exact position after a failover. 1. Create a topic on the source cluster: ```bash rpk --profile source topic create foo -p1 -r1 ``` 2. Produce records and consume them on the source cluster: ```bash seq 0 2 | rpk --profile source topic produce foo rpk --profile source topic consume foo -n3 -g consumer-group-foo ``` This creates a consumer group and processes the messages. 3. View consumer group offsets on both clusters: ```bash rpk --profile source group describe consumer-group-foo rpk --profile shadow group describe consumer-group-foo ``` The consumer group and its offsets are replicated to the shadow cluster. 4. Trigger a failover to the shadow cluster: ```bash rpk --profile shadow shadow failover shadow-link --all --no-confirm rpk --profile shadow shadow status shadow-link ``` This command promotes the shadow cluster to become writable. 5. Produce more records and consume on the shadow cluster: ```bash seq 3 5 | rpk --profile shadow topic produce foo rpk --profile shadow topic consume foo -n3 -g consumer-group-foo ``` The consumer resumes from the last committed offset (3) and consumes the new messages. ## [](#clean-up)Clean up To stop port forwarding, terminate the background processes: ```bash kill $(cat local-port-forward.pid) ``` To delete the kind cluster and all resources: ```bash kind delete cluster --name redpanda-shadow ``` ## [](#suggested-reading)Suggested reading - [Shadowing for Disaster Recovery](https://docs.redpanda.com/streaming/current/manage/disaster-recovery/shadowing/) - [Redpanda on Kubernetes](https://docs.redpanda.com/streaming/current/deploy/redpanda/kubernetes/get-started-dev/)