Forum Discussion

sshagent's avatar
sshagent
Level 4
3 years ago

Exactly what tape a backed up path is on

Long time NetBackup user here.  I have a situation of backups spanning multiple tapes, and this is getting a bit silly now with restore requests going by the contents of the restore log.  Retrieving all tapes mentioned in the top of the restore log. 
Obviously we could wait to see exactly what tape from that list it wants, but then it might ask for more after the first mount request.

I've been checking the output of bpflist and hoping i could cross reference something there with a fragment number on bpimagelist out, to know EXACTLY what tape a path of files was written to. 

Any pointers would be appreciated.  Thanks for your time.

Linux
  • mph999's avatar
    mph999
    Level 6
    3 years ago

    I don't think this is easy to do.

    The information that makes up the location is in two places, the image fragment table in nbdb, and, the images .f file.

    The problem is, the .f file (needs converting with the cat_convert command) does indeed show each file backed up, but only shows an 'offset' value from memory (I think) and so there is no obvious way to narrow this down to a particular tape.

    As an educated guess ...

    The frag table shows each fragment, the tape it is on and the position on the tape the frag is located.
    The .f file shows the offset of the file from (again a guess) the beginning of the backup.

    So you can see my thoughts, if you know how far into a backup a file is (offset), and you know where the fragments are and the size of the fragments, it might be possible.

    Another thought though, will NBU even start the restore if all the tapes are not available, although it may have the one it actually needs) - apologies, I probably should know the answer to that, but have never tried it ....


    • sshagent's avatar
      sshagent
      Level 4
      3 years ago

      Thanks for your time.  Looks like i'll investigate the nbdb and image files.  The cross reference on fragments is kind of what i was thinking would be a kind of solution.

      In regards to

      > Another thought though, will NBU even start the restore if all the tapes are not available, although it may have the one it actually needs) - apologies, I probably should know the answer to that, but have never tried it ....

      We do a lot of restores, and we fell behind a little on LTO generations for a bit...add into that a little too much multiplexing and we often get many tapes requested at the start of the restore.  A minute or two after, it'll specify the first tape it actually needs to mount.  All our tapes are offsite, as there are so many (more than a mile high, if you stack them flat on top of each other!)...so am looking to try and optimize this recalling of tapes.  I'd love to be able to knock up a script to calculate exactly what fragment, and therefore tapes, a restore path is on. 

      Thanks for the pointer, i'll look into this. 

  • sshagent's avatar
    sshagent
    Level 4
    3 years ago

    In case my query wasn't clear.  Here is an example.

    Suppose i have a 100 TB backup spanning many LTO tapes.  If i wanted to restore 10 GB worth of files (one directory and its contents).  Is there a combination of commands to identify the exact tape...or 2 if it happens to span 2 tapes that these tapes are on.

    I'm aware that the restore log will list off all tapes used in the original backup, then will ask for the mount of the 1st tape.  It won't mention that it *will* need a second tape until its finished with the first tape. 

    I want to know prior to running this restore all the tapes that are actually needed.  Not the ones that *could* be needed.  We are a restore heavy environment and we have a lot of older historical data on smaller LTO tapes, where we're asking for 10 tapes back and loaded in the library and only 1 or 2 tapes are actually needed.  This is causing library capacity issues and feels like something we should be able to get exact info for.  I guess some kind of bprestore -pretend option. 
    It feels like some kind of combination of bpflist and bpimagelist fragment numbers should get what i need.  But struggling to find a useful field in the bpflist output.