Unsolved
This post is more than 5 years old
1 Rookie
•
107 Posts
0
936
restore of NW8.1 storagenodes over the SAN fails in NW7.6 server environment
Hi,
Is there any spefics to look into when using w2008/w2012 storagenodes running NW8.1 while the backupserver is still NW7.6?
In a NW7.6 server environment (migration towards a new server running 8.x is planned as this server will be decommissioned) we experience issues while trying to restore data of Windows 2008R2 and 2012 NW8.1.1.9 storagenodes (*). Backup towards Datadomain VTL (**) goes fine, whereas the restore if the NW storagenode tries to recover its own data over its SAN tapedrives fails. Restore succeeds when defining another (Linux) storage node (running NW7.6) as recover storagenode for these Windows NW8.1.1.9 storagenodes. So recover over the LAN towards these windows systems works.
(*) which according to the NW manual is supported still for a NW7.6 server with NW8.1 storagenodes. Far from ideal and possibly part of the cause but nonetheless the situation we are at.
(**) so not DDboost as server still runs 7.6 and not 8.x therefor we can't use client side dedupe (client direct) yet of connected NW8.x clients (as only NMM3.x supports that in a NW7.6 server environment)
part of the restore logfile:
12/02/14 23:31:30.473296 Recovering files into D:\restore_bb
12/02/14 23:31:30.488906 lgto_auth for `nsrd' succeeded
12/02/14 23:31:30.504540 lgto_auth for `nsrindexd' succeeded
12/02/14 23:31:30.629546 calling clntnsr_start_pools_2_2
12/02/14 23:31:30.629546 lgto_reauth to `BACKUPSERVERNAME' succeeded
12/02/14 23:31:30.629546 calling clntnsr_start_pools_2
Recover start time: 12/2/2014 11:31:53 PM
Requesting 1 recover session(s) from server.
recovering 1 file(s) on rsid 2712615
12/02/14 23:31:53.551647 lgto_auth for `nsrmmdbd' succeeded
12/02/14 23:31:53.614158 lgto_auth for `nsrmmd' failed: busy
12/02/14 23:31:53.614158 direct recover mmd auth failed: busy
53363:recover: Recover of rsid 2712615 failed: busy
73724:recover: One or more recover threads failed to exit successfully
73731:recover: Parent recover thread exited with errors
Received 0 file(s) from NSR server `BACKUPSERVERNAME'
Recover completion time: 12/2/2014 11:31:53 PM
Looked into things like disabling nsrauth (as backupserver has only nsroldauth active for compatability with older clients), hosts file resolving, defining server network interface for tape drives, using empty servers file. Nothing resolved the issue. Backup still works however and can still be recovered by using another system as storagenode.
The direct recover message is also a weird one, as we are performing a local restore of its own data even for the non-clustered standalone system. All of our clients are multihomed as well as our backupserver. So it almost looks as if something is about resolving even though the backup goes fine...
clients are defined with a backup network name plus extension (i.e. systemnamebck). If one starts networkr gui, selects a file for restore it states "from systemnamebck to systemname.xxx.com. systemname.xxx.com is the frontend name of a system, whereas we make the backup via a client definition called "systemnamebck" and also give it a 3rd alias its shortname being "systemname".
ble1
14.3K Posts
1
December 6th, 2014 16:00
8.1 requires nsrauth and the combo you use is asking for trouble. Get versions all synced and it will work.
bbeckers1
1 Rookie
1 Rookie
•
107 Posts
0
December 8th, 2014 07:00
nsrauth mandatory for nw8.1? Would have been easier detected if backup would not have worked... in our case only restore is failing, whereas backup works fine.
Have you tried and really succeeded in specifying a working NW auth method setup as possible options are limited?
We have this in the NW7.6 server:
auth methods: \
"nw8-nmc-server.domain.com,nsrauth",
"yet-another-nw8-nmc-server.yet-another-domain,nsrauth",
"0.0.0.0/0,oldauth";
However as NW does not state with which user ID and from which system one tries to connect (or is it required to run NW in debug mode for that?) to a server from a NMC that tries to manage that backup server, it is not clear at all what to exactly specify so that it fits ones needs. Especially as it also requires a stop/start on the 24/7 busy NW server.
As wild cards are not supported - if I recall correctly - I tried specifying a subnet (by reducing the subnet to just one single host, the NMC server, the NMC server) but never got it to work for the yet-another-nw8-nmc-server.yet-another-domain... Both backupserver and NMC are multi-homed systems which add to complexity to know with what name a NMC reports itself to the backupserver.
I tried to get something working based on the examples as stated in the NW8SP1 manual. I tried the x.x.x.x/32 to reduce it to one single host, where x.x.x.x is the IP address of the NMC server. But in the end it did not work.
– pluto.company.com - An explicit NetWorker client name.
– 10.102.0.0/255.255.0.0 - A subnet IP address representing all NetWorker clients
on the subnet. Alternatively, you could type this value as 10.102.0.0/16.
– 0.0.0.0/0 - This value represents all clients in the domain
I only now see that the command reference guide also shows some examples:
"For example:
The following entries (combined) mean that the host: 10.101.1.1 can use AUTH_NONE, AUTH_UNIX, and AUTH_LGTO to authenticate, anything on the network: 137.69.0.0/16 network can use AUTH_NONE, AUTH_UNIX, AUTH_LGTO,
and RPCSEC_GSS to authenticate, and all other machines must use RPCSEC_GSS to authenticate.
"10.101.1.1,oldauth", "137.69.0.0/16,nsrauth/oldauth", "0.0.0.0/0,nsrauth"
"
So I will have a look at specifying only the IP's (without specific subnet) of the involved w2012 systems to use nsrauth and work from there. Still weird however that the backup still works.
ble1
14.3K Posts
1
December 9th, 2014 04:00
You are complicating too much (and unnecessary). There is nothing complex in multihomed setup - it's nothing exotic in 21st century. Get server updated and get over it.