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 <[email protected]>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 [email protected] via Backup Central. > |Forward SPAM to [email protected]. > +---------------------------------------------------------------------- >
