By Dr. Pranay Jha, infrastructure architect and long-time vExpert, who designs and tests DR for production VCF estates.
Two numbers decide almost every expensive choice in a disaster recovery design, and plenty of teams pick them backwards. They start from the product they already bought, or the replication they already run, then quote whatever recovery those tools happen to deliver. That is how a team promises the business a fifteen minute recovery while the real plan powers on forty virtual machines in no particular order and hopes the database is ready before the application tier starts asking for it.
The two numbers are RPO and RTO. Recovery point objective is how much data you can afford to lose, measured in time. Recovery time objective is how long the service can stay down before the loss becomes the kind that gets a meeting scheduled about it. In VMware Cloud Foundation 9, every design decision that spends money or bandwidth traces back to one of these two, and the platform, now sitting under VMware Live Recovery, gives you a separate set of controls for each. Set the numbers first. Buy and build to meet them, not the reverse.
Who this is for
You own the recovery number the business repeats back to you after an outage, and you want it to be a figure you can defend rather than a hope. This part is for the admin, infrastructure engineer or architect who has to turn RPO and RTO into replication choices, protection groups and a recovery plan that behaves the same at 3 a.m. as it did in the last test. Part 1 sorted backup from DR. This part turns the two numbers into design.
Two numbers, and what each one really asks
RPO and RTO sound like a matched pair, and teams often quote them together as if one implied the other. They do not. They measure different things, in different directions, and they are won or lost in different parts of the platform. Keeping them separate in your head is the first practical skill in DR design.
RPO is a promise about the past
RPO measures backward from the moment of failure. If your RPO is fifteen minutes, then in the worst case the last fifteen minutes of writes are gone when the service comes up at the recovery site. It is not a statement about how often a job runs. It is how much recent work the business has agreed it can lose or redo. A payment ledger and a nightly reporting database sit at opposite ends of that question. The operational reality at 3 a.m. is specific: someone asks whether the orders taken in the final minutes before the array died reached the recovery site. RPO is the answer you agreed to in advance, before anyone was awake to argue about it.
RTO is a promise about the future
RTO measures forward, from failure to the moment the service answers again. It is the number the business writes in its own continuity plan and the one a customer actually feels. RTO is not the time to power on a virtual machine. It is detection, the decision to declare a disaster, storage promotion at the recovery site, powering machines on in the right order, re addressing them when the network differs, and waiting for the application itself to respond. Teams underestimate it because they time the power on and forget everything wrapped around it.
RPO drives replication, RTO drives orchestration
The reason to separate the two numbers is that they pull on different machinery. RPO is won or lost in the replication layer, how often and how completely data reaches the recovery site. RTO is won or lost in orchestration, how the recovery plan brings services back and in what order. You can hold a perfect one minute RPO and still suffer a two hour RTO because nothing was sequenced. You can also run a fast, well ordered recovery plan that loses an hour of data because the replication schedule was too loose. Design both, and design them separately.
What RPO buys, and what it costs
Enhanced vSphere Replication under VMware Live Recovery reaches a one minute RPO. Standard host based replication floors at five minutes. Array based synchronous replication reaches effectively zero, because a write is acknowledged only once both sites hold it, at the price of write latency and a low latency link between sites. Every step toward zero costs bandwidth, money, or both. The table below is the shape of that trade.
What RTO buys, and what it costs
RTO improves through pre staging, ordering and automation. A recovery plan that groups machines by priority, boots them in sequence, waits for dependencies and re addresses them without a human typing anything will beat a manual scramble every time. The cost is the work to build the plan and the discipline to keep testing it. A plan that has not run since the network changed is a plan that will surprise you.
| Approach | Typical RPO | Typical RTO | Cost and complexity |
|---|---|---|---|
| Array based synchronous | Near zero, seconds | Minutes, if orchestrated | Highest |
| Enhanced vSphere Replication (VLR) | 1 min to 24 hr | Minutes to tens of minutes | Moderate |
| Standard vSphere Replication | 5 min to 24 hr | Minutes to tens of minutes | Lower |
| Restore from backup | Last completed job, hours | Hours | Lowest |
From the field
RPO is a target the scheduler negotiates, not a timer you set. vSphere Replication does not copy on a fixed clock. It watches the change rate on each protected machine and works backward from your RPO to decide when the next transfer must start and finish. Set a five minute RPO on a machine that writes faster than the link can drain, and the engine cannot close the window. You accrue RPO violations quietly, and the first time many teams notice is a red alarm during a scheduled test in front of an audience, not during a real event. The one minute floor bites for a different reason: it is entitled through the VMware Live Recovery subscription. Standard replication stops at five minutes. Teams size a whole design around one minute and only later find the licensing does not cover it.
Sizing an RTO you can defend
Here is how an RTO number actually adds up, using a plan of forty machines split across the five priority groups a recovery plan gives you. The platform will not start a priority group until the group above it has finished recovering, so the times stack rather than overlap. Add the fixed overhead at the front, the plan start, storage promotion and network mapping, and the total looks nothing like the sum of power on times alone. Walk the numbers once and you will stop quoting optimistic RTOs.
Worked example: forty VMs, five priority groups
Fixed overhead before anything boots is about 8 minutes: the recovery plan starts, storage is promoted at the recovery site, and network mappings and re-IP are applied. Priority 1 holds 4 core machines (DNS, directory, gateways) that take 4 minutes to boot and become ready. Priority 2 holds 8 databases at 6 minutes. Priority 3 holds 12 application and middleware machines at 7 minutes. Priority 4 holds 10 web tier machines at 5 minutes. Priority 5 holds 6 ancillary machines at 4 minutes. Because groups run in sequence, that is 8 + 4 + 6 + 7 + 5 + 4, which comes to 34 minutes measured. Add a 6 minute validation and sign off buffer and you reach 40. So you do not promise 34, and you certainly do not promise the raw power on time. You quote about 45 minutes with margin, and you keep the measured 34 as your internal target.
| Step | VMs | Added time | Cumulative |
|---|---|---|---|
| Plan start, promote storage, re-IP | n/a | 8 min | 8 min |
| Priority 1, core (DNS, directory, gateways) | 4 | 4 min | 12 min |
| Priority 2, databases | 8 | 6 min | 18 min |
| Priority 3, application and middleware | 12 | 7 min | 25 min |
| Priority 4, web tier | 10 | 5 min | 30 min |
| Priority 5, ancillary | 6 | 4 min | 34 min |
| Validation and sign off buffer | n/a | 6 min | 40 min |
What to validate before you rely on this
Confirm the RPO you set is actually being met per machine, which means checking for RPO violations, not just that replication shows configured. Confirm the link can drain the busiest machine at its peak change rate inside the RPO window, not at its daily average. Confirm the one minute RPO is covered by your VMware Live Recovery entitlement rather than assumed. And confirm your RTO figure came from a real test failover with a stopwatch, not from adding up power on times in a spreadsheet.
The RPO most teams set too low
The common advice is to push RPO as low as the tooling allows. I disagree, and I will say why. A one minute RPO applied across the board is the most common way teams waste bandwidth and licensing on this platform. Most systems do not need it. The one minute floor is entitled through the VMware Live Recovery subscription, and it consumes link capacity in proportion to change rate, so setting it everywhere means paying twice, in licensing and in the pipe, to protect data that in many cases reconciles from an upstream source anyway.
Tier it instead. Reserve one minute or synchronous for the few systems where a lost minute is a lost transaction with a name and a value. Put the broad middle at fifteen minutes to one hour, where the vast majority of workloads live comfortably. Let archives and reporting sit at four to twenty four hours. The design gets cheaper, and because you are no longer saturating the link with change from systems that did not need protecting so tightly, the tiers that actually matter meet their RPO under load. A flat one minute RPO is the kind of decision that looks careful on a slide and starves your important systems of bandwidth during the one event you built all of this for.
What I would actually do
Define two or three RPO tiers, never one. Keep the aggressive one minute or synchronous tier for the handful of systems that genuinely cannot lose minutes, set the broad middle at fifteen minutes to an hour, and let the long tail sit at four to twenty four hours. Set RTO by recovery plan priority group, measure it in a non disruptive test, and quote the measured number plus a margin. Write both numbers per tier into the design document and get a business owner to sign the page. The signature is what turns your RPO and RTO from an engineering guess into an agreement.
Measure RTO with a test, not a real failover
Running an actual failover to time your RTO is a production affecting action. It moves live services to the recovery site and requires a failback to return them. Use a non disruptive test failover, which runs the recovery plan into an isolated test network so you can measure the timings without touching production. Save real planned migration or failover for a scheduled window with a rollback plan agreed in advance.
Common questions
Is a lower RPO always better?
No. RPO should match what the data is worth, not what the tool can do. A one minute RPO on a system that already reconciles from an upstream source every hour buys nothing and costs bandwidth and licensing. Match the number to the recovery the business actually needs.
What is the lowest RPO vSphere Replication supports?
One minute, and only with enhanced replication through a VMware Live Recovery subscription or a legacy Site Recovery Manager license. Without that entitlement the floor is five minutes. The maximum in both cases is twenty four hours.
Does RTO include the time to notice and decide to fail over?
It should. The clock the business cares about starts when the service stops, not when you click run. Detection and the decision to declare a disaster often add more minutes than the technical recovery, so build that time into the number you promise.
Can I reach near zero RPO with host based replication?
No. Near zero or zero data loss needs synchronous array based replication, where a write is acknowledged only after both sites hold it. That protects data but adds write latency and demands a low latency link, so it is reserved for the systems that justify the cost.
If replication is healthy, is my RTO safe?
Not necessarily. Healthy replication protects your RPO. RTO depends on the recovery plan doing the right things in the right order and on the recovery site having the compute, network and storage to run everything at once. A green replication dashboard says nothing about boot order or capacity at the far end.
RPO and RTO are not fields you fill in after the design is finished. They are the design. Get the two numbers agreed and written down, tier them so you are not paying for one minute everywhere, then build replication to protect the first number and a recovery plan to hit the second. Part 3 walks through the VMware Live Recovery family so you know which component owns which promise, and where the old Site Recovery Manager and vSphere Replication names went.
Start with the pillar guide if you want the whole map: the VMware Live Recovery for VCF 9 complete guide. It links every part as it publishes.
« Previous: Part 1 | VMware Live Recovery Complete Guide | Next: Part 3 »
References
Broadcom TechDocs, how the recovery point objective affects replication scheduling
Broadcom TechDocs, recovery plan for Site Recovery Manager and vSphere Replication in VCF
VMware Cloud Foundation blog, recovery improvements with VMware Live Recovery
About The Author
DrJha