I just had a tech jump in and take a look at my configuration. Although i did have a few instances of the vadp backup systems, they did infact have the same ID. The issue was that under Gloabal2 SYSTEM@(VADPSERVER) was not sufficient as far as permissions went. once he configured it as *@VADPSERVER the savesets apeared within the VADP networker user list. Also, if you are using a VADP proxy it is absolutely supposed to be launched from the VADP proxy (as long as its also a storage node). changing system to * allowed the networker user on the VADP system to see the save sets.
AFAIK, the 'recover storage node' attribute of the client that you are recovering should define which Storage Node is being used for the recover operation. I'm not sure why it's not working for you. Is there only one VM affected by this or all of them? You should check your name resolution aswell to be sure that the entry in that field is being correctly resolved.
As this is a new deployment and i have been concentrating on getting the backups functional, this was the first full vm restore i have done. The rest are actual systems and i dont care to delete their datastores if i cannot restore them in under 2 days .
here is a screencap of the config for the test system im working with. the VADP storage node local to the home office is the VUSVADP02 as listed in the storage node and recover storage nodes.
I had a look at the documentation and neither of the two conditions that override the 'recover storage node' field are met in this scenario (read hostname field for a jukebox, and a volume already being mounted on another storage node). If I were you, I'd test the non-VADP behaviour if you can to see if what you are seeing is specific to VADP. Also, you could try changing the 'recover storage node' field of the NetWorker server's client instance and the proxy's client instance just to see if this changes the behaviour. It might give you a better understanding of what's going on.
I did a redirected restore from the networker server. i had it restore a 3Gb iso image from one system and applied it to another. it flew by in about 25 seconds at 40mbps (ish).
just for fun, once i have an opportuinity to try the restore again, i will set the recovery storage node to the physical node at the home office and see if that gives me any changes.
Well changing the restore node to the physical node for VADP did nothing.
I want to ask a different question here. Under the manual i saw that it said "restoring to virtual center server". Well our virtual center server is across the WAN connection to our datacenter. the ESXI hosts in our dev environment are at our home office... shoudl i be attempting to restore this in a different manner? EG is there a way to push it directly onto the ESXI host or datastore?
NetworkSupport-
61 Posts
0
July 31st, 2012 12:00
Ok,
I just had a tech jump in and take a look at my configuration. Although i did have a few instances of the vadp backup systems, they did infact have the same ID. The issue was that under Gloabal2 SYSTEM@(VADPSERVER) was not sufficient as far as permissions went. once he configured it as *@VADPSERVER the savesets apeared within the VADP networker user list. Also, if you are using a VADP proxy it is absolutely supposed to be launched from the VADP proxy (as long as its also a storage node). changing system to * allowed the networker user on the VADP system to see the save sets.
coganb
736 Posts
0
July 26th, 2012 04:00
Hi,
AFAIK, the 'recover storage node' attribute of the client that you are recovering should define which Storage Node is being used for the recover operation. I'm not sure why it's not working for you. Is there only one VM affected by this or all of them? You should check your name resolution aswell to be sure that the entry in that field is being correctly resolved.
-Bobby
NetworkSupport-
61 Posts
0
July 26th, 2012 05:00
As this is a new deployment and i have been concentrating on getting the backups functional, this was the first full vm restore i have done. The rest are actual systems and i dont care to delete their datastores if i cannot restore them in under 2 days
.
here is a screencap of the config for the test system im working with. the VADP storage node local to the home office is the VUSVADP02 as listed in the storage node and recover storage nodes.
coganb
736 Posts
0
July 26th, 2012 06:00
I had a look at the documentation and neither of the two conditions that override the 'recover storage node' field are met in this scenario (read hostname field for a jukebox, and a volume already being mounted on another storage node). If I were you, I'd test the non-VADP behaviour if you can to see if what you are seeing is specific to VADP. Also, you could try changing the 'recover storage node' field of the NetWorker server's client instance and the proxy's client instance just to see if this changes the behaviour. It might give you a better understanding of what's going on.
-Bobby
NetworkSupport-
61 Posts
0
July 26th, 2012 07:00
Good idea,
I did a redirected restore from the networker server. i had it restore a 3Gb iso image from one system and applied it to another. it flew by in about 25 seconds at 40mbps (ish).
just for fun, once i have an opportuinity to try the restore again, i will set the recovery storage node to the physical node at the home office and see if that gives me any changes.
NetworkSupport-
61 Posts
0
July 26th, 2012 08:00
Well changing the restore node to the physical node for VADP did nothing.
I want to ask a different question here. Under the manual i saw that it said "restoring to virtual center server". Well our virtual center server is across the WAN connection to our datacenter. the ESXI hosts in our dev environment are at our home office... shoudl i be attempting to restore this in a different manner? EG is there a way to push it directly onto the ESXI host or datastore?