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