Video Screencast Help

getting status 84 on client - storage unit is msdp

Created: 26 Dec 2012 • Updated: 26 Dec 2012 | 4 comments
This issue has been solved. See solution.

Hello. Have a client that has been successfully backing up over the last week, however, it began throwing status 84 errors over the weekend.

 

Client is Red Hat 6.2. Master is Win Server 2008 R2 Enterprise.

Detailed status of job is as follows:

12/25/2012 6:10:16 PM - Info bpbrm(pid=3352) apfs1 is the host to backup data from     
12/25/2012 6:10:16 PM - Info bpbrm(pid=3352) reading file list from client        
12/25/2012 6:10:18 PM - Info bpbrm(pid=3352) starting bpbkar32 on client         
12/25/2012 6:10:18 PM - Info bpbkar32(pid=0) Backup started           
12/25/2012 6:10:18 PM - Info bptm(pid=3192) start            
12/25/2012 6:10:19 PM - Info nbjm(pid=2304) starting backup job (jobid=217) for client apfs1, policy apfs1, schedule Differential-Inc  
12/25/2012 6:10:19 PM - Info nbjm(pid=2304) requesting STANDARD_RESOURCE resources from RB for backup job (jobid=217, request id:{96A0AA10-C1FE-4361-9616-D41F8876C39C})  
12/25/2012 6:10:19 PM - requesting resource apsu1
12/25/2012 6:10:19 PM - requesting resource nbflmaster.NBU_CLIENT.MAXJOBS.apfs1
12/25/2012 6:10:19 PM - requesting resource nbflmaster.NBU_POLICY.MAXJOBS.apfs1
12/25/2012 6:10:19 PM - granted resource nbflmaster.NBU_CLIENT.MAXJOBS.apfs1
12/25/2012 6:10:19 PM - granted resource nbflmaster.NBU_POLICY.MAXJOBS.apfs1
12/25/2012 6:10:19 PM - granted resource MediaID=@aaaah;DiskVolume=PureDiskVolume;DiskPool=apdp1;Path=PureDiskVolume;StorageServer=apnetbackup;MediaServer=apnetbackup
12/25/2012 6:10:19 PM - granted resource apsu1
12/25/2012 6:10:19 PM - estimated 325478 Kbytes needed
12/25/2012 6:10:19 PM - Info nbjm(pid=2304) started backup (backupid=apfs1_1356487819) job for client apfs1, policy apfs1, schedule Differential-Inc on storage unit apsu1
12/25/2012 6:10:19 PM - Info bptm(pid=3192) using 262144 data buffer size        
12/25/2012 6:10:19 PM - Info bptm(pid=3192) setting receive network buffer to 1049600 bytes      
12/25/2012 6:10:19 PM - Info bptm(pid=3192) using 30 data buffers         
12/25/2012 6:10:20 PM - Info bptm(pid=3192) start backup           
12/25/2012 6:10:20 PM - started process bpbrm (3352)
12/25/2012 6:10:21 PM - Critical bptm(pid=3192) image open failed: error 2060001: one or more invalid arguments   
12/25/2012 6:10:21 PM - Info bptm(pid=3192) EXITING with status 84 <----------        
12/25/2012 6:10:22 PM - connecting
12/25/2012 6:10:24 PM - connected; connect time: 00:00:02
12/25/2012 6:10:29 PM - end writing
media write error(84)

___________________________________________________________________________________

This is the only client backing up to this particular media server / storage unit. It had success until 2 days ago, and no one has been on campus since last Fri. Any guidance? A google search mentioned dedup jobs may still be ongoing etc, but the last good backup was on the 24th - can't imagine a differential backup would take 2+ days to process, so I figure something is going on.

 

Discussion Filed Under:

Comments 4 CommentsJump to latest comment

Marianne's picture

You never mentioned NBU patch level on Master/media server?

Any chance you have more than one policy for client with mixed case hostnames in Clients tab?
We have seen that MSDP needs to have exact same name for clients - not Uppercase in one and lower case in another.

Also see if this TN is relevant: http://www.symantec.com/docs/TECH183707

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

lovethatcheese's picture

Marianne,

 

Master / all media servers are on 7.5.0.4. Client is 7.0.

Regarding the tech note:

_____
UNIX: /usr/openv/pdde/pdcr/bin/crcontrol --getmode
Windows: <install_path>\Veritas\pdde\crcontrol --getmode

"put=Yes" means that cache loading is complete. Normal operations should resume.
 If "put=No," examine the <storage_path>/log/spoold/spoold.log file for the following message:

Storage Cache Manager: load completed

The message means that spoold finished loading the fingerprints. However, the new state probably has not been pushed to all processes yet.

_____

My result was put=No. In looking at the log, I do find this:

December 21 10:23:50 INFO [000000000DDAA100]: Storage Cache Manager: cache load completed
December 21 10:23:50 INFO [000000000DDAA100]: Storage Cache Manager: importing complete [thread 000000000DDAA100]
December 21 10:23:50 INFO [000000000DDAA100]: Task Manager :

_____

Per the tech doc, I will wait and re-run the command. it's puzzling, because the last successfull back up was a differential on the 24th - would seem really odd for such a small amount of data to take so long?

_____

Current Environment - NB 7.5.0.4 on Master / Media Servers. 7+ and above on clients (Red Hat).

OS - Windows Server 2008 R2 Enterprise on all

All media servers have MSDP / attached tape drive / enabled SLP's

___

lovethatcheese's picture

Put still = no after re-running command. Any other ideas? As for Marianne's suggestion, I have triple checked all hosts / client entries - no inconsistencies in capital letters, etc. 

 

_____

Current Environment - NB 7.5.0.4 on Master / Media Servers. 7+ and above on clients (Red Hat).

OS - Windows Server 2008 R2 Enterprise on all

All media servers have MSDP / attached tape drive / enabled SLP's

___

Marianne's picture

See second part of point 5 in TECH183707:

If "put=No," contact your Symantec support representative.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

SOLUTION