02-22-2014 04:06 PM
A Tale of Two Backups
02-22-2014 09:19 PM
you have 2 issues ..
1) Media write error.
2) backup issue with job "h"
please show me the backup policy configurations
bppllist <policy name of job a> -L
bppllist <policy name of job h> -L
also attach the entire bpbkar log for the h job with Verbose 5
PS:-I like the way that you presented the issue over here..
02-22-2014 10:41 PM
Regarding 1) Media write errors -- yes, agreed, that's an issue.
Regarding 2) backup issue with job "h", attaching the info you requested. I had to resume the job again so I could capture the stuff at the beginning of the log file; I only included the first 1000 lines or so (I confirmed that there are 23 unique log entries and they all appear at the beginning of the log)
Thanks for taking the time to look at this!
02-22-2014 11:37 PM
22:29:57.054 [19169] <2> bpbkar resolve_path: INF - /gs3/users/hcs2 resolves to /gpfs/gsfs3/users/hcs2 22:29:57.054 [19169] <2> bpbkar resolve_path: INF - Actual mount point of /gs3/users/hcs2 is /gpfs/gsfs3/users/hcs2
so the actual mount for /gs3/users/h* is /gpfs/gsfs3/users.
so try to keep the backup selection as /gpfs/gsfs3/users/h* and try the backups, lets see how it goes..
i would also see deatail status of the failed job or full log of bpbkar log... because i would like to see how much time its taking befor its giving the failure message..
02-23-2014 01:00 AM
Hi sb981 - What is the O/S version and CPU architecture of the backup client ?
I ask because not all combinations of NetBackup + linux + ext4 are listed in compatibility matrix:
http://www.symantec.com/business/support/index?page=content&id=TECH76648
02-23-2014 11:37 AM
I can see the rationale for using the actual mount point rather than our symbolic link shorthand... but both jobs have been backing up files this way for months.
About the log -- I'm not sure what is supposed to happen to the remote bpbkar client process when the master server places a job in Incomplete status, but for this "h" job the process persisted and continued to accumulate cpu time and write to the logs -- by the time I realized that was the case the logs had cycled through 111 50MB files (keeping three at any given time). I killed the process and the logging stopped. Note, however, there were no such lingering processes from the "a" backup, so it handled the transition more gracefully (and correctly, I'm sure).
I'm going to let this issue go for now because I just looked at the policy for "dis-gs3-h" with the GUI and noticed that the "Backup Selections" says "/gs3/users/g*" !! so I'm not surprised that this job isn't able to resume.
Thanks again for your help!
02-23-2014 12:12 PM
Hi sdo,
Thanks for the link. The NetBackup master server is running RHEL5 on x86_64 and the client is RHEL6 on x86_64.
We're planning to upgrade Netbackup and the master server OS later this year.
02-23-2014 03:29 PM
Ok looks like ext4 is supported, with your O/S, architecture and NetBackup Client version.
Next I'm wondering if there's an etrack listed (from around page 80 onwards) in the v7.0.1 release notes that might be relevant, but it'll be a lot of reading if you don't get lucky with a search:
http://www.symantec.com/business/support/index?page=content&id=TECH124476
02-23-2014 03:49 PM
I can see that GFS2 support began with NetBackup v7.5 onwards - but it's not clear to me if GFS2 is synonymous with GPFS - which, might not be supported... Found this re GPFS:
http://unix.ittoolbox.com/groups/technical-functional/ibm-aix-l/symantec-netbackup-gpfs-support-5245335
Is GFS2 the same thing as GPFS?