Feature proposal: backup classes

[Gavin Carr]

On Wed, Apr 08, 2009 at 12:47:27AM -0700, Martin Atkins wrote:
> What is the use-case for this?
>
> In my (admittedly limited) experience, classes of backups have been used 
> either where there is a variety of backup media with different 
> characteristics available, or where different datasets are being backed up 
> to the same target.
>
> I'm having trouble imagining why you'd want to distingish "classes" of 
> backup from the same source to the same medium.

Yes, I'm talking same source, same medium.

> Can you elaborate a bit on what you're trying to achieve?

The typical use case is to be able to differentiate retention levels
for different backup frequencies, since you typically want to keep 
more copies of recent backups than of old ones. If I need to go back
a year, I don't really need to be able to specify to the hour which 
backup it was. But if I need data from yesterday, hourlies might be
a quite appropriate backup granularity to want to support.

> (If you *are* talking about different media, then presumably this problem 
> can be solved with different backup sources and targets. Your example at 
> the end of having backups with "daily" and "monthly" in their names seems 
> functionally equivalent to having three sources called "home", "home-daily" 
> and "home-monthly" and pruning the backup files based on name, periodically 
> running a gc to remove orphaned chunks.)

Hmmm, that's a pretty interesting idea - I hadn't thought of that at 
all. I suspect you're right - you could probably implement this in terms 
of multiple sources and targets, and that might be sufficient.

I think to do so you'll end up with lots of repeated stuff in these additional
target and/or source entries, which would be an indicator that class is an 
orthogonal concept to either target or source, and might be worth splitting 
out. But it is an interesting suggestion, thanks - I'll have a try and see how 
it works.

Cheers,
Gavin



> Gavin Carr wrote:
>> One feature that's available in most other backup systems, and
>> currently missing in brackup, is the ability to distinguish 'classes'
>> of backup (like monthly/weekly/daily), and prune or rotate separately
>> within those classes. 
>> I'd like, for instance, to able to tag the first backup of the month as a 
>> 'monthly', and have those backups ignored in the standard prune.
>> Or do monthlies and weeklies and dailies, say, and keep all monthlies, 8 
>> weeklies, and 30 dailies, or whatever.
>>
>> I think this would just be a matter of adding the notion of a 'class' to a 
>> backup, and modifying prune to be class-aware (perhaps initially just 
>> operating on a single class). I'd imagine you'd keep the current
>> behaviour by allowing a 'null' class that's used if one isn't specified.
>>
>> I believe brackup-target list_backups and prune just look at the brackup 
>> file name and metadata rather than looking at its contents, so we probably 
>> want to encode a classname in the brackup filename to keep this behaviour. 
>> Perhaps we could just append a class, if given,
>> to the brackup file name, like this:
>>
>>   home-1233494128.brackup
>>   home-1233548070-daily.brackup
>>   home-1233704988-monthly.brackup
>>
>> which would display in list_backups as:
>>
>>   home-1233494128           Mon 02 Feb 2009 00:20:12         31034846
>>   home-1231679729-daily     Mon 12 Jan 2009 00:20:01         30507171
>>   home-1228050927-monthly   Mon 01 Dec 2008 00:19:10         29264710
>>
>> Thoughts/comments? 
>> I'm happy to produce some code if there's general agreement on the 
>> concept.
>>
>> Cheers,
>> Gavin
>>
>>
>
>

-- 
Gavin Carr
- http://www.openfusion.com.au - Linux, Perl, and Web Consulting
- http://www.openfusion.net    - Hackery, the Blog
* Fashion is a variable, but style is a constant - Programming Perl