>>I understand this - it's the effect of collocation.

>I am not sure this statement is correct.
>Collocation attempts to keep data for a particular node either all in one
>tape or all data for one file space in one tape. This is not directly
>related to how many scratch tapes are used.

Sure it is.  Suppose you have three nodes collocated in a brand new storage
pool, you have several tapes in the scratch pool, and the storage pool has
a high maxscratch value.  The first backups on each node will go to
separate tapes -- so far, three tapes used in the pool.  Let's say NODE1
has used 80% of VOL001, NODE2 has used 25% of VOL002, and NODE3 has used
only 5% of VOL003.  Next backup on NODE1 (which is a very volatile machine)
needs to backup 50% of it's data again.  So it mounts VOL001 and writes
until the volume is full.  But there is still more to backup... but NODE1
can't use VOL002 or VOL003 because of collocation, so it grabs a new
scratch tape (VOL004).

So collocation, in general will use more scratch tapes, and will have more
tapes FILLING, than the same nodes in a non-collocated pool.  The payback
of collocation is supposed to be faster restores due to not having to wade
through other nodes' data.  However, in practice, after many months or
years of backups, a restore will still have to go through its own inactive
files to find the active ones to restore (or the correct inactive ones for
a Point In Time restore).

Perhaps what we need is a way to "defragment" a node's already backed up
data... resort it by active/inactive then by date... so all the active
versions are contiguous.

Robin Sharpe
Berlex Laboratories