Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm having some issues with a new Backup Exec 2010 R2 installation. I configured a NetApp FAS2020 as an NDMP device and want to backup files from the SAN to a tape drive connected to my backup server. I set up ndmpd according to this document (http://www.symantec.com/business/support/index?page=content&id=TECH48957) and created a separate backup user (http://filers.blogspot.com/2006/09/setting-veritas-netbackup-with-non.html).

Backup works perfectly, but restoring any file gives me an authentication failed error. The NDMP device has a "global" ndmp user configured in the device tab (tried this with the newly created ndmpd backup user and the netapp root) and I can also configure separate resource credentials in the BE restore job.

I have tried setting the same accounts for the "global" ndmp device and the restore credentials and have also tried setting different accounts for them.

NDMP debug level is at 5 and this is what shows up in /etc/messages. The session is closed immediately after it has been granted.

16:12:07 PST [Java_Thread:info]: ndmpdserver: ndmpd.access allowed for version = 4, sessionId = 51, from src ip = 192.168.11.17, dst ip = FAS2020-1/192.168.11.75, src port = 50857, dst port = 10000 16:12:07 PST [Java_Thread:info]: Ndmpd51: ndmpd session closed successfully for version = 4, sessionId = 51, from src ip = 192.168.11.17, dst ip = FAS2020-1/192.168.11.75, src port = 50857, dst port = 10000

Running wireshark on the backup server doesn't produce much. It shows a SYN -> SYN/ACK -> NDMP CONNECT_CLOSE Request from the backup server.

The Resource Credentials for the restore job behave very oddly. If I enter NDMP credentials and do "Test All" it fails. If I use my regular domain backup account, it is successful. There are no failed or succeeded logons in the NetApp ndmp log and tracing this check shows that it doesn't even connect to the SAN. This makes me think that this is more likely flaky BE behaviour rather than misconfiguration of the SAN.

Here is the options ndmp output:

FAS2020-1> options ndmp

ndmpd.access all

ndmpd.authtype challenge

ndmpd.connectlog.enabled on

ndmpd.enable on

ndmpd.ignore_ctime.enabled off

ndmpd.offset_map.enable on

ndmpd.password_length 16

ndmpd.preferred_interface disable

ndmpd.tcpnodelay.enable off

share|improve this question
    
What does Symantec support have to say about this? I never ran into this issue at all with 3140's. It was pretty painless. –  SpacemanSpiff Jan 18 '11 at 0:41
    
I'll contact them tomorrow if nothing turns up. –  uuwe Jan 18 '11 at 2:54

1 Answer 1

THis is a known bug to Symantec, and is supposedly to be fixed with the release of 2010R3 in a couple weeks.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.