Forum Discussion

sclind's avatar
sclind
Level 6
11 years ago

What do people have set as "Reduce Fragment Size" for LTO3/4 tapes

I have two master servers  with LTO4  drives where we take the default of 1TB.

I have another master server where we have LTO3 drives where we drop it all the way down to 2048 MB.

Since I have such a big difference I am curious what other do (and perhaps why).

 

  • We never had ours set, but a smaller value can improve the speed of restores especially for restoring a few smaller files in a large backup.

    A quick search of the forum (for reduce fragment size) will yield 'a lot' of resolved posts, including a pointer to the following T/N (for 7.1 - not sure if there is a newer one):

    http://www.symantec.com/business/support/index?page=content&id=HOWTO56051

    In the end it comes down to your own environment & how your backups/restores are performing (ours were few & far between, so our emphasis was always on getting the data onto tape in the first instance).

  • Just remember fragment size determine how many data Netbackup minimum has to read to restore a single file. See it like a conveyor belt , where the fragment size is containers and tape the conveyor belt 

    For database backup big frament is good

    For file systems backup, smaller fragments is perferable, but will increase Netbackup catalog space slightly due to the larger mount of fragment pointers.

  • We never had ours set, but a smaller value can improve the speed of restores especially for restoring a few smaller files in a large backup.

    A quick search of the forum (for reduce fragment size) will yield 'a lot' of resolved posts, including a pointer to the following T/N (for 7.1 - not sure if there is a newer one):

    http://www.symantec.com/business/support/index?page=content&id=HOWTO56051

    In the end it comes down to your own environment & how your backups/restores are performing (ours were few & far between, so our emphasis was always on getting the data onto tape in the first instance).

  • Just remember fragment size determine how many data Netbackup minimum has to read to restore a single file. See it like a conveyor belt , where the fragment size is containers and tape the conveyor belt 

    For database backup big frament is good

    For file systems backup, smaller fragments is perferable, but will increase Netbackup catalog space slightly due to the larger mount of fragment pointers.

  • I might disagree here ...

    LTO drives are capable of fast block positioning, with the imformation held as to where the file is in the NBU catalogs .f file for the backup.  Therefore we no longer have to position to the beginning of the fragement as read all the way though till we find the file, we just zip straight along to it.

    Hence, for restores, frag size is irrelevant.

  • Looking at the TN posted above, this confirms my understanding:

    • During restores, newer, faster devices can handle large fragments well. Slower devices, especially if they do not use fast locate block positioning, restore individual files faster if fragment size is smaller. (In some cases, SCSI fast tape positioning can improve restore performance.)

  • 2048MB fragment size is default value for BasicDisk storage unit in some version of NetBackup, if I remember right. I guess someone had set this value when he(or she) migrate storage from disk to tape.

  • I disagree with you partly - you are right about non-multiplxed backup, but not on multiplxed backups.

    • By limiting the size of the fragment, the size of the largest read during restore is minimized, reducing restore time. The fragment size is especially important when restoring a small number of individual files rather than entire directories or file systems.
    • Larger fragment sizes do not hinder performance when restoring from non-multiplexed backups. For multiplexed backups, larger fragments may slow down the restore. In multiplexed backups, blocks from several images can be mixed together within a single fragment. During restore, NetBackup positions to the nearest fragment and starts reading the data from there, until it comes to the desired file. Splitting multiplexed backups into smaller fragments can improve restore performance

    If Netbackup could do fast locate to files within fragments it would means the image catalog should contain block numbers for each files, but I am not able to see that infromation stored in the .f files or any output form bpimagelist under fragments.

    Let's continue the discussion in private so we dont hijack this thread.

  • Ahh yes, fair play Nicolai regarding the MPX backups ...