Restoring VM with newly added disks - a heads up

[cby]

Hopefully you won't have to go through the same problems I experienced when trying to restore a VM using Veeam.

We have a RHEL5 VM with a number of disks and created a Veeam backup job. Test restores went fine. We then needed to add a further two disks to the VM -- one disk was on the SAN fibre storage the other on FATA. The backup went through without problems. However, the VM restore was not successful. I was able to restore files through FLR. The two recently added disks were not recognised in the Virtual Infrastructure Client -- I won't go into detail but the VIC got very confused over the two disks.

A support call was left with Veeam and after several weeks there was still no apparent resolution. I amended the VMX file, renamed the VMDKs even tried re-entering the disk properties in VIC. All to no avail. Another suggestion was to create a new backup job which was easier than it sounds when disk space is tight (we're talking 360GB VM) and you don't want to remove the old production backups with rollbacks. Anyway, net result, by creating a new backup job I managed to successfully restore the VM with the recently added disks,

Lesson seems to be that adding disks to a VM that is the subject of an existing backup job does not guarantee a proper restore. You need to create a new job -- unless Veeam come up with a fix.

[Gostev]

Yes, this sound like a bug. I will make sure it is logged on our bug tracker.Thanks!

[Gostev]

I just checked with QC, and this scenario is covered by corresponding tests, so there should not be any issues with that. They also did reproduce your scenario based on information from your log files, and could not confirm the issue in our lab. May be we are missing something important, do you have some kind of VM modification history (sequence of actions)? If you are using Veeam Reporter Enterprise installed, you can get VM changes report from it.

Bottom line - in most cases, this scenario should be correctly handled by Veeam Backup, without resulting in any problems. There's also seems to be a bug with certain sequence of actions and/or VM configuration, but we are currently unable to reproduce it internally.