VMware SRM for Healthcare DR in the Philippines: A Practical Guide
Healthcare IT in the Philippines faces a unique set of constraints: unreliable power, typhoon season, strict data privacy rules under the Data Privacy Act of 2012, and limited budgets compared to Singapore or Hong Kong. We have helped three Philippine hospitals build disaster recovery using VMware Site Recovery Manager (SRM). This guide reflects what actually works in that environment.
Why SRM Fits Philippine Healthcare
Most Philippine hospitals run VMware vSphere on-premise. Public cloud DR is attractive on paper but often fails in practice because: - Internet uplinks are not reliable enough for synchronous replication - Latency to cloud regions (Singapore, Hong Kong) adds recovery complexity - Recurring cloud egress and compute costs are unpredictable - Data residency concerns remain despite cloud certifications
SRM with a secondary site in the same metropolitan area provides a practical middle ground: recoverable within hours, with data staying in-country and under direct control.
The Reference Architecture
| Component | Primary Site | Secondary Site |
|---|---|---|
| vSphere version | 7.0 U3 | 7.0 U3 |
| Hosts | 4 x Dell PowerEdge | 2 x Dell PowerEdge |
| Storage | SAN replication (Async) | Matching SAN |
| Network | 1Gbps WAN to secondary | 1Gbps WAN to primary |
| SRM | 8.6 | 8.6 |
| Recovery point objective | 1 hour | — |
| Recovery time objective | 4 hours | — |
The secondary site is typically another hospital branch, a shared medical facility, or a colocation cabinet in Metro Manila.
Step 1: Define Protected Workloads
Not every VM needs DR. For a 250-bed hospital, our typical protection group includes:
| Priority | Systems | RPO | RTO |
|---|---|---|---|
| Critical | HIS, PACS database, AD, DNS | 1 hour | 4 hours |
| High | EMR application servers, file servers | 4 hours | 8 hours |
| Standard | Print servers, dev/test, monitoring | 24 hours | 48 hours |
Patient-facing systems (HIS, EMR, PACS) get protection plans. Back-office systems get lower priority or no DR.
Step 2: Storage Replication
We use array-based replication rather than vSphere Replication for two reasons: - It offloads replication processing from ESXi hosts - It preserves storage snapshots and consistency groups
Our standard configuration: - Consistency group: HIS DB + HIS App + PACS DB grouped together - Replication schedule: Every 60 minutes for critical, every 4 hours for high - Snapshot retention: 24 hourly + 7 daily at the secondary site - Bandwidth requirement: ~200 Mbps sustained for a typical 10 TB protected set
Step 3: Network Mapping
SRM network mapping translates production port groups to recovery port groups. For hospitals, we map:
| Production Network | Recovery Network | Notes |
|---|---|---|
| HIS-Prod | HIS-DR | Same subnet, stretched L2 via MPLS |
| PACS-Prod | PACS-DR | Same subnet |
| Management | Management-DR | Out-of-band access |
| Guest Wi-Fi | Not mapped | Not recovered |
IP customization is kept to a minimum. Changing IP addresses during a disaster adds confusion and extends RTO.
Step 4: Build Recovery Plans
A recovery plan is more than a VM boot order. For the critical group, our plan includes:
- Power off protected VMs at primary (if still running)
- Promote secondary storage snapshots
- Register VMs at secondary site
- Power on in sequence:
- Domain controllers and DNS first - HIS database second - HIS application servers third - PACS database fourth - PACS viewers last 5. Run custom scripts to update DNS records 6. Send notification to IT and clinical operations
Total manual steps: zero, after the initial trigger.
Step 5: Test, Test, Test
We run two types of tests:
Planned migration test (quarterly): Move workloads to secondary in an orderly fashion, verify clinical apps function, then move back.
Disaster recovery drill (twice yearly): Simulate primary site loss, execute recovery plan, verify patient data access and PACS image retrieval.
Each test produces a report with: - Actual RTO vs target - Data integrity checks - Application sign-off - Issues and remediation items
Compliance and Documentation
Under the Philippines Data Privacy Act of 2012, DR plans must document: - Where personal health information is stored at all times - Who can access it during a disaster - How it is protected during transfer and at rest - How long it is retained at the secondary site
We keep an SRM runbook with: - Network diagrams - Recovery plan ownership - Vendor contact numbers - Decision tree for declaring a disaster
Common Philippine-Specific Challenges
| Challenge | Solution |
|---|---|
| Power instability at secondary site | UPS + generator with 8-hour minimum runtime |
| Limited WAN bandwidth | Compress at array level; schedule replication during off-peak hours |
| Typhoon season | Pre-stage recovery before forecasted severe weather |
| Small IT teams | Use SRM automation; avoid manual runbooks beyond initial trigger |
| Budget constraints | Protect only critical systems; use shared secondary facility |
Cost Reality
For a 250-bed hospital with 40 protected VMs, expect: - SRM license: ~$15,000–$25,000/year - Secondary site colocation: ~$800–$1,500/month - WAN link: ~$500–$1,000/month - Professional services for initial setup: ~$20,000–$35,000
Compared to a major outage during peak admissions, this is inexpensive insurance.
Bottom Line
VMware SRM works well for Philippine healthcare when the architecture is kept simple: a secondary site in-country, array-based replication, clear recovery priorities, and regular testing. The technology is only half the solution — the other half is a documented, rehearsed process that clinical and IT staff understand.
Want to go deeper? Explore VMware alternatives, Run infrastructure services, or platform comparison.