Recommended settings for Ultrium 4 (HP1760)
I am experiencing poor performance when backing up a new HP X1600 NAS server to a directly attached SAS Ultrium 1760 with Backupexec 12.5
All the latest firmware, patches etc have been installed but the backup job averages around 600MB/min.
On a drive partition that whole a small number of very large files (1GB) the performance increases up to 1925MB/min.
Restores also perform OK at around 1800MB/min.
Are there any recommended settings for the buffers, block size, etc on the Ultrium 1760?
Currently it is set to the default of 64K block and 64k buffers with count of 10.
We have many HP proliant servers running ultrium 1,2 and 3 which perform much better on older disk subsystems, so this does seem particularly slow.
Any advice much appreciated.
DanW
Comments
I've found sometimes better
I've found sometimes better performance using the OEM's drivers over Symantec's. They are often updated more often and may provide additional performance.
Now since it's smaller files, that sounds about right, for the slower backup vs larger files. This is normal behavior. Can you get more speed, perhaps? It depends on a lot of factors, and the biggest bottleneck could just be NTFS, file fragmentation, and poor disk tuning.
You want to benchmark your NAS and see what kind of throughput you can get when doing an FTP transfer, and disk to disk transfer. May want to give HDTach a shot for some low level benchmarks as well.
For the drive itself, try a larger block size.
There is an online portal, save yourself the long hold times. Create ticket online, then call in with ticket # in hand :-) http://mysupport.symantec.com "We backup data to restore, we don't backup data just to back it up."
RE: Recommended settings for Ultrium 4 (HP1760)
Those settings should be OK. You could try setting the buffer to 128 or 512K if you want, as long as you have sufficient RAM to handle things
As tervia-boy says, though, lots of small files will always backup slower than a few large files totalling the same backup size. This is due to the overhead involved in accessing and opening the smaller file as opposed to just streaming the larger once accessed
If this response answers your concern, please mark it as a "solution"
Would you like to reply?
Login or Register to post your comment.