Chapter 9: Replication, Disaster Recovery, and SiteContinuity

Cohesity replication is a Protection-Group-aware operation: the source cluster sends only unique, deduplicated, compressed chunks to the target cluster, and the target keeps a fully addressable copy that can be searched, recovered, mounted, or orchestrated independently of the source. The replica is a working cluster, not a tape, which is what makes the four classic topologies viable.

The Four Canonical Topologies

Figure 9.1: Replication Topology Variants

Replication Policies and Retention

Replication is configured on the Protection Policy, not on the Protection Group. A policy can specify multiple "external" targets — local snapshot, replication target cluster, CloudArchive, CloudTier — each with its own retention. Retention on the replica is independent of the source: 14 daily on primary, 30 daily + 12 monthly on DR, 7 yearly on CloudArchive — all driven by one policy.

Key Takeaway: Topology decisions are driven by failure domain, not by bandwidth. Pick the topology that aligns with your blast-radius assumptions, then size WAN and retention to match.

Encrypted, Compressed, Deduplicated Wire Format

Cohesity replication is always encrypted in flight (TLS) and is deduplicated and compressed at the chunk level before the wire. The source queries the target's chunk fingerprint database and only ships chunks the target does not already have. This global dedup on the wire is the dominant reason Cohesity hits aggressive RPOs over modest WAN links.

Three Throttling Surfaces

1. SaaS Connector throttling for DataProtect-as-a-Service — per-connector, day/time windows, split upload/download. Values are in bytes per second.
2. Source-agent throttling for individual physical hosts.
3. Cluster-to-cluster windows on the Protection Policy.

Common gotcha: SaaS Connector throttle is in bytes per second, opposite of Veritas AIR convention. "100 MB/s" is 800 Mbps on the wire.

Network Architecture and Required Ports

Cohesity recommends 2x 10 GbE LACP Bond Mode 4 with MLAG/VPC for replication-target clusters and ROBO nodes — 20 Gbps combined per node.

Enable jumbo frames (MTU 9000) end-to-end. A single device that does not honor 9000-byte frames silently fragments or drops, tanking throughput.

Initial Seed Strategies

1. Wire seeding with extended window — quiet multi-day window, relaxed throttles.
2. Physical seed transport — replicate to a portable cluster on-site, ship it, re-home the target.

Replication Failure Handling

Cohesity replication is checkpointed: a partial run resumes from the last committed chunk rather than restarting. Persistent failures generate Helios alerts and pause the policy after configurable retry attempts.

Key Takeaway: Replication mechanics are built on dedup, compression, and TLS — but they only work if you've sized 2x10 GbE LACP, opened TCP 443/111/20000/24444, enabled MTU 9000 end-to-end, and remembered SaaS Connector throttles are in bytes per second.

The single formula every CCAE must memorize:

Required throughput = (FETB × daily change rate × (1 - dedup/compression)) / replication window

Bytes-vs-Bits Reference

Worked Example: 50 TB FETB, 5% Daily Change, 4-Hour Window

Step 1 - Daily change in bytes:
  50 TB x 0.05 = 2.5 TB of change per day

Step 2 - Apply dedup/compression (60% reduction):
  2.5 TB x 0.40 = 1.0 TB on the wire

Step 3 - Divide by replication window (4 hr = 14,400 s):
  1,000,000 MB / 14,400 s = ~69.4 MB/s

Step 4 - Convert to bits per second:
  69.4 MB/s x 8 = ~556 Mbps

Step 5 - Apply 50% utilization headroom:
  556 Mbps / 0.50 = ~1.11 Gbps minimum WAN provisioning

The RPO / Bandwidth / Dedup Trade-offs

Key Takeaway: Memorize the bandwidth equation, work in bytes first, multiply by 8 last, and budget for 50% of wire speed. The bytes-vs-bits trap has cost more than one architect a six-figure WAN over-provisioning bill.

Replication moves the data; SiteContinuity moves the application. SiteContinuity is Cohesity's DR orchestration engine that turns "we have replicated VMs" into "we have a runnable runbook with a measurable RTO."

The Runbook Analogy

