code review

Author: paulohtb6

modules/deploy/pages/redpanda/manual/resilience/shadowing.adoc

@@ -10,20 +10,17 @@ include::shared:partial$enterprise-license.adoc[]
 
 Shadowing is Redpanda's enterprise-grade disaster recovery solution that establishes asynchronous, offset-preserving replication between two distinct Redpanda clusters. A cluster is able to create a dedicated client that continuously replicates source cluster data, including offsets, timestamps, and cluster metadata. This creates a read-only shadow cluster that you can quickly failover to handle production traffic during a disaster.
 
-[IMPORTANT]
-====
-**Experiencing an active disaster?** See xref:deploy:redpanda/manual/resilience/shadowing-guide.adoc[Emergency Shadowing Failover] for immediate step-by-step emergency procedures.
-====
+include::shared:partial$emergency-shadowing-callout.adoc[]
 
 Unlike traditional replication tools that re-produce messages, Shadowing copies data at the byte level, ensuring shadow topics contain identical copies of source topics with preserved offsets and timestamps.
 
 Shadowing replicates:
 
 * **Topic data**: All records with preserved offsets and timestamps
 * **Topic configurations**: Partition counts, retention policies, and other xref:reference:properties/topic-properties.adoc[topic properties]
-* **xref:develop:consume-data/consumer-offsets.adoc[Consumer group offsets]**: Enables seamless consumer resumption after failover
+* **Consumer group offsets**: Enables seamless consumer resumption after failover
 * **Access Control Lists (ACLs)**: User permissions and security policies
-* **xref:manage:schema-reg/schema-reg-overview.adoc[Schema Registry] data**: Schema definitions and compatibility settings
+* **Schema Registry data**: Schema definitions and compatibility settings
 
 == How Shadowing fits into disaster recovery
 
@@ -81,17 +78,16 @@ This service account authenticates from the shadow cluster to the source cluster
 
 === Network and authentication
 
-You must configure network connectivity between clusters with appropriate firewall rules to allow the shadow cluster to connect to the source cluster for data replication. Shadowing uses a pull-based architecture where the shadow cluster fetches data from the source cluster.
+You must configure network connectivity between clusters with appropriate firewall rules to allow the shadow cluster to connect to the source cluster for data replication. Shadowing uses a pull-based architecture where the shadow cluster fetches data from the source cluster. For detailed networking configuration, see <<networking>>.
 
 If using xref:manage:security/authentication.adoc[authentication] for the shadow link connection, configure the source cluster with your chosen authentication method (SASL/SCRAM, TLS, mTLS) and ensure the shadow cluster has the proper credentials to authenticate to the source cluster.
 
 == Set up Shadowing
 
 To set up Shadowing:
 
-* **Understand replication behavior**: Before you set up Shadowing, review what topic properties, consumer groups, and security settings Redpanda automatically replicates versus what requires explicit configuration
-* **Configure filters**: Define which topics, consumer groups, and ACLs should replicate by creating include/exclude patterns that match your disaster recovery requirements
-* **Create a shadow link**: Establish the connection between clusters using `rpk`, the Admin API, or Redpanda Console with authentication and network settings
+* **Configure filters**: Define which topics, consumer groups, and ACLs should replicate by creating include/exclude patterns that match your disaster recovery requirements. See <<set-filters>>.
+* **Create a shadow link**: Establish the connection between clusters using `rpk`, the Admin API, or Redpanda Console with authentication and network settings. See <<create-a-shadow-link>>.
 
 == What gets replicated
 
@@ -143,16 +139,16 @@ Each filter uses two key settings:
 * **Pattern type**: Determines how names are matched
   - `LITERAL`: Matches names exactly (including the special wildcard `*` to match all items)
   - `PREFIX`: Matches names that start with the specified string
-* **Filter type**: Specifies whether to include or exclude matching items
+* **Filter type**: Specifies whether to INCLUDE or EXCLUDE matching items
   - `INCLUDE`: Replicate items that match the pattern
   - `EXCLUDE`: Skip items that match the pattern
 
 ==== Filter processing rules
 
-Redpanda processes filters in the order you define them with exclude filters taking precedence. Design your filter lists carefully:
+Redpanda processes filters in the order you define them with EXCLUDE filters taking precedence. Design your filter lists carefully:
 
 1. **Exclude filters win**: If any EXCLUDE filter matches a resource, it is excluded regardless of INCLUDE filters
-2. **Order matters for includes**: Among INCLUDE filters, the first match determines the result
+2. **Order matters for INCLUDE filters**: Among INCLUDE filters, the first match determines the result
 3. **Default behavior**: Items that don't match any filter are excluded from replication
 
 ==== Common filtering patterns
@@ -312,6 +308,8 @@ This creates a template configuration file that you can customize for your envir
 
 Configure network connectivity between your source and shadow clusters to enable shadow link replication. The shadow cluster initiates connections to the source cluster using a pull-based architecture.
 
+For additional details about networking, see <<network-and-authentication>>.
+
 ==== Connection requirements
 
 * **Direction**: Shadow cluster connects to source cluster (outbound from shadow, inbound to source)
@@ -526,9 +524,11 @@ See also: link:/api/doc/admin/[Admin API v2 reference^]
 
 == Failover
 
+include::shared:partial$emergency-shadowing-callout.adoc[]
+
 Failover is the process of modifying shadow topics or an entire shadow cluster from read-only replicas to fully writable resources, and ceasing replication from the source cluster. You can fail over individual topics for selective workload migration or fail over the entire cluster for comprehensive disaster recovery. This critical operation transforms your shadow resources into operational production assets, allowing you to redirect application traffic when the source cluster becomes unavailable.
 
-=== Understanding failover behavior
+=== Failover behavior
 
 When you initiate failover, Redpanda performs the following operations:
 
@@ -612,7 +612,7 @@ After successful failover, your shadow cluster exhibits the following characteri
 
 **Topic accessibility:**
 
-* Failedover topics become fully writable and readable.
+* Failed over topics become fully writable and readable.
 * Applications can produce and consume messages normally.
 * All Kafka APIs are available for failedover topics.
 * Original offsets and timestamps are preserved.

modules/shared/partials/emergency-shadowing-callout.adoc

@@ -0,0 +1,5 @@
+[IMPORTANT]
+.Experiencing an active disaster?
+====
+See xref:deploy:redpanda/manual/resilience/shadowing-guide.adoc[Emergency Shadowing Failover] for immediate step-by-step emergency procedures.
+====