rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rdiff-backup-users] Delete Enough To Finish


From: Andrew K. Bressen
Subject: Re: [rdiff-backup-users] Delete Enough To Finish
Date: Mon, 26 Jan 2004 18:22:00 -0500
User-agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Common Lisp, linux)

Bob Fischer <address@hidden> writes:
> Rdiff-backup will catch not-enough-space errors using a try...catch type
> block.  When such an error occurs, it will do the following:
>  1. Delete ONE increment, using the already-build increment deletion
> feature.
>  2. Try again
>  3. If still not enough space, delete another increment, etc...
>
> The increment deletion would be configured to not delete too much; for
> example, to leave at least two increments, or at least 1 week, etc.  If
> there is not enough space and no more increments can be deleted, then
> rdiff-backup can declare the hard drive to be full.
>
> Is there any reason this could not be implemented?

Seems pretty practical; might not work for everyone, 
but would be useful for many.

The most obvious concern is that one overly large file would cause
all the backups to be pared down to the minimum retain value and
then fail anyway, but assuming one sets a minimum retain value
correctly, I suppose this wouldn't be deadly. 

It occurs to me that if rdiff-backup were given the ability
to blow away stuff in order to make space, 
then if the metadata-diddling features from the wishlist were available, 
it could be given a pretty complex combination of increment 
and file priorities for space management;
ie, 
first blow away all copies of the big file "foo" except for 2, 
then all copies of the not-quite-as-big file "bar" except for 
  the past three months, 
then blow away increments retaining at least five months' worth. 

It has just occurred to me that rdiff-backup may not have to 
in fact perform the backup in order to figure out how much space
it would require; it only needs to do all the work involved in making
the backup and keep count of the results. This would be a trade
of lots of cpu and bandwidth for more precise space management. 
It would still have to do the try...catch iteration in case more
files were created during the run, and I don't know the 
rdiff algorithm well enough to know if it would need much scratch
space.

  --akb




reply via email to

[Prev in Thread] Current Thread [Next in Thread]