Learn Veeam - Replication & Failover

#Introduction

Restores in episode 8 bring data back — but in the business world, downtime is expensive. In episode 9 we move to the next level: replication & failover — not just recovering, but staying running during a disaster. This is the essence of the Availability philosophy we covered in episode 1: backup is RPO, replication is RTO.

We will build VM replicas on another host, put together a Failover Plan, discuss Continuous Data Protection (CDP) for near-zero RPO, and automate failover with scripts and Veeam Disaster Recovery Orchestrator.

#Replication

#Replicating VMs to Another Host

A replication job creates a VM copy (replica) on another host — usually the DR site — keeping the replica synchronized. Unlike backup (which stores restore points), a replica is a ready-to-run VM that can be failed over at any time.

$vm = Get-VBRViObject -Name "DB-01"
$hostDst = Get-VBRServer -Name "esxi-dr"
Add-VBRReplicationJob -Name "Replica DB-01 to DR" -Entity $vm `
    -DestinationHost $hostDst -DestinationPath "datastore-dr"

#RPO and Synchronization

Replication uses forever incremental — after the first full, only changes are synchronized (every 15 minutes or hourly). The RPO is determined by how often synchronization runs. The replica stays in a powered off (but consistent) state until failover happens.

#Failover Plans

#Failover, Failback, and Test Failover

A Failover Plan is a set of VMs (replicas) failed over together as one unit — important because multi-tier applications need the correct boot order.

• Test Failover — running the replicas in an isolated network for testing without disrupting production. Mandatory on a routine basis (DR drills).
• Failover — the replicas are activated as production at the DR site; the replica VMs are powered on with new IPs/names.
• Failback — after the primary site recovers, changes are brought back (reverse failover), then the replicas return to their original state.

From the console: select the replica → Failover Now / Test Failover / Failback. Monitor the process via sessions:

Get-VBRReplica | Format-Table Name,State,HostName -AutoSize

#Continuous Data Protection (CDP)

For the strictest RPO, Veeam provides Continuous Data Protection (CDP): tracking every I/O change at the VM storage level and replicating it continuously to the replica. RPO can be pushed to seconds — not minutes or hours like regular replication.

When CDP is needed: critical transactional databases, payment systems, or workloads where losing a few seconds of data is a big loss. The trade-offs: more resources (network and storage) and limited platform support (vSphere in v13, with other platforms in development).

#DR at Site 2 and Failover Automation

#A Simple DR Architecture

Site A (production)                 Site B (DR)
VM ── replication job ──▶ Replica (ready-to-run VM)
                              ├── Failover Plan (together)
                              └── Test failover (isolated)

#Automation via Scripts and Orchestrator

Simple failovers can be automated with PowerShell — for example, when site A is considered down, run the Failover Plan:

Start-VBRFailoverPlan -Plan "AppStack-DR" -PowerAction Failover

However, for fully coordinated DR (DNS, IP, connectivity, boot order of many VMs), use Veeam Disaster Recovery Orchestrator (VDRO) — adding Runbooks that automate the entire DR process from detection to failback, including scheduled automated tests. We touch on VDRO again in episode 21 (roadmap/ecosystem).

#Designing DR Correctly

Design guidance:

• Replication for minute-hour RPO; CDP for second RPO.
• Failover Plans for multi-tier applications (boot order: DB → app → web).
• Routine test failovers in an isolated network; never test on the production network.
• Failback scheduled and tested — coming back from DR is as hard as leaving.
• Combine with off-site backup copies (episode 7) — replicas for RTO, backups for history and granular restores.

#Verification

After this episode, make sure:

• The replication job succeeded and the replica is consistent.
• Test failover successfully ran the replica in the test network.
• The Failover Plan includes the correct boot order.
• (Optional) The Start-VBRFailoverPlan script is ready to automate.

#Closing

Key takeaways:

• A replication job creates a ready-to-run replica on another host (DR site).
• A Failover Plan fails over many VMs together with the correct boot order.
• Routine test failovers are non-negotiable — DR rehearsal before a disaster.
• CDP replicates continuously for second-level RPO.
• Automation: PowerShell for simple failovers; VDRO for full DR runbooks.

In the next episode, episode 10, we will cover application backups: SQL, Exchange, AD & Oracle — application-aware processing with VSS for consistency, Application Groups (SQL + AD + file server), and agent jobs for databases (SQL/Exchange/SharePoint/Oracle) via Veeam Agent and plugins. Your backups will level up: from VM-level to data-level.