Dan Langille wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Kevin Keane wrote:
>   
>> Item  n:  implement retention times specified as number of copies.
>>  Date:   4/6/2009
>>  Origin: Kevin Keane - subscription at kkeane dot com
>>  Status: 
>>  
>>  What:   Currently, the retention time for a volume/job etc. is a
>>          fixed number of seconds from the last time the item (volume,
>>          job, file) was written or backed up.
>>
>>          What I would like to see is a retention time based on the last
>>          successful backup at Full or Differential levels instead.
>>
>>          For instance:
>>
>>          Keep Copies = 2
>>
>>          would mean "expire retention time for a file or job when there
>>          are at least two newer copies of the same file/job".
>>  
>>  Why:    There are three benefits to this approach.
>>
>>          1) archiving. If you decommission a server, the last backup of
>>          that server would automatically stay around forever.
>>
>>          2) storage management. Currently, if a full backup is done in the 
>> middle
>>          of a backup cycle, the previous full backup will still be retained, 
>> and
>>          take up space, until its full expiration time.
>>
>>          3) fail safety. If a full backup fails for some reason for several 
>> days
>>          in a row, the current retention-time mechanism may still allow the
>>          previous full backup to expire, leaving you potentially with no 
>> good backup
>>          at all.
>>  
>>  Notes:  This feature may only makes sense for jobs and files, maybe not for 
>> volumes.
>>          I haven't fully thought through the implications yet.
>>          The interaction between "Keep Copies" and "Volume Retention"
>>          needs to be defined.
>>          A possible alternate implementation might be to have a relative
>>          retention time instead of the number of copies: keep a backup until
>>          two days after the next full backup. I believe that "Keep Copies" is
>>          better, though, because the relative retention time mechanism would 
>> not
>>          allow for an easy mechanism to specify that you want to keep several
>>          full backups before expiring the oldest one.
>>     
>
> - From a programming point of view, have you thought about the algorithm
> which could be used to determine "2 copies"?
>   
For the jobs, it should be pretty simple to do with a single database 
query. Simply count the last two backups of jobs with the same name and 
the appropriate levels. BTW, I just realize that my spec is a bit vague: 
does one differential + the previous full backup count as two backups? 
I'd say, no; it has to be two differentials.

For the files, theoretically it should also be pretty simple to do, but 
it would probably be unacceptably slow to do that way.

Maybe this feature should only be implemented for jobs? That's where it 
would be most useful anyway.

-- 
Kevin Keane
Owner
The NetTech
Find the Uncommon: Expert Solutions for a Network You Never Have to Think About

Office: 866-642-7116
http://www.4nettech.com

This e-mail and attachments, if any, may contain confidential and/or 
proprietary information. Please be advised that the unauthorized use or 
disclosure of the information is strictly prohibited. The information herein is 
intended only for use by the intended recipient(s) named above. If you have 
received this transmission in error, please notify the sender immediately and 
permanently delete the e-mail and any copies, printouts or attachments thereof.


------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users