Start a Conversation

This post is more than 5 years old

Solved!

Go to Solution

3956

March 10th, 2014 17:00

Networker Upgraded to 8.1.1 NetApp NDMP dump proxy save no longer works

I have upgraded our networker from 7.4.5 to 8.1.1.2 this past few weeks, with the inclusion of upgrading the OS from win2003 to win2008. While it was on win2008 and 7.4.5, the NDMP via proxy worked flawlessly, now it ignores "i think" -M -P "other_ipaddress" setting.

So the server has two nics, one "regular_ip_address" and one "other_ipaddress" for ndmp dumps.

The command that used to work is:

nsrndmp_save -M -T dump -P "other_ipaddress"

Now on the new version this same command does not respect the "other_ipaddress" everything goes through the "regular_ipaddress" which creates a huge bottleneck.

The server is a standalone networker, no other storage nodes. So the proxy was pointing to the other interface.

Any suggestions? Is this a bug in 8.1.1.2?

The NetApp is on dataontap 8.something.

Thanks

6 Posts

June 8th, 2014 21:00

With the help of EMC tech, it should have worked with the ipaddress.

With him working on it for an hour he figured out the solution and that is:

nsrndmp_save -M -T dump -P

And in the Application Information of the client add the

NSR_DSA_SAVE_SERVER=

And this is still on 8.1.1.2

Thanks for all the suggestions.

2 Intern

 • 

14.3K Posts

March 10th, 2014 17:00

I use 8.0.3.1 and it works there.  I would argue that this is a bug in case that -P parameter is ignored.

5 Practitioner

 • 

274.2K Posts

March 11th, 2014 01:00

6 Posts

March 11th, 2014 10:00

No change with the NSR_DSA_NODE

I have even changed the hosts files on both netapp and the backup server and only, from what I can tell, the small amount of traffic that has gone through the "other_ipaddress" might be the just metadata, about 1GB or so, after that I can clearly see that it is going through the "regular_ipaddress" again.

So the hostname has little to say, if the network is still reachable. But unfortunately I can't VLAN separate this since this is a production filer.

6 Posts

March 11th, 2014 12:00

Just an FYI

5183:nsrndmp_save: DSA is listening for an NDMP data connection on: "regular_IPAddress", port = 8839

42952:nsrndmp_save: xxxxxxxx:/vol/vol_xxxxxxx/ NDMP save running on 'xxxbackupserverhostnamexxxxx'

86724:nsrdsa_save: DSA listening at: host 'other_ipadress', IP address 'regular_ipaddress', port '8839'.

42958:nsrdsa_save: Performing Immediate save

I will also try to update the server tomorrow to 8.1.1.3

6 Posts

March 11th, 2014 13:00

It was defined a long time ago through the front-end

2 Intern

 • 

14.3K Posts

March 11th, 2014 13:00

Here is how it is in my case using 8.0.3.1 (Linux) - also with NetApp.

# cat 4180

42909:nsrndmp_save: Performing DAR Backup..

83320:nsrndmp_save: Performing incremental backup, BASE_DATE = 5660605732

42794:nsrndmp_save: Performing backup to Non-NDMP type of device

42658:nsrdsa_save: DSA savetime = 1365724838

85183:nsrndmp_save: DSA is listening for an NDMP data connection on: {backend IP}, port = 8332

42952:nsrndmp_save: {filer backend name}:/vol/{volume}/{qtree} NDMP save running on '{front-end name}'

86724:nsrdsa_save: DSA listening at: host '{backend IP}', IP address '{backend IP}', port '8332'.

42958:nsrdsa_save: Performing Immediate save

42617:nsrndmp_save: NDMP Service Log: DUMP: creating "/vol/n5051002/../snapshot_for_backup.59" snapshot.

42617:nsrndmp_save: NDMP Service Log: DUMP: Using inowalk incremental dump algorithm for qtree

42617:nsrndmp_save: NDMP Service Log: DUMP: Date of this level 1 dump: Fri Apr 12 02:00:38 2013.

42617:nsrndmp_save: NDMP Service Log: DUMP: Date of last level 0 dump: Thu Apr 11 02:00:36 2013.

42617:nsrndmp_save: NDMP Service Log: DUMP: Dumping /vol/{volume}/{qtree} to NDMP connection

42617:nsrndmp_save: NDMP Service Log: DUMP: mapping (Pass I)[regular files]

42617:nsrndmp_save: NDMP Service Log: DUMP: mapping (Pass II)[directories]

42617:nsrndmp_save: NDMP Service Log: DUMP: estimated 28127095 KB.

