08-19-2016 06:48 AM
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 ?
Solved! Go to Solution.
08-22-2016 03:33 AM - edited 08-22-2016 03:42 AM
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:
I rest my case....
08-19-2016 08:18 AM
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!
08-19-2016 10:42 AM
08-20-2016 03:01 PM - edited 08-20-2016 03:03 PM
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.
08-21-2016 08:59 AM
08-22-2016 01:34 AM - edited 08-22-2016 01:36 AM
.
08-22-2016 01:35 AM - edited 08-22-2016 01:37 AM
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'.
08-22-2016 01:47 AM
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....
08-22-2016 03:01 AM
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 ...
08-22-2016 03:33 AM - edited 08-22-2016 03:42 AM
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:
I rest my case....