01-30-2020 01:58 AM
Hello all,
1)My NetBackup vesion: 8.2 Operating System : windows server 2019
2)client Operating System : windows server 2012
I want to restore rename vm to hyper-v server,but I am facing an issue during the recovery of vm .
C:\Veritas\NetBackup\bin\admincmd>bpsetconfig -h win233
bpsetconfig> BPCD_WHITELIST_PATH=\C:\testt
bpsetconfig> ^Z
C:\Veritas\NetBackup\bin>nbrestorevm.exe -vmhvnew -C NBUtestVM01 -S win226 -vmserver win233 -vmid -R \C:\testt
Restore image time = 01/30/20 13:44:57
VM restore request returned with status = 6000
EXIT STATUS 6000: The provided path is not whitelisted.
How to solve this problem?
Thanks,
Angus
01-30-2020 02:45 AM
Hello,
review yout nbrestorevm syntax:
- you have allowed whitelist path on win233, but -R path is related to the server from where you call nbrestorevm
- is C:\testt rename file? Looks like restore destination.
Regards
Michal
01-30-2020 09:56 PM
- is C:\testt rename file? Looks like restore destination.
Yes,I want to restore rename VM on win233. C:\testt is on win233.
I try to restore rename new VM on win233,and dont overwrite original VM.
Do you have any ideas ?
Thank you.
01-30-2020 11:45 PM
@Michal_Mikulik1 has already said to you:
"review your nbrestorevm syntax"
.
Your command is wrong. See some notes re syntax here:
https://www.veritas.com/content/support/en_US/doc/21357025-130334382-0/v93105983-130334382
02-02-2020 03:21 AM
Hello sdo,
I have execute nbrestorevm as per suggested. Here is the output:
C:\Veritas\NetBackup\bin>nbrestorevm -vmhvnew -C NBUtestVM01 -R \C:\testt\newvm
Restore image time = 01/30/20 13:44:57
VM restore request returned with status = 6000
EXIT STATUS 6000: The provided path is not whitelisted
Output the same situation from this.
File content is
change /C/ProgramData/Microsoft/Windows/Hyper-V/Virtual Machines/BC8775FC-DEEC-4A35-8737-816ABB5858BD.xml to /C/testt/BC8775FC-DEEC-4A35-8737-816ABB5858BD.xml
change /C/ProgramData/Microsoft/Windows/Hyper-V/Virtual Machines/BC8775FC-DEEC-4A35-8737-816ABB5858BD/BC8775FC-DEEC-4A35-8737-816ABB5858BD.bin to /C/testt/BC8775FC-DEEC-4A35-8737-816ABB5858BD/BC8775FC-DEEC-4A35-8737-816ABB5858BD.bin
change /C/ProgramData/Microsoft/Windows/Hyper-V/Virtual Machines/BC8775FC-DEEC-4A35-8737-816ABB5858BD\BC8775FC-DEEC-4A35-8737-816ABB5858BD.vsv to /C/testt/BC8775FC-DEEC-4A35-8737-816ABB5858BD/BC8775FC-DEEC-4A35-8737-816ABB5858BD.vsv
change /C/Users/Public/Documents/Hyper-V/Virtual hard disks/NBUtestVM01.vhdx to /C/NBUtestVM01.vhdx
Thank you
02-02-2020 04:16 AM
Maybe try this:
1) change the name of the rename file to C:\testt\rename.txt
2) dir C:\testt\
3) setup the bpcd whitelist using :
BPCD_WHITELIST_PATH=C:\testt
BPCD_WHITELIST_PATH=C:\testt\
BPCD_WHITELIST_PATH=C:\testt\rename.txt
4) try the restore with this command:
nbrestorevm -vmhvnew -C NBUtestVM01 -R C:\testt\rename.txt
02-02-2020 05:25 AM
Hello sdo,
Here is the output:
C:\Veritas\NetBackup\bin>nbrestorevm -vmhvnew -C NBUtestVM01 -R C:\testt\newvm.txt
Restore image time = 01/30/20 13:44:57
VM restore request returned with status = 2
EXIT STATUS 2: none of the requested files were backed up
But I already backup up for this VM.
Thank you very much.
02-02-2020 10:17 AM
Ok - you need to look at the nbrestorevm log for starters:
Logs for troubleshooting the nbrestorevm command
https://www.veritas.com/content/support/en_US/doc/21902280-127283730-0/v89994458-127283730
02-03-2020 12:03 AM
02-03-2020 06:08 AM
My restore was failing because:
1) I was using the "-vmhvnew" switch
2) and my Hyper-V version on 2012 R2
3) and the original backup was VSS based
4) and the VM still existed
...i.e. the restore was failing because NetBackup does not feature assigning a new GUID at restore time for these older style VSS based backups (only the newer WMI style VM backups can have a new GUID assigned/allocated at restore time).
So, when I changed my command from using "-vmhvnew" to "-vmhvstage" then my restore to an alternate location worked, and this must be because NetBackup was now not attempting to register the VM in the Hyper-V cluster.
Anyway, that was my journey.
.
@AngusChiu did you manage to inspect the logs to identify the error?