SharkOps
Case Study · Disaster Recovery

Automated VM Protection through Zerto for Disaster Recovery

An API-driven framework that automates disaster recovery management across thousands of virtual machines — eliminating manual DR processes, reducing human error, and optimising infrastructure cost.

Dhirendra Kashyap, DevOps Engineer 18 July 2025 8 min read
1000s
VMs Protected
100%
API-Driven
1-Cmd
Docker Deploy
Zero
Manual Steps
Back to Case Studies

The Challenge

The client needed a fully automated, scalable solution for Virtual Machine (VM) disaster recovery using Zerto. For a large enterprise running thousands of VMs across distributed systems, managing DR protection is a quietly painful problem — every step required human attention, making the process slow, error-prone, and difficult to audit. The existing process suffered from:

No Real-Time VM Protection Tracking

  • No visibility into protected / unprotected VMs.
  • Manual checks led to delays in DR readiness.

Manual Data Collection & Processing

  • Teams manually extracted VM protection status from Zerto.
  • Error-prone and time-consuming.

No Automated Deployment Mechanism

  • Lack of auto-protection for new VMs.
  • Untagged / unused VMs were not removed, increasing costs.

Additional Technical Hurdles

  • Finding VPG IDs dynamically for bulk operations.
  • Handling thousands of unprotected VMs efficiently.
  • Integrating multiple Zerto APIs to fetch VM metadata.
  • Destroying untagged / unused VMs via API automation.

Tech Stack

  • Python — scripting & automation.
  • Docker — containerisation & deployment.
  • Zerto API — VM protection & DR management.
  • RESTful APIs — data extraction & processing.

The Solution

SharkOps' DevOps engineer Dhirendra Kashyap developed a Python-based automation framework leveraging Zerto's APIs to handle DR protection at scale.

1. Automated VM Discovery & Protection

  • Fetch real-time VM protection status via Zerto APIs.
  • Identify unprotected VMs and auto-add them to Virtual Protection Groups (VPGs).
  • Bulk protection for thousands of new VMs.
Zerto API — VM discovery
HTTP 
GET /v1/vms
# Get information about protected virtual machines.
# Supports filtering with additional query parameters.

GET /v1/virtualizationsites/{siteIdentifier}/vms
# Get the list of unprotected VMs at the site.

2. API-Driven Data Processing

  • Multi-API integration to collect VM metadata, VPG IDs, and DR status.
  • Automated parsing & filtering to classify protected / unprotected VMs.
Zerto API — VPG metadata
HTTP 
GET /v1/vpgs
# Get information about all VPGs.

GET /v1/vpgs/{vpgIdentifier}
# Get information about a specific VPG.

GET /v1/vpgSettings
# Get all VPG settings.

3. Dockerized Deployment

  • Containerised solution for portability & scalability.
  • One-command deployment to trigger protection workflows.
docker run --rm -e ZERTO_HOST=<host> -e ZERTO_TOKEN=<token> sharkops/zerto-dr-automation

4. Cleanup of Unused VMs

  • Automated detection of untagged VMs.
  • API-driven destruction to optimise resources.

Architecture

The framework sits as a control plane on top of Zerto's APIs and the hypervisor inventory. A scheduled worker reconciles "desired state" (protection policy as code) against "actual state" (what Zerto currently protects) across the Production and DR sites — and converges the two using the Zerto Virtual Manager (ZVM), Virtual Replication Appliances (VRAs), and the failback channel between sites.

Zerto disaster recovery architecture — Production Site with vCenter, ZVM, VMs, and VRAs replicating across the failback channel to the DR Site with Mgmt, ZVM, VMs, and VRAs
Production Site (vCenter + ZVM + per-host VRAs) replicating VMs over a failback channel to the DR Site (Mgmt + ZVM + per-host VRAs). The Python framework orchestrates protection and cleanup across both sites via the Zerto APIs.
  1. Discovery — query hypervisor inventory and Zerto site endpoints to enumerate VMs and metadata (business unit, criticality tags).
  2. Reconciliation — compare against Zerto's VPGs and decide what to add, update, or remove.
  3. Action — issue Zerto API calls to protect new VMs, update existing protection settings, or unprotect retired ones.
  4. Reporting — emit structured logs and metrics so SREs can see DR coverage at a glance.

Benefits

  • Fully Automated DR Process — eliminated manual checks & human errors.
  • Real-Time VM Protection Tracking — instant visibility into protected / unprotected VMs.
  • Scalable for Large Environments — handled thousands of VMs efficiently.
  • Cost Optimisation — automated cleanup of unused / untagged VMs.
  • Consistent Deployment — Docker ensured repeatable execution across environments.

Results

With the framework in place, the client's VM estate maintains constant DR readiness with effectively no human effort. Operations teams moved from "configure DR by hand" to "review exceptions only" — a much healthier mode of work.

  • VM landscapes stay in a constant DR-ready state.
  • Operational overhead for DR onboarding / offboarding dropped to near-zero.
  • Infrastructure cost is optimised because retired VMs are cleaned up promptly.
  • The Dockerised model means the framework can be rolled out to any environment in minutes.

Lessons Learned

While the solution was technically successful, project delays impacted client satisfaction. Key takeaways:

  • Early Risk Assessment — identify API limitations & scalability issues upfront.
  • Clear Timeline Alignment — set realistic deadlines for API integrations.
  • Ownership & Communication — regular stakeholder updates to manage expectations.
  • Testing at Scale — simulate thousands of VMs to ensure performance.

Technology Stack

Python

Docker

Zerto (HPE)

RESTful APIs

Key Takeaway

Disaster recovery is one of those areas where manual work feels normal — until you operate at the scale of thousands of VMs and the gaps start hurting. Treating DR as an automated, reconciled, code-driven workflow is the only path that scales. The Zerto + Python + Docker combination gave us a clean way to deliver that without changing how the client thinks about their DR policy.