42617:nsrndmp_save: NDMP Service Log: DUMP: dumping (Pass III) [directories]

42617:nsrndmp_save: NDMP Service Log: DUMP: dumping (Pass IV) [regular files]

42617:nsrndmp_save: NDMP Service Log: DUMP: Fri Apr 12 02:05:43 2013 : We have written 9144344 KB.

42617:nsrndmp_save: NDMP Service Log: DUMP: Fri Apr 12 02:10:43 2013 : We have written 16777124 KB.

42617:nsrndmp_save: NDMP Service Log: DUMP: Fri Apr 12 02:15:43 2013 : We have written 25076866 KB.

42617:nsrndmp_save: NDMP Service Log: ENHANCED_DAR_ENABLED is 'T'

42617:nsrndmp_save: NDMP Service Log: ACL_START is '28691347456'

42617:nsrndmp_save: NDMP Service Log: DUMP: dumping (Pass V) [ACLs]

42617:nsrndmp_save: NDMP Service Log: DUMP: 28018901 KB

42617:nsrndmp_save: NDMP Service Log: DUMP: DUMP IS DONE

42617:nsrndmp_save: NDMP Service Log: DUMP: Deleting "/vol/n5051002/../snapshot_for_backup.59" snapshot.

42617:nsrndmp_save: NDMP Service Log: DUMP_DATE is '9955659430'

42951:nsrdsa_save: Successfully Done.

sc33hbg5051-st.corp.vattenfall.com: /vol/{volume}/{qtree} level=incr, 28 GB 00:17:36     27 files

completed savetime=1365724838

42913:nsrndmp_save: Save session closed with NW server successfully

42914:nsrndmp_save: Sorting File History....

42916:nsrndmp_save: Sorting File History completed Successfully in 00:00:00 Hours

42917:nsrndmp_save: Processing NDMP File History...

42918:nsrndmp_save: {filer backend name}:/vol/{volume}/{qtree} Processing NDMP File History completed Successfully on '{server front end}' in 00:00:00 Hours

42920:nsrndmp_save: browsable savetime=1365724838

42927:nsrndmp_save: Successfully done

How did you define filer - over front-end or back-end address?

2 Intern

 • 

14.3K Posts

March 11th, 2014 14:00

That would be the only difference in setup I guess when comparing to what I have.  You can always rename client to see if that makes any changes if update won't help (I suspect it won't as I didn't see anything described as you have on fix list).

2 Intern

 • 

326 Posts

March 19th, 2014 00:00

WHat is entry in storage node field..was informed that -P is irrelevant and storage node field supposed to take care of that but was told in 7.6x it doesnt work and the workaround is to put the -P in command....but in 8 was told that the sn field shd work without p...no?

6 Posts

March 20th, 2014 10:00

i had nsrserverhost, which i have changed to the "other_Ipaddress", but no change in behavior.

Still on 8.1.1.2 since i could not get the upgrade started with the 8.1.1.3 installer.

2 Intern

 • 

14.3K Posts

March 20th, 2014 16:00

8.1.1.2 -> 8.1.1.3 is not upgrade, but update and as for such you will to uninstall 8.1.1.2 first and then install 8.1.1.3. I personally doubt 8.1.1.3 will fix your issue as I didn't see anything in fix list specific to this problem.

1 Message

May 18th, 2016 10:00

Thanks rolajo,

The answer was great help for me,  The networker server has two Vlans, a is administrative and another is of backup.

Always the backup used the IP of vlan administrative and the backup failed

administrative IP = 10.181.0.15

##############################################################

82966:nsrndmp_save: Using networker as the NetWorker server.

42910:nsrndmp_save: Performing Non-DAR Backup..

83564:nsrndmp_save: Performing full backup

42794:nsrndmp_save: Performing backup to Non-NDMP type of device

42658:nsrdsa_save: DSA savetime = 1463584832

85183:nsrndmp_save: DSA is listening for an NDMP data connection on: 10.181.0.15, port = 9778

42597:nsrndmp_save: data connect: failed to establish connection

42886:nsrndmp_save: Unable to start the NDMP backup process.

42617:nsrndmp_save: NDMP Service Log: SELECTED NODE: 172.30.80.154  WWN 2009000b0804a6fa for BE session

42619:nsrndmp_save: NDMP Service Error: Cannot connect to the mover

####################################

So the solution was:

backup command:

nsrndmp_save -M -T dump -P

appl:

NSR_DSA_SAVE_SERVER=

No Events found!

Top