Blog

Key Takeaways

• Replication keeps a ready-to-start copy of a workload on a second platform, so recovery means powering something on instead of rebuilding it.
• Backup and replication are not competing options. Backup gives you retention and clean recovery points. Replication gives you speed.
• Snapshot-based replication creates point-in-time replicas on whatever interval you set, from nightly to every few minutes. Continuous data protection uses a journal instead, for recovery points measured in seconds.
• Replication is storage agnostic but not hypervisor agnostic. Cross-platform portability comes from restoring a backup, not from a replica.
• The goal is a mix you can afford. CDP costs more than snapshot replication, which costs more than backup, mostly because of the storage underneath.
• A replica that has never been failed over is an assumption. Tested, orchestrated plans are what turn replicas into a recovery capability.

---

Here is a question worth sitting with: when did you last prove your recovery time objective, rather than assert it?

An RTO does not go stale because of the calendar. Plenty of targets set years ago still hold up fine. It goes stale when nothing in the environment has tested it since, and most teams cannot say which category theirs falls into.

Replication is one of the levers that makes an aggressive RTO provable. It maintains a ready-to-start copy of a workload at a second site or in a cloud, so you fail over to the copy instead of restoring from backup. The copy is already in the right format, on the right platform, waiting to be powered on.

That difference is measured in orders of magnitude. Restoring a large workload from backup can take as long as the backup took to create. Failing over to a replica takes as long as it takes to boot.

What Is Replication for Disaster Recovery?

Replication creates a copy of a workload on a second platform and keeps it ready to run. How current that copy stays depends on which method you use, and that is the part most explanations skip.

With snapshot-based replication, you get point-in-time replicas created on whatever interval you set. Run the job nightly and you have a replica of last night. Run it every 15 minutes and you have a replica from 15 minutes ago.

Both are legitimate designs. I ran nightly snapshot replicas as a customer for years and slept fine, because nightly was what the business had actually agreed to lose. The interval is a business decision, not a technical verdict on the method.

With continuous data protection, you get a journal rather than an interval. You pick a point in time to recover to, and that point can be seconds old.

Either way you end up with something you can power on. Neither is a live mirror of production, which is the most common misconception about replication.

Two numbers describe what you are buying:

• Recovery time objective, how long service can be unavailable. Replication improves this because the replica is already built. You are powering on a machine, not rebuilding one.
• Recovery point objective, how much data you can afford to lose. You set this yourself through the job interval, anywhere from once a night to every few minutes, or down to seconds with CDP.

Replicas can sit in a second data center you own, at a service provider, or in a cloud. Where they live changes the cost and the failover procedure, not the underlying idea.

Backup and Replication Solve Different Problems

This is the comparison people search for most, and the honest answer is that you need both. They fail in different directions. Backup is a historical archive optimized for retention and storage efficiency. Replication is a standby copy optimized for speed of return to service.

	Backup	Replication
What it produces	A compressed, deduplicated, portable copy in a repository.	A ready-to-start copy of the workload on a target platform.
Typical recovery time	Minutes to hours, depending on size and restore method.	Minutes, limited mainly by boot and network cutover.
Typical recovery point	Set by job schedule, usually hours.	Set by job schedule too, from nightly to minutes. Seconds with CDP.
Retention	Long. Days, months, or years, with archive tiering.	Short. A limited number of restore points per replica.
Storage cost	Lower. Backups can live on cheaper storage.	Higher. Replicas need production-class capacity on the target.
Platform portability	High. A backup can be restored to a different hypervisor.	None. Source and target stay on the same platform.
Best for	Compliance retention, ransomware recovery, granular restores, rebuilding from a known-clean point.	Workloads where minutes of downtime carry real cost.

One caution worth stating plainly: replication is not a ransomware control. A replica that faithfully mirrors an encrypted source is an encrypted replica. Clean recovery depends on immutable backups and enough retained restore points to find a known-good state.

Two Ways to Replicate

Snapshot-based replication

