Disaster Recovery & Business Continuity

Most organizations have some form of VMware disaster recovery: a replication product, a backup platform, a second site or a cloud target. Far fewer can say how long each application would take to come back, how much data it would lose, and in what order things have to start. That gap is where recoveries fail. We design DR around those answers, build it on the platforms you already own or are choosing, and prove it with tests you can show an auditor.

Designing VMware disaster recovery around the business

DR design starts with two numbers per application. The recovery point objective (RPO) is how much data you can afford to lose, measured in time. The recovery time objective (RTO) is how long the application can be down. Everything else, from the product you buy to the bandwidth between sites, follows from those numbers.

Replication or backup-based recovery

There are two broad ways to recover a VMware workload, and most estates need both:

• Continuous replication (Zerto, vSphere Replication, array replication) keeps a copy at the recovery site that is seconds or minutes behind. It suits applications with tight RPO and RTO, at the cost of standing capacity and bandwidth at the recovery site.
• Backup-based recovery (Rubrik and similar platforms) restores from a backup copy, either instantly mounted or fully restored. RPO is the backup interval and RTO depends on how many VMs come back at once. It costs less and also protects against ransomware and accidental deletion, which replication on its own does not.

Choosing between them per application, rather than for the whole estate, is usually where the savings are.

RTO and RPO application tiering

We group applications into tiers so that protection, testing effort and cost match what each application is worth to the business. The table below is an illustration of a typical starting point, not a promise of what any specific environment will achieve. Your tiers come out of the business impact discussion.

Tiering also fixes the recovery order. A tier 1 application that depends on a tier 3 database is really a tier 1 database waiting to be discovered, so dependency mapping is part of the exercise, not an afterthought.

Zerto consulting

Zerto replicates VMs continuously at the hypervisor level and keeps a journal of changes, so you can recover to a point in time seconds before an outage or before ransomware hit, rather than only to the latest copy. Our Zerto work covers:

• Virtual Protection Groups (VPGs) built around applications, so every VM an application needs is recovered to the same consistent point.
• Boot order and delays inside each VPG, so databases are up before the application servers that connect to them.
• Re-IP and network mapping for recovery and test networks, where the recovery site uses different address ranges.
• Journal sizing and recovery-site storage, matched to the history each tier needs.
• Test failover, Move and Failover: when to use each, and how to run a test into an isolated network without touching production.

Rubrik implementation

Rubrik is the backup-based half of many recovery designs. We plan and configure it so that backups are not only taken but recoverable at the speed the tiers require:

• SLA policies per tier: frequency, retention, replication to a second cluster or cloud archive.
• Instant recovery and Live Mount to bring a VM back by running it from the backup while the full restore happens behind it.
• Orchestrated recovery for multi-VM applications, with ordering and checks, where your licensing includes it.
• Immutable copies and access control, so the backups survive the same incident that took down production.

DR testing that proves something

A DR plan that has never been tested is a hypothesis. We plan and run tests that answer specific questions: did each application come back inside its RTO, to a point inside its RPO, and did the people running the test have what they needed?

• Non-disruptive tests into isolated networks, so production keeps running and users never notice.
• A clear scope for each test: which tiers, which applications, what counts as success and who signs off.
• Evidence: timings, screenshots and sign-offs collected into a test report you can hand to auditors or insurers.
• A lessons-learned loop: every gap found becomes a fix in the design, the runbook or the tooling before the next test.

DR runbooks your team can follow

When a real disaster happens, the person running recovery may not be the person who designed it, and they may be doing it at 2 a.m. A usable DR runbook contains:

• Who declares a disaster, who is contacted, and how decisions are recorded.
• The recovery order by tier and application, with the dependencies that drive it.
• Step-by-step procedures for each recovery method, with expected results at each step.
• Validation checks per application, and who confirms it is working.
• Failback: how to return to the primary site once it is healthy.

The dependencies that break recoveries

Recovered VMs that boot but cannot authenticate or resolve names are not recovered. We design and test the supporting pieces explicitly: DNS and Active Directory availability at the recovery site, networking (stretched or re-addressed subnets, firewall rules, load balancers, external DNS records), certificates, and licensing for operating systems, applications and VMware itself at the recovery site.

How a DR engagement runs

1. Assess: inventory applications and dependencies, agree tiers and RPO/RTO with the business, and review what is protected today.
2. Design: protection method per tier, recovery-site capacity, network design and tooling choices.
3. Build: configure Zerto, Rubrik or your chosen platform, protection groups and SLA policies.
4. Test: a first non-disruptive test with evidence and a gap list.
5. Document and hand off: runbooks, test reports, and a testing schedule your team can keep running.