I am implementing a new backup infrastructure based on BackupExec 2012 for one of our clients and am facing an issue.
I am testing various backup methods and options and one of those is the complete restore of a VM, just like after a catastrophic san failure for example.
To do so I configured a test lun, created a datastore on this lun and created a test VM on this LUN.
I configured this VM with specific settings, such as a manual configured MAC address, 4vCPUs and in the VM bios I configured a management bios password and enabled a serial port. Finally I made some tweaks in the advanced settings options. For example I used the parameter cpuid.coresPerSocket to create a 1vCPU 4 core VM.
After this a full backup of the VM was made and with this successfully completed I deleted the VM completely and then I restored it on the original location.
When I examined the VM it seemed a good restored VM. It booted and everything seemed ok, but after some closer inspection I noticed it was not 100% the same as the original. The VM settings like the MAC address and the number of vCPUs seemed right, but the alterations of the BIOS and the advanced settings are gone.
This means a full backup is really not a full backup.
Compatitive products like Veeam Backup & Replication don't seem to suffer from the same problem, so it is not a VMware API issue that is preventing the complete configuration of a VM to be backuped.
Since we have many VMs to protect with some of them containing specific settings we want to be able to TRUST the backup application. A restore of a FULL VM backup must be EXACTLY 100% the same as the backup and not 99%!
Can someone confirm this is a BackupExec 2012 (SP1) "feature" or is it a bug that will be solved with a hotfix soon?
Can't answer for all of the settings, however Plug and Play within the operating system of the virtual machine will often detect the restore (especially a redirected restore) as a change in Physical Network interface, resulting in DHCP being assigned to what it sees as a "new interface" the registry of the server will still contain your manual defined network settings - but as it does not detect the same card any longer they are in effect againts offline hardware. You can sometimes see this same effect if you copy a virtual machine from one VMware environment to another (where only Vmware utiltities are used) and no backup product
I suspect that any hardware managed by plug and play could do the same thing and of course what this means is we have restored the settings but they are not active as they are registered against offline hardware. Note: Symantec cannot be responsible for how Plug and Play and the VMware environment interacts after a restore.
I am aware of these possible reactions.
My issues are pure BackupExec related. The restored VM is NOT the same as the original and that is weird for a backup solution.
It seems you guys at Symantec now realise the impact of this problem.
The case is escalated all the way up to enginering.
It seems the VMX file is altered only when restoring to vCenter of ESXi directly.
The NVRAM file is completely skipped during backup.
I hope the problems are fixed soon. To me it is unacceptable for a backup application that it doesn't backup everything without notifying me.