Red Hat Bugzilla – Bug 121623
restore unable to do full restore from multi-volume dumps
Last modified: 2013-07-02 18:59:49 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a)
Description of problem:
I run a system (AMD Opteron based, though I see this with RedHat 9 on
x86 based systems too) where I do periodic dumps of my disks onto
another disk. The dumps are split up into ~1GB volumes (for
conventient copying onto DVDs later on).
The problem is that when I try to do a complete restore of the dumps,
restore complains somewhere into the restore (usually on the 2nd, 3rd,
4th, 5th or so volume) restore finds a file that's split up onto
multiple volumes. Sometimes when it finds one of thes files, it
complains that there are missing blocks in the dump, and it assumes
there's a hole in the dump. Then it tries to resync, and continue, and
sometimes that succeeds (but the file on the volume boundary is cut
short) or it just can't resync (reads the rest of the volumes w/o
finding anything else).
Version-Release number of selected component (if applicable):
dump-0.4b33-3 (x86-64) and dump-0.4b28-7 (i386)
Steps to Reproduce:
The dump command I use is:
dump -0 -B 1062400 -q -u -f /somefile. -M -Q /somefile.map /somedir
and to restore I do:
restore -i -b 10 -f /somefile. -M -Q /somefile.map -V
If I catch it complaining about a file (which it almost always does,
depending on the dump, but it's 100% reproducable with some dumps I
have) and I go back and restore only that file (no other files) then
the restore succeeds, so it seems like the dump is ok, but restore
confuses itself when crossing many volume boundaries, or reading
Are you able to reproduce this with the latest dump version from
Does this also happen if you restore in non-interactive mode (restore
Does it also happen if you omit the -Q <file> when doing the restore
(which in fact is not useful, since QFA is useful when restoring only
a few files, it helps speeding up the tape positionning. But since you
are restoring all the data, this is a no-op) ?
I never had reports of this kind of errors before, and if you have a
test case which is 100% reproducable I'm sure we can find out what's
I didn't get a chance to try out the latest version from
dump.sourceforge.net yet, but I did try to restore one of the broken
dumps using restore -r, and that worked! Went all the way through w/o
any errors and w/o resulting in any broken files (i.e. no loss of data).
I'll try to test the latest version and report back. Thanks!
I just pulled the latest version of the source code from
dump.sourceforge.net (through CVS) and compiled it, and now restore -i
works as well!
Any chance to get an updated version into the official release of fc2?
FYI, the CVS has the same code as the latest released dump-0.4b36.
It would be nice to get it into fc2.
Hi Johnny, Stelian,
dump-0.4b37 (available rawhide) will be present in FC3t2 and later and
dump-0.4b36 is in FC3t1.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.