Replicaton on Redirect Disk IR VM

[smile_dav]

I have been working closely with Veeam support and we have discovered another bug for version 6. Case#5181411
When moving the IR VM (with redirect disk enabled) back to the production environment using replication, we experienced the following issue:

Creating helper snapshot error: unable to access file..........etc

Support has told me they have been able to reproduce this error in their lab.
My guess is because the .vmx is not in the working directory, a different directory than the .vmdk, Veeam tells VMware to create a snapshot at the wrong place, therefore VMware returns an error saying it fails to create a snapshot and so does Veeam. But this is my pure guess, support said they are on it, but it won't be fixed until the next version.

Luckily, we were testing all the possible scenarios and quickest ways to recover for an IR VM, and we were eager to get this working as this would really reduce the downtime needed for the client to move back to the production environment and at the same time take some of the loading off the backup repository when IR-ing, i.e. do a full replication during normal backup window and schedule for downtime, perform an incremental backup before failing over to the replica which is located on the production site.

Without redirect disk change, replication for IR VM works fine, only when it's enabled that this error occurs.
All in all, our testing indicates that if you have many backups in the same repository, IR-ing them all at the same time will most likely give you poor performances, so poor that you might be better off restoring it in full in the first place.

[Gostev]

Yep, you definitely do not want to run lots of VMs from the same vPower NFS server at once. Instant VM Recovery is definitely not a replacement for replication, which is what you want to use to be able to perform large-scale recoveries, such as all VMs belonging to one customer at once. I see this as an extra service you should charge your customers premium for.

This is how I would do this:

"Full VM Recovery" service (uses basic full VM restore)
- RTO = X hours
- no per-month fee

"Instant VM Recovery" premium service (uses Veeam Instant VM recovery)
- RTO = X minutes
- limited to up to Y VMs at once, I/O throttled for up to Z hours
- $ per-month fee to enable option, flat fee no matter of the number of protected VMs

"Instant multi-VM recovery" premium service (uses Veeam Replication)
- RTO = Y minutes
- no limits on amount of recovered VMs, I/O is not throttled
- $$$ per protected VM per month (to justify standby storage costs)

You can also charge for actual recoveries beyond certain amount per months, of course - as each recovery requires admin work.

[mit.extrico]

Hi

I have the same problem when replicate servers from one destination to another. I just want to know. Did the upgrade from version 6 to version 6.5 solved the issue ?

[Vitaliy S.]

Hi Michael, let me check it with our R&D team. I will update this topic once I have more information.