Snapshot-based replication runs as a job on an interval. Each run creates a snapshot, identifies the blocks that changed since the previous run, and sends only those to the target. Changed block tracking keeps the transfer small, and variable compression lets you trade processing for bandwidth depending on the link you have.

One distinction matters more than any other here, and it is the one people get wrong most often. Snapshot-based replication is storage agnostic, not hypervisor agnostic.

You can replicate between different storage on either end without trouble. The platform, though, has to match: vSphere to vSphere, Hyper-V to Hyper-V, Proxmox to Proxmox. You cannot replicate a vSphere VM onto a Proxmox host.

If cross-platform portability is what you are after, that comes from backup. Restoring a backup to a different hypervisor is supported, and for teams currently re-evaluating their hypervisor strategy, that is the capability worth leaning on. Keep the backups broad and the replicas narrow.

Proxmox replication and instant recovery were both added in 13.1, which widens where this method applies.

Continuous data protection

Continuous data protection is for workloads where losing an hour is not survivable. Instead of snapshotting on a schedule, it intercepts write operations in transit between the machine and its datastore and replicates them as they happen, through the hypervisor I/O filtering interface. Because it is always on and never creates a snapshot, it reaches a near-zero recovery point objective.

Short-term restore points let you roll back to a state seconds or minutes ago, which is useful for more than site loss. A bad deployment or a corrupted database can be rewound without going near a backup.

Veeam Backup & Replication v13 added Universal CDP, which covers Windows source workloads replicating to a VMware vSphere or Cloud Director target.

The trade-off is footprint. CDP needs supported infrastructure, journal capacity on the target, and enough bandwidth to keep up with your write rate. It is a tier-one tool, not a default.

When Bandwidth Is the Real Constraint

Most disaster recovery designs do not fail on concept. They fail because moving the data off site turned out to be harder than the diagram suggested. The link that looked fine on paper meets a 40 TB initial sync and the project stalls for a month.

A few controls do most of the work:

• Changed block tracking, so only the blocks that changed get sent. This is the single largest reduction in traffic.
• Variable compression, tuned per job. Heavier for slow links, lighter for fast links where processing time becomes the bottleneck.
• WAN acceleration, which combines compression, multi-streaming, and deduplication against a global cache so repeated blocks are never sent twice.
• Replica seeding, where the first full copy reaches the target by other means and is then kept current with increments. This turns an impossible initial sync into a routine one.
• Traffic throttling windows, so replication does not compete with the business during working hours.
• Encryption of data in transit. This is a separate control from WAN acceleration, and it earns its place the moment replicas leave your network for a provider or a second site over links you do not own.

Network mapping and re-IP rules belong in the same conversation. A replica that boots into the wrong network is not a recovery, and sorting out addressing during an outage is not the time to discover it.

A Replica Is Not a Recovery Plan

A replica proves you have a copy. It does not prove you can recover. The gap between those two is where most disaster recovery programs actually live.

Recovery needs order. Applications have dependencies, and bringing 40 machines up in the wrong sequence produces 40 machines that cannot talk to each other.

A failover plan encodes the boot order, the delays between tiers, and the network changes, so failover becomes one action rather than 40 decisions made under pressure. Plenty of teams handle this with homegrown PowerShell today. That works, right up until the person who wrote it moves on.

Veeam Recovery Orchestrator, part of Veeam Data Platform Premium Edition, does this properly. It arranges replicas into orchestrated plans, supports custom scripts inside those plans, restores to different locations, and runs failover tests in an isolated environment without touching production.

It also generates the documentation and test evidence auditors ask for. That matters more than it sounds. An untested plan and a tested one look identical on paper, right up until the day you need one.

Two more things belong in any plan worth the name:

• Getting to the disaster recovery site is half the exercise. Returning to the primary site, with the data that changed while you were failed over, is the other half.
• A tested schedule. Test at a defined cadence, and test again after significant infrastructure change. A plan validated against an environment that no longer exists is not validated.

DRaaS: Disaster Recovery Without a Second Data Center

The cost and complexity of standing up a secondary site stops many organizations before they start. Disaster recovery as a service solves that by renting the target instead of building it. A provider supplies the compute, storage, and network on the far end, and you replicate into it.

