[Top][All Lists]
[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.