Strange SRM Use Case

Today we had rather a strange request, which was resolved by ‘thinking outside of the box’ using Site Recovery Manager.

Scenario

Client required an exact copy of an 8TB VM to be available in an alternate location over 50km away.  I’m not exactly sure why, but we had been explicitly told that the VM could not be logged into, so this ruled out using any items inside the VM such as robocopy.  Another constraint was that the original VM had to stay in it’s same location and it needed to be accessed by the in house IT team in the alternate location!

The engineer working on the ticket, originally used Veeam to restore the VM from backup which was fine, but we couldn’t alter the original backup files, therefore a restore to an alternate device at the same location seemed the next logical step.  The only downside was we only had the spare capacity to bring the VM up on the NAS it was backed up to, which meant two things:

1. It was thrashing the disks as it was reading the backup files, and then writing the restore, plus it then had to deal with the normal Veeam backup duties.
2. The VMDK’s still needed to be copied from the NAS onto removable media, taken to the alternate location and copied onto the target device and then booted up as a new VM.

With the above in mind, the engineer gave me a call and asked if we could do something with SRM!

Solution

We know the VM could not be accessed and that trying to restore from backup wouldn’t meet the clients time requirements, so we discussed using SRM.

The VM in question was protected by SRM and is replicated on a 15 minute basis.  So the plan was to

1. Run a Test Failover creating a Read/Write snapshot of the Read Only copy in the target location in an isolated environment.
2. Shutdown the Read/Write copy and copy the VMDK’s to another datastore.
3. Create a new VM and attached VMDK’s

The first step worked like a dream, however we received an error when trying to copy the VMDK’s to another datastore ‘the specified key, name, or identifies already exists’.  We thought about removing the VM from inventory and re-adding it back again, but didn’t know the risks in terms of SRM cleanup.  We knew we could force a cleanup, but knowing the sensitive case of the request we couldn’t afford any unknown errors.

Instead we decided to ‘clone the VM’, once completed we disabled the NIC, changed the server name and IP address.

It worked, everyone was happy in the ‘ranch’ and we used SRM for a different purpose than intended.  Understanding how something work’s makes the difference to putting forward solution to resolve a time sensitive problem.