If I'm reading what you wrote in the first post correctly, then you're
keeping every version of every file ever created, so long as there is still
a version of the file active on a client.  And when a file gets deleted on
the client, you're immediately purging every version of that file from the
database.  (In this case, "immediately" actually means "during the first
expiration once a backup has run and detected that the file is gone.")  So
if you have enough files changing and not being deleted, then overall, yes,
you could be using a large total quantity of tape space to store all of
those versions, especially if there are databases in the mix.  At the same
time, you're not providing any real recoverability for files that are
accidentally deleted.  If you want to post the output of the "query
copygroup" command it might clarify things.

How to fix it?  First order of business is to decide on what is appropriate
retention for the data, existing and deleted.  It's unlikely that you really
need to keep every version of every current file forever; you could probably
reclaim a good bit of space if you adjusted that.  And get better protection
by increasing the retention of the deleted files (to anything other than
zero, really!).  If you decide to implement collocation for some or all of
the data, you can allow it to happen naturally as data expires and reclaims,
or you can use 'move data' or 'move nodedata' to speed it along.  It's
definitely fixable.



On Tue, Aug 10, 2010 at 1:08 PM, ego3456 <tsm-forum AT backupcentral DOT 
com>wrote:

> wow, so it really is as clear as mud..  :D
>
> my assumption of the retention taking that many tapes was understood by me
> to be a function of not only the shelf life (retention) but the reclamation
> (no we don't use collocation, which I'm well aware we should) shotgunning
> those data bits across a large number of tapes; if all this is true, without
> a large increase in tape library capacity (we have 252 slots) or a large
> increase in disk resources, is there an easy way to fix it?  If not, I'm
> inclined to scrap it all and put in NBU for backups going forward.  saving
> the argument on which is better, I'm an NBU guy and a staff of one, and my
> inclination is if I'm spending buckets of cash, I'm doing it in a way I'm
> familiar.  My first whack though is to try and save this thing so I'm hoping
> someone out there can provide a panacea or at least an incremental
> improvement that is free and time efficient.  am i spitting in to the wind?
>
> +----------------------------------------------------------------------
> |This was sent by ericgosnell AT gmail DOT com via Backup Central.
> |Forward SPAM to abuse AT backupcentral DOT com.
> +----------------------------------------------------------------------
>