Maximum Fragment Size

[H_Sharma]

Hi Experts,

Does it helpfull in now a days to speed up the restoration when we have SCSI Locate command on Tape Drives?

https://www.veritas.com/support/en_US/article.TECH15692

Any suggestions/Experiences ?

[Genericus]

You should check your tape information, as well as your own testing.

Tape drives can have a maximum buffer size, and your systems may also have a "sweet spot" or optimal buffer size.

Writing to disk, you may be better off with larger buffers, I use 256 for my tapes

cat /usr/openv/netbackup/db/config/SIZE_DATA_BUFFERS

262144

Please NOTE - there are separate buffer sizes for NDMP, DSK and RESTORE as well!

[Marianne]

The question here is about fragment size in STU properties, not buffer size.

The answer remains the same - your own experience is what is right for you.
@H_Sharma has been around long enough to tell about his own experience.

There is no right or wrong or even best practice. Each environment is unique and tests must be performed to see what is working best.

Each user in this forum will have his/her own opinion.
Martin Holt who is Veritas Support Backline tape expert will tell you with fast locate, a reduced buffer size is not needed.
Nicolai and I will tell you that we still believe that smaller fragment size ensures quicker restore where a single small file needs to be restored from a large backup image.

[mph999]

Hello, did I hear someone mention tape ;0)

What a wonderful answer from Marianne, yes, we all have our preferences, and based on theory alone fast block locate should negate the need for smalller frag size, why, because we know where the file is (block position) and modern tape drives have the 'fast locate block' feature.

I once tried to prove this by attempting to match up the data in the .f file with the output of scsi_command -map. If  I recall correctly I couldn't quite get the numbers to match, I was a tiny bit out, which probably had a simple explanation if I knew 'exactly' how this all worked (it's kinda Engineering level difficulty and I'm not an Engineer (as in the guys who write the code).

MPX would also add another layer of complexity, and I would have to do some testing before I commect futher if mpx is involved.

By luck, I have a case with engineering at the moment, not related to this, but does involve .f files.  It's with an Engineer who prior to the case I hadn't worked with, but he's a really great guy and very knowledgeable, so when I get a little time, I'll drop him a mail and see if I can get an official answer.

[Marianne]

Maybe the better test would be to run backups and restores with and without reduced fragment size.

[mph999]

.

[mph999]

Test restore using max frag size, of last file in a backup (determined by looking in .f file) - 1 fragment in backup

08/22/2016 08:10:20 - restored from image womble_1471848558; restore time: 0:00:44

08/22/2016 08:10:21 - end Restore; elapsed time 0:00:49 the requested operation was successfully completed (0)

Re-ran backup using frag size of 50MB, then restored the same file - 84 fragmants in backup

08/22/2016 09:00:07 - end Restore; elapsed time 0:00:54 the requested operation was successfully completed (0)

Pretty much the same time, so smaller fragment size made no difference. Backup time was small, only 5 minutes, but given the restore took seconds, this appears to have been sufficiently long enough to demonstrate the 'theory'.

[Marianne]

I have seen a difference with single file restore from a large File Server backup that ran for more 8 hours with fragment size of 0 (default of 1TB).
I was called when restore was still active after about 3 hours and file not yet restored.
Cannot remember drive type, but it was not that long ago....

[mph999]

As far as I amaware, any of the recent drives should support FBP,  at least from LTO1 onwards, or similar (eg. STK drives).  However, that doesn't of course mean that it worked, and didn't have some fault.

I've seen faults on drives that you think, how on earth can it do that (or not ...),  so no matter how unlikely, anything is possible of course ...

[Marianne · Accepted solution]

I do not believe that there is a right or wrong answer here.
I have seen in the field that reduced fragment size is only useful for large file-server backups, and of no use for database backups.

That is why I recommended that @H_Sharma performs his own tests in his unique environment and tell us what his personal experience is...
He is not a newbie - been using NBU in tape environment for at least 3 years now. 

Plus, there is a list of 4-5 similar discussions that can be seen on the right-hand side of this screen... 

..... MMMMMM...... 
Just noticed that the OP has also asked about fragment size about 19 months ago:

Fragment Size 

I rest my case....