Re: [rdiff-backup-users] No space left on device - how to regress that?

[Ben Escoto]

On 24 Oct 2003 10:44:53 +0200 Erik Forsberg <address@hidden> wrote:
> Last night the disk I'm rdiff-backuping to went full. I'm not
> surprised, since the disk is small (temporary solution) and I added a
> whole bunch of data the other day. The traceback is as follows:
...
> IOError: [Errno 28] No space left on device
> 
> Now that's fine - of course rdiff-backup should exit when it can't
> write to the disk. However, the question now his how I recover from
> this situation? If I try to regress the directory I get the same
> problem:
...
> Hmm.. I could probably move the troublesome backup directory to
> another disk and regress it, and then move it back, but that feels
> like a awkward solution. What's the real solution?

I looked a bit more into this problem.  Earlier I said the ideal way
would be to go backwards.  This is true, but I was overlooking the
fact that the metadata file is gzipped and layed out only in a
forwards direction.  So it seems pretty difficult to go backwards.

However, I did notice that there are some files like
file_statistics.*, error_log.*, mirror_metadata.*, etc. associated
with the time getting regressed that are predictibly present (taking
up space), and simply need to be deleted.  Before rdiff-backup would
delete these after processing the increments directory, but I just
updated the stable and development versions to delete these files
first.

Hopefully this half-measure will usually solve the problem in
practice.  In general regressing is a space-freeing procedure, so the
question is just one of temp-space (and keep in mind the backup part
also requires temp space, so it will fail because of lack of space
before the space gets to 0 free).  If in particular cases this doesn't
work, it is possible to take stronger ad hoc measures, like moving the
old log files in rdiff-backup-data temporarily to another location.


-- 
Ben Escoto

pgppSdawmdwje.pgp
Description: PGP signature