Veeam Cloud Connect Replication is the built-in mechanism. It connects a Veeam Backup & Replication installation to a provider’s infrastructure over a single port, without a site-to-site tunnel. For organizations already running on a provider platform, replicas can be integrated into the provider’s own multi-tenant environment.

Failover does not have to mean filing a ticket and waiting. Through the Veeam Service Provider Console, you can initiate and manage your own failover directly.

That said, the provider is worth more than their hardware. Planning the failover procedure, sizing the target, and walking through a real test are where a good one earns their keep.

DRaaS is worth considering when any of these apply:

• You have no second site, and building one cannot be justified for the number of workloads that need it.
• You have a second site, but it is too close to the first to survive a regional event.
• Regulation or data sovereignty requires a protected copy in a separate location or jurisdiction, and standing that up yourself is not practical.
• You have the infrastructure but not the people to design, test, and maintain a failover capability.
• Your recovery requirements apply to a small subset of workloads, so a full secondary environment would sit mostly idle.

Read the contract carefully on two points: who declares a disaster, and what the provider commits to on failover time. Those two answers decide whether the recovery time objective in your plan is real.

Mix and Match: Building a Strategy You Can Afford

The real value in having backup, snapshot-based replication, and CDP in one platform is not picking the best one. It is combining them so each workload gets the protection it needs at a price the business can carry.

The cost hierarchy is consistent, and it comes down to the storage underneath:

• Backup is the cheapest. Backups compress and deduplicate, and they can live on slower, cheaper storage.
• Snapshot-based replication costs more. A replica needs production-class capacity on the target, because it has to be able to run.
• CDP costs the most. On top of production-class target storage, it needs journal capacity and bandwidth that keeps pace with your write rate.

Protecting everything with CDP is a budget conversation you will lose. Protecting everything with backup alone is a recovery time objective you cannot meet. The answer is a deliberate mix.

Build it so it can change, too. Workloads get promoted and demoted as the business shifts, and a strategy that assumes today’s tiering is permanent will be wrong within a year.

Matching Tiers to Workloads

Here is a starting point. The specifics will differ, but the shape holds: backup underpins every tier, and replication is layered on top where downtime costs enough to justify it.

Tier	Recovery target	Typical approach
Tier one	Seconds of data loss, minutes to recover.	CDP to a second site or provider, inside an orchestrated failover plan, with immutable backup underneath.
Tier two	Minutes to an hour of data loss, under an hour to recover.	Snapshot-based replication on a tight interval, with immutable backup underneath.
Tier three	Hours of data loss, hours to recover.	Immutable backup with an offsite copy, restored on demand.
Tier four	A day or more acceptable.	Immutable backup, tiered to capacity or archive storage.

Assign the tier with the application owner, not for them. The conversation about what an hour of downtime actually costs is the one that makes the rest of the design defensible, and it is a much easier conversation to have before an outage than after one.

How Veeam Helps

Veeam Backup & Replication provides backup and replication in the same platform, from the same interface, against the same protected workloads. You are not stitching a disaster recovery point product onto a separate backup strategy and hoping the two agree about what is protected.

Snapshot-based replication and CDP are both built in, so you can assign a method per workload instead of per environment. Changed block tracking, variable compression, and WAN acceleration handle the bandwidth reality.

Veeam Cloud Connect Replication gives you a provider-hosted target when a second site is not on the table, with self-service failover through the Veeam Service Provider Console. Veeam Recovery Orchestrator turns replicas into tested, documented failover plans.

And because backup and replication share the platform, the immutable backup copies that get you through a ransomware event sit alongside the replicas that get you through an outage. That is what lets you mix methods per workload instead of standardizing on the most expensive one.

The trial includes full functionality for 30 days, which is enough to replicate a real workload and fail it over.

---

FAQ

The post Replication for Disaster Recovery: How to Hit Tight RTOs and RPOs appeared first on Veeam Software Official Blog.

from Veeam Software Official Blog https://ift.tt/FBpxPTg