I agree with the principle of what you say, though it is only practical if your storage units are configured in a way that allows that. It would be pretty easy and sensible for example with Oracle servers that have SAN Media Server, and hence a Storage Unit that is only used to backup the Oracle server's own data, to set a large fragment size, as the files are likely to be large. Looking at the output of bpimaglelist is a good way to do this, see http://www.encephalon.com/perl/veritas-Netbackup_bkrep.txt.
However general purpose Media Servers cannot really do this, so a compromise is needed. I agree with Brian Bahnmiller that the tape accelerate/decelerate time is a major factor in performance of the backups, and the fragment size needs to be large enough to reduce the significance of this. I'm not sure I agree that modern tapes can get round the need to fast position to the file, and then slow scan the file. As I understand it NetBackup is tracking the fragment (effectively file on tape) in which a file is located, so for a restore it can use this to fast position. That I believe is the reason to keep the fragment small, though as Gideon Wheeler says it depends on the file size. I guess the ideal would be that the fragment exactly matched the file size so each file was a fragment, for this purpose only - clearly unattainable unless you have very neat data file sizes. Opinion seems to be that a size > 8GB, maybe 16 or 20 and as much as 32GB is sensible. I must admit that is much less than I was thinking, given the default for NBU 6 is 1TB! My rough calculation suggests that at ~60MB/s a 32GB fragment takes a little over 9 minutes to write, and a 16GB fragment just over 4 1/2 minutes. So in terms of seeing the fragments tick up one can take a choice. I think the larger fragment does more to reduce the accelerate/decelerate time, so I think I will try that and see how it goes. Hopefully I can find time to test this in our lab. As we are looking at D2D2T using SLPs, it is also affected by the fragment size on the disk staging storage unit (actually AdvancedDisk). Those are large, designed to make the destaging go fast. In fact I wonder if I can aim for that ideal that each disk fragment exactly fits each tape fragment, i.e. make them the same size or at least an exact multiple. On disk I care about how many fragments there are as it will affect the performance of the file system if there are millions of small fragments. Thank you all for the responses. William D L Brown veritas-bu-boun...@mailman.eng.auburn.edu wrote on 17/09/2009 06:42:46: > I agree a 2GB fragment size for an LTO3 / 4 drive is a little on the > small size, but rather than choosing the fragment size to fit the > tape technology perhaps it would be useful to select fragment size > based on the type of the data we are backing up. Large single file > data such as image, audio or exported databases etc. would benefit > from using the larger fragment sizes. Database Agent orientated > backups such as RMAN / MSSQL could use a fragment size based on > their fileset size or multiple thereof. Whilst User home accounts, > source code project directories would use the smaller settings. Of > course all this only applies to non NDMP backups. > There is an advantage of using fragment sizing in that?s it a great > way of determining tape throughput. It?s easy to calculate the speed > of a backup if you know that its taking t minutes to backup a 2 or > 20GB fragment rather than waiting t hours for a terabyte. > Psychology: Nothing is more re-assuring then seeing the fragment > markers count up in the job details panel. Its good indicator that > all is well with that client. > As to the overhead of fragment markers in the catalogue I have no idea. > Just my 2-bits worth. > > Gideon Wheeler_______________________________________________ > Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu ----------------------------------------------------------- This e-mail was sent by GlaxoSmithKline Services Unlimited (registered in England and Wales No. 1047315), which is a member of the GlaxoSmithKline group of companies. The registered address of GlaxoSmithKline Services Unlimited is 980 Great West Road, Brentford, Middlesex TW8 9GS. ----------------------------------------------------------- _______________________________________________ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu