Recently, I embarked on an exercise to see if changing the properties of the tape drive has any effect on the speed of my backups.
I am using BE 12.5. I back up my data to a SAS-attached HP tape library with a LTO4 tape drive and I write to both LTO3 and LTO4 tapes.
First, I unchecked the single block mode parameters to enable buffering. This has no effect on the backup time.
Next, I increased the high water count which is the number of buffers that is filled before the data is written out to the tape drive. This sped up the backup a little, but not significantly. This indicates that my system is unable to stream enough data to tax the tape drive.
Since I have 4GB of memory on my media server, the next parameter to change is the buffer size and/or the block size. Before changing these parameters, I checked with HP as to whether my tape drive supports buffer and block sizes greater than the default 64k and whether bigger sizes will speed up things. As expected, HP is rather non-committal. They just said that it support bigger block and buffer sizes, but they have no specific recommendations as to which size to use. It is all up to the backup software.
When I tried to change the block size, I get dire warnings from BE that bigger block size may not be support and that I should test that I can restore the data. So I changed the buffer size first to 256k. What a dramatic effect this has: The job rate for my job which writes to LTO4 tapes jumped from 2 GB/m to 2.7 GB/m, saving an hour! Strangely, this change had minimal effect on my job which writes to LTO3 tapes.
I thought everything is fine until a few days later when my job failed with this error
An inconsistency was encountered on the storage media in HP 3.
V-79-57344-33994- The data being read from the media is inconsistent.
I thought this was a one-off failure due to dirt on the tape, etc. A couple of similar failures convinced me otherwise. Looking closer at the job logs for the failed jobs, I noticed that all of them were spanning tapes. For the jobs that did not span tapes, there were no failures. I set the buffer size back to the default 64k and the problem disappeared.
However, I am not about to give up on the improvement in backup time. I changed both the block size and buffer size to 256k. After the change, I run a small backup job with verify to check that the tape drive can handle the new block size. It ran successfully. The backup time for my LTO4 tapes with these new settings was the same as when the buffer size alone is 256k, i.e. 2.7 GB/m. A few days later, my job spanned to a second tape and there was no error.
Next, I changed the block and buffer sizes to 512k. This has no effect on the backup timings, so I reverted back to 256k. There is no point in tying up extra memory for nothing.
These are the final settings that I am using are shown in the figure above.
Before I use these settings permanently, I checked that I am able to read the tapes that were previously written with 64k blocks. I ran a small restore job and it ran fine. The tape drive was able to read the 64k blocks without me setting the block size to 64k first.
I also check with Symantec Technical Support as to whether there is any report of the problem that I encountered when my job spanned tapes. They said that there is no report of such a problem. I leave it at that. This kind of problem occurs at a fairly low level between the backup software and the tape device. Talking to the technical support staff at either Symantec or HP would be futile. This problem can only be traced at the development lab where it is possible to see the actual data passing between BE and the tape device.
For my tape drive,
- Buffering has no effect on the backup time. My system is unable to tax the tape drive.
- Writing big chunks of data to the tape drive saves backup time.
If you are using a SAS-attached LTO4 tape drive, my settings can probably be used as it is.
For other types of tape drives or connection, you would need to test what parameter changes work for you. If you do want to tune your tape drive parameters, I suggest that you take baby steps and observe the results. If anything adverse happens, revert back to the old settings. The sequence of changes that I went through will be a good sequence, i.e.,
- Turn on buffering
- Change the buffering high water mark
- Increase the buffer size
- Increase the block size