I'm a NB newb, and I've been looking all over Google, NB doc, forums etc. looking for an explanation of the fields in the bplist output, but am not finding anything. I even found an explanation for bpflist, which is an undocumented command, but nothing for bplist. Any suggestions? TIA
Netbackup Commands found in DOCS of mediakit:
bplist - list the backed up and archived files on the NetBackup server:
The bplist command shows a list of previously archived or backed up files
according to the options that you specify. You can choose the file or directory
and the time period that you want the listing to cover. Directories can be
recursively displayed to a specified depth. bplist shows only the files that you
have read access to. It lists the files only if an administrator account performs
the user backup. A non-administrator or backup operator cannot use bplist.
You also must own or have read access to all directories in the file paths. You can
list the files that were backed up or archived by another client only if you are
validated to do so by the NetBackup administrator.
Sorry, should have been more specific, I'm looking for an explanation of the bplist output fields when using the -Listpolicy flag. Some are obvious, some not so much; I assume one of the 0's is policy type.
Example (output fields on separate lines for readability:)
$ bplist -Listpolicy -s <start date> <file name>
0 0 0 0 <bytes> 372 15840 -2147480663 1 33188 <owner> <group> <bytes> <backup timestamp> <last access timestamp> <last inode mod timestamp> <last file mod timestamp> 4 16 <policy name> 41 <file name>
Going to have to try this when I'm back at work & can try it on somthing specific there.
Looking at the man page doesn't divulge much:
Names the file or directory to list. If you do not specify a path, the default is the current working directory. Any files or directories that you specify must be listed at the end, following
all other options. For directories, if you do not use the -R option, include the trailing path
separator as in the following: bplist -l "/home/user1/*" Note: If you use the asterisk meta character "*", you should use quotation marks around the filename for the command to work properly.
Includes the schedule type and policy name in the command output.
Looks like it's very similar to bpflist (which makes sense), albeit in slightly different order...
field 8 is encoded major/minor dev number (-2147480663 above is an NFS mount)
field 10 is mode bits in decimal (33188 above = 100644 octal = reg file mode 644)
field 18 is schedule type (4 above = Cumul INCR)
Still would like to find this documented somewhere, rather than play detective.
Where's the fun in that?
Maybe you're right, it isn't fun....you've got a lot further than I think I'd've managed.
If you provide the version info CRZ requested I'm sure he'll do the business for you!
Sorry dmj - it wasn't as easy as I'd hoped :) I've put some feelers out to other folks to see if I can find an "official" answer for you.
My educated guesses from poking around - and after you already did most of the heavy lifting:
Fields 1-4 appear to be used to specify sizes under certain conditions, but are unused with straight file backups. They are taken in pairs - one is gigabytes and the other is the remainder - you add 'em to get the final size. All this is moot as they were always 0 in my tests and I don't think you'd ever get nonzero results from the command line. :)
Field 5 is the file size in bytes, as you have already figued out.
Fields 6 and 7 file and block numbers and go with the device number in field 8, which you have already figured out.
Field 9 is a "this file is in the image" flag, looks like. (It was always 1 whenever I tested it out, which makes sense)
I never would have figured out field 10 in a zillion years - fortunately you already figured out it was the permission. :)
Fields 11 and 12 are obviously user and group, as you have already figured out.
Field 13 looks like file size in bytes again. It's possible that if you're using compression, this one (or field 5) would change to the compressed file size in bytes, but that's a REAL reach of a guess from me. I probably shouldn't assume there's an actual reason for listing the bytes twice :)
Fields 14-22 are pretty much exactly as you have already figured out.
Finally, it doesn't look like this output has changed much (at all?) from the time it was introduced in 5.x through 7.x.
Hope this helps! If I find out anything more "official," I'll be sure to share it - thanks for the interesting question!