A SiteContinuity runbook is an emergency-evacuation plan for an office building:

1. Who goes first? — Dependency order (DCs/DNS first, then app servers, then web).
2. Where do they go? — Resource Profile (target compute, port group, datastore).
3. What address? — Re-IP and VLAN mapping at the DR site.
4. How do you know everyone got out? — Validation steps.

Failback is going home after the storm: same plan in reverse, only after the building has been certified safe.

Runbook Building Blocks

• DR Applications — logical groups of VMs with defined boot order.
• Resource Profiles — reusable mappings of target vCenter/datastore/port group/IP rules.
• Failback Resource Set — separate resource definition for failback (Edit -> Add Resource Set).
• Snapshot Selection — latest by default, override for explicit RPO.

Figure 9.2: SiteContinuity DR Plan State Machine

Failover Procedure (Production Cutover)

1. DR Plans -> Disaster Recovery Plans.
2. Select plan -> Actions -> Failover.
3. Choose Resource Profile (network mapping, IP customization, target compute).
4. Optionally enable Protect VMs at DR Site — closes the backup gap at moment of failover.
5. Confirm snapshot (latest or earlier RPO).
6. Type YES to confirm.
7. Validate via DR vCenter: boot order, networks, application functionality, PG state.

Figure 9.3: Failover Orchestration Sequence

Prepare for Failback

1. Confirm plan is in Failover Complete.
2. Actions -> Prepare for Failback — drives reverse replication from DR back to primary.
3. Plan moves: Prepare for Failback In Progress -> Failback Ready.

Failback Procedure

1. Actions -> Failback.
2. Pick failback Resource Profile; confirm snapshot (VADP or CDP).
3. Type YES.
4. Validate against primary vCenter.
5. After Failback Complete -> Actions -> Prepare for Failover to re-seed the DR site.

RTO and RPO Measurement

• RPO is bounded by replication frequency (4-hr replication = 4-hr RPO worst case).
• RTO is bounded by runbook execution time (boot order, IP customization, app warmup).
• Regular Test Failovers are the single dominant predictor of successful real-world recoveries.

Key Takeaway: A SiteContinuity DR Plan is a state machine: Failover Ready -> Failover Complete -> Prepare Failback -> Failback Ready -> Failback Complete -> back to Failover Ready. Test variants do not change state. Skipping "Prepare for Failback" is the most common operational error.

The Four Cloud Features

CloudReplicate — DR Replica as a Working Cluster

Replicates Protection Group snapshots to a Cohesity Cloud Edition cluster in AWS or Azure. Granular file recovery, IMR, View mounting, and SiteContinuity all work on the cloud-side replica. Use when the cloud is your DR site.

CloudSpin — On-Demand Native Cloud VMs

Converts a backup snapshot into a native cloud VM (EC2 + EBS, or Azure VM + Managed Disks). Active trigger by user. Use for dev/test clones or lightweight cloud DR without a Cloud Edition cluster.

CloudArchive — Long-Term Retention

Separate archival copy in cloud object storage (S3, Azure Blob, GCP), driven by Protection Policy schedules. Source cluster keeps a local index for search.

CloudArchive Direct: streams full data blocks directly to cloud, only the index stays on-prem.

CloudTier — Capacity Overflow (NOT a DR Tool)

Auto-tiers cold blocks (default >60 days) to cloud object storage when local capacity exceeds 80%. Two critical facts:

• Once enabled, CloudTier cannot be disabled.
• CloudTier is not a DR copy — the cluster is still the only authoritative copy.

Decision Matrix

Figure 9.4: Cloud DR Decision Tree

Recovery into VMware Cloud and Azure VMware Solution

VMC and AVS are first-class targets — native vCenter that SiteContinuity drives directly, no CloudSpin conversion, no Cloud Edition cluster required. Trade-off: SDDC cost vs. Cloud Edition cost.

Comparing Cost vs. Recovery Options

Key Takeaway: CloudReplicate gives you a working cluster, CloudSpin gives you a native VM, CloudArchive gives you compliance retention, and CloudTier gives you capacity relief. Only the first three are DR options. CloudTier is irreversible once enabled.