- Do you know what you get when you mix rdiff-backup and a disk full
error? I do now:
File "/var/lib/python-support/python2.6/rdiff_backup/regress.py", line
290, in restore_orig_regfile
tf.write_from_fileobj(rf.get_restore_fp())
File "/var/lib/python-support/python2.6/rdiff_backup/rpath.py", line
1195, in write_from_fileobj
copyfileobj(fp, outfp)
File "/var/lib/python-support/python2.6/rdiff_backup/rpath.py", line 64,
in copyfileobj
outputfp.write(inbuf)
IOError: [Errno 28] No space left on device
Besides being a royal pain in the ass you won't believe me when I tell
you that to repair this requires actual surgery on the filesystem.
Here's a bug report [savannah.nongnu.org] and a thread
that discusses the issue more widely
[comments.gmane.org]
- The solution I found was to find a couple of really large files (MOVs
in fact) in the rdiff-backup-data subdirectories and move them around to
a separate filesystem while running --check-destination-dir. Hopefully
that won't error out completely -- still running.
- Ah, indeed rdiff-backup can cope with that -- it basically creates
zero-sized files where it would have placed the original file and moves
on. In my case it's slightly more complicated to interpret because this
is actually a recovery pass (using --check-destination-dir) from a
backup that failed and therefore the recovery pass is trying to recreate
files in the rdiff-backup master directory which are actually deleted in
the live system. But that's easier to amend later!
- The best solution I've found to this problem, so far, is to keep some
easily-freed large files on the filesystem. That way, even if you /do/
run out of space and crash, well, you can move them away and then
recover.
|