Disaster Recovery Services (DR)

Disaster recovery services from Consult Circle: DR design and deployment, VMware Live Site Recovery upgrades from SRM, DR reviews and test failovers that turn a documented plan into evidence.

Speak to our team 0203 916 5593

Most disaster recovery estates we are asked to look at are not broken. They are out of date - designed correctly for an estate that has since changed, with recovery plans carrying stale mappings and objectives nobody has revalidated with the business in years. We design, review, deploy and test disaster recovery on VMware, centred on VMware Live Site Recovery (formerly Site Recovery Manager).

Need a second opinion on your DR design?

Book a free 30 minute call. We'll review your current design, replication choice and test evidence - it is a short conversation and it usually surfaces something.

Book a FREE 30 Minute Call 0203 916 5593

Our disaster recovery services

DR Design & Deployment

Topology, replication selection, sizing and placement for VMware Live Site Recovery - protection groups and recovery plans structured around business services rather than storage layout.

DR Review & Health Check

A self-contained review of an existing DR estate: stale inventory mappings, protection group sprawl, untested plans and the gap between stated and achievable recovery objectives.

SRM to Live Site Recovery Upgrade

Upgrades into the VMware Live Site Recovery 9.0 stream, with a known good pre-upgrade test failover baseline, protection group consolidation and post-upgrade test evidence.

DR Testing & Evidence

Scheduled test failovers with application owner participation, recorded with a date and a name, so recovery capability is demonstrated rather than documented.

What a good DR solution looks like

A disaster recovery design fails in one of two ways. It fails loudly, when the recovery does not run, which is rare and obvious. Or it fails quietly, when the recovery completes and delivers an environment nobody can use - which is common, and only discovered during an invocation. A good solution is built to remove the second failure mode.

Objectives set by the business, not by infrastructure

Recovery point and recovery time objectives that differ by service, agreed with the people who own the service, and revalidated rather than inherited from a policy document.

A replication choice that matches the protection profile

Array-based, host-based or Virtual Volumes replication chosen deliberately. Datastore-level granularity on an estate where only a fraction of workloads need protecting is the most common and most expensive design error.

Protection groups that mirror business services

Groups that fail over together because the service does, not because of a scale limit that no longer applies or a storage layout from six years ago.

Recovery plans a stranger can run at 3am

Ordered by dependency, honestly tiered, with roles rather than names, pauses that exist for a reason, and application validation steps built in.

Inventory mappings that are maintained

Networks, folders, resource pools and storage policies drift at both sites. Mapping review belongs in the change process, because stale mappings are the leading cause of a failover that completes and delivers an unreachable environment.

Evidence, not assertions

Every plan tested on a schedule, failback exercised periodically, results recorded with a date and an owner sign-off.

A separate answer for ransomware

Replication reproduces malicious change faithfully. Site recovery and cyber recovery solve different problems and both need a position.

Dependencies outside the plan accounted for

Identity, DNS, certificate services, monitoring and the DR management components themselves. A plan that assumes those are available is a plan that has not been tested honestly.

Things to look for in your own estate

If several of the following are true, the DR capability you publish is probably not the one you could deliver.

Nobody can answer, per plan, when the last successful test failover ran
Recovery objectives were last reviewed with the business more than two years ago
Protection group structure was shaped by historic scale limits or storage boundaries
Callout scripts reference paths on rebuilt servers or people who have left
The recovery site was never sized for the performance the business expects
Ransomware recovery and site recovery are treated as the same capability
DR management components would be lost with the protected site
Only the plan the team is confident about ever gets tested

VMware Live Site Recovery

Site Recovery Manager was rebranded as VMware Live Site Recovery and brought, alongside the former Cloud Disaster Recovery, under the VMware Live Recovery family. The lineage, architecture and recovery plans continued; the licensing moved to subscription and the 9.0 release stream raised the protection group limit to 1500 virtual machines and added stretched storage and Virtual Volumes support. We plan upgrades into that stream, consolidate protection group structures where the current limits allow, and run the pre and post upgrade test failovers that make any problem attributable.

Where DR sits inside a wider platform programme, this work runs alongside our VMware Cloud Foundation services. For the documentation, risk assessment and business impact analysis side, see our BC/DR planning service.

Disaster recovery guides

In-depth guides on designing, upgrading and proving a VMware disaster recovery capability.

Talk to a disaster recovery specialist

Tell us about your current DR platform, recovery objectives and when you last tested - we'll come back within one working day.

Already have a DR design you want stress tested?

We review designs built by internal teams and run the test failovers that establish whether the published objectives are achievable.

Get DR help 0203 916 5593

Talk to us about disaster recovery services (dr)

Book a free 30 minute call and we'll review your requirement, the risks and the realistic route forward.

Book a FREE 30 Minute Call