10-11-2012 11:48 AM
Hi,
Solved! Go to Solution.
11-18-2012 07:24 PM
Wondering why do you rely on NBU to clone your VMs when you have that feature in VMware / Hyper-V itself
10-11-2012 12:47 PM
I have not tried the way you asked, but I have a suggestion for your need (to refresh the Dev and QA from Production VM):
1. Assuming that you have the DB or release codes on different drives (for example, D:\) than of the boot drive (C:\), then you can configure the NBU backup policy to exclude the boot disk in "virtual disk selection" so only the data drives are backed up. You can configure another NBU policy to back up the boot disk only (exclude the data disks) so you still can protect the whole VM.
2. Restore the data drives to the Dev and QA servers to refresh these non-production environments. Now you don't have to restore the whole VM and worry about changing the UUID, etc.
10-11-2012 05:13 PM
You can restore VM with different UUID unless you check 'Restore BIOS UUID "xxxx" intead of creating a new UUID' at restore.
Of course, you can set different display name.
11-18-2012 07:24 PM
Wondering why do you rely on NBU to clone your VMs when you have that feature in VMware / Hyper-V itself
12-19-2012 04:49 PM
You're right Captain, at the end I wasn't able to test the NetBackup restore. The VMware administrator cloned the virtual machine and that was enough to resolve the issue.