Video Screencast Help

Question about Multiplexing and Fragment Size

Created: 27 Mar 2014 • Updated: 16 May 2014 | 6 comments
This issue has been solved. See solution.

Hello all,

I've been reading up on multiplexing and fragment size tuning. Specificaly from the NBU 7.1 Perfromance Tuning Guide. I understand that Fragment size should be adjusted to improve restore performance when restoring only small amount of files on multiplexed tapes.

I'm curious on why I would reduce the fragment size drastically from default when the fast locate feature is enabled on the tape drive? Would it be beneficial to go to 500GB fragment size? I've seen some recommendations of 10GB or 50GB fragment size but I feel like that may be too small.

My enviornment:

Netbackup on RHEL 6.5

Spectra Logic T380 TLD - 10 x LTO6 Drives

Thanks in advance.

Operating Systems:

Comments 6 CommentsJump to latest comment

SymTerry's picture


There is actually a pretty good description on this thread about fast forward and fragments by AAlmroth. Check that link out.

Marianne's picture

Why not do your own tests and decide what works for you?

Run the same large filesystem backup using different fragment sizes and then restore the same file from each of the backups.

Let us know the result.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

Mark_Solutions's picture

If you are doing multiplexed backups then fragment size has no real meaning anyway as when more than one backup is writing to a tape they are constantly writing markers to the tape as each backup writes its data blocks on the tape.

The only way it would make a difference is when a non multiplexed backup is written (or only one stream is running) when after every XXX GB a tape marker gets written to the tape.

So whatever tape technology you have the fragment size will be of no consequence when running multiplexed backups.

Hope this helps

Authorised Symantec Consultant . Expert Partner.

Don't forget to "Mark as Solution" if someones advice has solved your issue - and please bring back the Thumbs Up!!.

Nicolai's picture

I am guessing here from what I know about Netbackup.

I don't think Netbackup can do a fast locate to a block in a fragment. I think it only can do locate to the beginning of a fragment.

If netbackup could do fast locate to each file , it would mean the Netbackup catalog should contain block numers for each file. I can't see such details when looking around in the image catalog.

Assumption is the mother of all mess ups.

If this post answered your'e qustion -  Please mark as a soloution.

mph999's picture

I could be wrong ...

The block details for the files are in the .f file ...  (blknum  column)

root@nbmaster00 1396000000 $ cat_convert -dump tape_1396177154_FULL.f
num     len     plen    dlen    blknum  ii      raw_sz  GB      dev_num path    data

0       0       1       50      0       0       0       0       2049    /       16877 root root 0 1396090921 1396004400 1396004400
1       0       10      50      3       1       0       0       2049    /testdata/      16877 root root 0 1396176999 1395221621 1395221621
2       0       15      52      4       1       0       0       2049    /testdata/file4 33188 root root 332 1395221618 1395221618 1396176999
3       0       15      52      6       1       0       0       2049    /testdata/file2 33188 root root 332 1395221611 1395221611 1396176999
4       0       15      52      8       1       0       0       2049    /testdata/file3 33188 root root 332 1395221615 1395221615 1396176999
5       0       15      52      10      1       0       0       2049    /testdata/file5 33188 root root 332 1395221621 1395221621 1396176999
6       0       15      52      12      1       0       0       2049    /testdata/file1 33188 root root 332 1395221621 1395221606 1396176999

Regards,  Martin
Setting Logs in NetBackup:
ggand's picture

All, thanks for the input. It is very helpful. I actually have some backup/restore tests scheduled in the next few days and I will post my results to this thread afterwards.