Re: [Duplicity-talk] Proposal of new feature

[Stefan Hoth]

Kenneth Loafman schrieb:
> Stefan Hoth wrote:
>> Hello Ken and all the others,
>>
>> first of all: Great job again with the new version, runs very smooth.
>>
>> Now to the real reason of my mail: I was wondering if it would be
>> possible to arrange a quota for every backup-location.
>>
>> My intention would be to keep as many backups as possible but without
>> exceeding the backup space. This way I would be much more flexible when
>> trying to restore older files.
>>
>> What do you think, would this be possible?
> 
> It's possible -- we know the amount of data on the system as soon as we
> do the first operation, list().  What we don't know is how much we're
> going to put on the system.  We would not want to just stop the backup
> mid-stream to enforce a quota, 

Erm, no, I certainly don't want to stop in the middle of a backup.

> so the only option would be to delete old
> backups to get room.  Is that what you would envision?

Deleting old ones would be considered neccessary but...

> 
> Such an action could have unintended consequences, say you remove all
> your previous full backups and this one fails.  Not sure you would want
> to do that at all, in fact I'm fairly certain you would not want that.

... I surely don't want to loose all backups in case of an error. I
guess it should be done like it works with the option when I try to
purge all old backups older than X - if I'm informed correctly duplicity
won't delete the last full backup even if it is older,right?!

> 
> So, yes this could be done.  Do we really want to?

I see the problem - as you mentioned it - in defining how much space the
new backup would need. The best way in terms of using the backup space
optimal might be running a dry step to count the size of all changes.
But this would double the backup time and data transfer since every
update will be processed twice (first count, then real run) - not very
beautiful.

Hmmm, maybe we can add a less optimal parameter to avoid these problem:
If we count the whole source files without testing the differences we'd
have the maximal amount of data (maybe even consider applying an avarage
packaging ratio). With this information we check the backup location for
enough space left and if there's not enough we delete the oldest backups
- but keep at least one full!

This way we waste a bit space cause the backup size is often much less
than the whole source files but it might use the space better than the
static value of time.

(BACKGROUND: For my webserver I got a seperate ftp account on another
server for backup purposes only. Since I often change configuration
files and have several services running on this server I would prefer
going back in time as far as possible if a problem occurs to check the
prexistence of it. Of course keeping old logs is also useful many times.
So I want to fill up the space with my backups without setting a certain
timelimit. I just want to have a secure backup with a little more comfort.)

What do you think of that?
> 
> ...Ken
> 
Stefan

signature.asc
Description: OpenPGP digital signature