05/17/2013 00:51:04 - started process bpbrm (pid=27698)
05/17/2013 00:51:04 - connecting
05/17/2013 00:51:05 - connected; connect time: 0:00:00
05/17/2013 00:51:07 - begin writing
05/17/2013 00:52:47 - Info bpbrm (pid=27698) server123 is the host to backup data from
05/17/2013 00:52:47 - Info bpbrm (pid=27698) reading file list from client
05/17/2013 00:52:48 - Info bpbrm (pid=27698) starting bpbkar on client
05/17/2013 00:52:48 - Info bpbkar (pid=3035390) Backup started
05/17/2013 00:52:48 - Info bpbrm (pid=27698) bptm pid: 27699
05/17/2013 00:52:48 - Info bptm (pid=27699) start
05/17/2013 00:52:49 - Info bptm (pid=27699) using 1048576 data buffer size
05/17/2013 00:52:49 - Info bptm (pid=27699) setting receive network buffer to 1048576 bytes
05/17/2013 00:52:49 - Info bptm (pid=27699) using 512 data buffers
05/17/2013 00:52:50 - Info bptm (pid=27699) start backup
05/17/2013 00:52:50 - Info bptm (pid=27699) backup child process is pid 27724
05/17/2013 02:01:13 - end writing; write time: 1:10:06
05/17/2013 02:02:48 - Error bpbrm (pid=27698) socket read failed: errno = 62 - Timer expired
05/17/2013 02:02:50 - Error bptm (pid=27699) media manager terminated by parent process
05/17/2013 02:02:56 - Info bpbkar (pid=3035390) done. status: 13: file read failed
file read failed (13)
Solved! Go to Solution.
Error bpbrm (pid=27698) socket read failed: errno = 62 - Timer expired
This looks like Client Read Timeout.
The default is 300 (5 minutes). As a start, increase this timeout on the media server. If current Client Read Timeout on the media server is 300, change it to 900 as a start.
To see where backup gets stuck on the client, create bpbkar log folder on the client under /usr/openv/netbackup/logs on the client.
VERBOSE = 3
to /usr/openv/netbackup/bp.conf on the client.
Please post bpbkar log file as File Attachment after next failure.
In the meantime, please tell us more about the client:
OS (including version)
NBU version and patch level
Type of data in /u01
If what Marianne suggested doesn't help, it could be a corrupt or unreadable file.
You can pull /u01 out of the normal backup and let everything else get backed up by the existing policy while you truoblehsoot the problem with /u01. You can try to increase logging on the client and backup /u01 to see if it gives you an idea where it fails. Alternatively, you can narrow it down by backing up the individual subdirs of /u01 until you find one that fails again. Focus your efforts there by again backing up the sub dirs until you find the culprit file.
It's a bit of a pain and a manual effort, but if it is indeed a corrupt file, this will find it.
You might also get lucky with doing an ls of all files following the same method as you might run into a 'cannot stat file' or similar OS error.
Database backup in /u01 probably means large flatfiles?
Are any steps taken to ensure that database bakup to disk is finished by the time NBU backup starts?
Try to increase timeout as per my previous post.
Create bpbkar log on client as suggested above with increased logging (level 3 should be sufficient) to see where exactly backup is getting stuck.