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

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

Re: [rdiff-backup-users] restore old backups fails with gzip error -


From: Hunter Matthews
Subject: Re: [rdiff-backup-users] restore old backups fails with gzip error -
Date: Sat, 02 Jul 2005 13:43:58 -0400

On Fri, 2005-07-01 at 21:25, dean gaudet wrote:
> On Fri, 1 Jul 2005, Hunter Matthews wrote:
> 
> ...
> >   File "/usr/lib64/python2.2/site-packages/rdiff_backup/librsync.py",
> > line 95, in _add_to_inbuf
> >     new_in = self.infile.read(blocksize)
> >   File "/usr/lib64/python2.2/gzip.py", line 163, in read
> >     self._read(readsize)
> >   File "/usr/lib64/python2.2/gzip.py", line 227, in _read
> >     self._read_eof()
> >   File "/usr/lib64/python2.2/gzip.py", line 247, in _read_eof
> >     raise ValueError, "Incorrect length of data produced"
> > ValueError: Incorrect length of data produced
> 
> hey could you try a higher -vN setting to see if it will let you know 
> which file it's having trouble with?  -v7 is very verbose, but you might 
> need to go that far.
> 
I've debugged this. If its not a rdiff-backup bug (i'm biased at the
moment) its at least a serious misfeature..

rdiff-backup has this interesting property that it doesn't care a bit if
its incremental, dir and other files are compressed or not. So I made a
copy of all 32GB of backup stuff for that host and gunzip'd it by hand,
thinking either the python gzip module was nuts or gunzip might give me
more hints.

Tryed the restore AGAIN, and this time got a different failure...
 File "/usr/lib64/python2.2/site-packages/rdiff_backup/rpath.py", line
60, in copyfileobj
    outputfp.write(inbuf)
IOError: [Errno 28] No space left on device

Ah ha. But where I told rdiff-backup to restore has PLENTY of space. 

Frustration, anger, much hate.

Get out ye olde sledgehammer.
address@hidden postgres]# strace -o /local/log rdiff-backup --force -r
2005-05-08 AFTOL-2.custom /backups/restores

Ah /tmp/@blahblah.

rdiff-backup uses a file in /tmp to munge all those incrementals
against, then moves the final file into place. Regardless of whether
/tmp has enough space or where you told it to put the restored
file/tree.

CONCLUSION:
There's an os.tmpfile() [or similar] call in rdiff-backup thats doing
this. Rdiff-backup should be patched either 
a) to use 'tmp' files in the restoration target, with the assumption
that the user requesting restore knew what he/she/it was doing to have
enough space there, but perhaps not on /tmp.
b) add a command line arg to do that.

I think (A) is far more desirable.

> thanks
> -dean
-- 
Hunter Matthews                          Unix / Network Administrator
Office: BioScience 145/244               Duke Univ. Biology Department
Key: F0F88438 / FFB5 34C0 B350 99A4 BB02  9779 A5DB 8B09 F0F8 8438
Never take candy from strangers. Especially on the internet.





reply via email to

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