\VERITAS\NetBackup\db\images

The reason why you cannot find anything is because we are not meant to open these files although they are text files.

There are commands to query the image files. Like bpimagelist.

bpimagelist has lots of options to make output humanly readable (e.g. -L).

bpimagelist -l gives 'unformatted' output, i.e. in the same format that you see them in the header files. 

See this TN for explanation of all the fields: http://www.symantec.com/docs/TECH5584

OK, this does not appear to be a what /if question - and as you have made an effort (searched Google) I will give some details.

The header files as Marianne correctly says, have gone into EMM at 7.5, for various reasons, the main one I suspect is performance.

The steam file is created when a backup runs with ,multiple streams

I have no idea what those bits are you have highlighted, and guess what - it doesn't matter , there is nothing in this file you need to be concerned about - look at it this way, I've never needed to know this level of detail about this file in almost 5 years of supporting NBU.  I've searched, it isn't documented, meaning the only way to find out this detail is for examnple to run multiple backups changing various selection in the policy, client type etc ... and see if this changes any of the values in this file.  It is quite possible that some of these numbers change depending on various settings, but it is also quite possible that some of these numbers will always be 0, as there are there for future use , of have been dropped from use, but the NBU code still needs to have some value in this file.

But ...

I figured nbjm creates this file, so looking in the nbjm log I found that this is true, and that is all you need to know.  IF for some reason you found that this file wasn't being created causiong a failure. some good trouble shooting would be to check in nbjm to see if the files was created, you could then pass you findings to support to continue.  On occassion, when multi-streams backups have had an issue, I've deleted the streams file, and this has been a fix, as it has been recreated when the next jobs runs, but apart from that, I've never needed to touch it, or even be concerned about what the numbers really are.

Clearly, if there was a big reason to know, it would be documented, it isn't.

For 7.5 - I'll mention the other bits in here ...

In the images/<client>/>ctime> directory you will have the .f files - these are binary files that contain a list of the files in the backup.  In effect, when you look in the BAR gui to restore, you are looking in the .f file.

The file must never be editted.

Now, when the backup is big, the .f is big (many files being added to it) and searching a long list is not efficient, so when this file gets to be bigger than I think 2MB, it is broken up, and the details in it are split into multiple files in the catstore directory.  The .f file then becomes 72 bytes in size.

The resulting files in catstore, for the backup image, are 'arranged' in a data structure called a b-tree (computer science term) - this is a 'format' that allows the data to be searched quicker and more efficiently.

For b-tree stuff see the wiki page.  No point asking me about them, I don't know any more than the wiki page.