> Finding the sweet spot for the fragment size is a time 
> consuming task as each of our environments is different.

You're kidding, right?

I have never known anyone to tune this.  Ask about it, yes, but "find
the sweet spot?"  What are your criteria and relationships?  How
compressible are your data?  How good is the drive compression on those
data?  Long or short backups?  Multiplexing?  Big restores or
few/scattered files?  How often?

> How much does each 'index' per each fragment take up?

What index?  The NetBackup Media Manager System Administrator's Guide
describes the format.

> Say I backup 200GB to an LTO2 tape, if I write an index every 
> 2GB, how much space is lost due to the file markers?

Again, there is no index.  To calculate this, you'd need to know the
size of the inter-record gaps on your drive (used to be 0.6" in
reel-to-reel drives), length of the medium, linear density
(bits-per-inch), number of passes required for the head(s) to write all
tracks on a serphentine tape, inter-block gap size, physical block size,
guesstimate of the compression ratio, and maybe a few things I've
forgotten.  Would be far easier to determine empirically.

> I know the file markers immensely speed up the restores, 

Not really.  It should only come into play if you're restoring
individual files with drives lacking fast-locate-block capability or
restoring part of a multiplexed set (see the MM SAG; I've never tested
the mux part).

> but what is the impact of them on backups?  Has anyone thought of
this?

IMO, if you are spending time thinking of this, you are seriously
overmanaging trivial hardware details.  It's not the '60s any more.

> Also, what if the fragment size is 32GB and the backup is 
> exactly 32GB? Are two fragments written or one?

Yes.  :-)  See technote 280018 for a pre-5.1MP5 or pre-6.0MP2 bug
related to this.