Bug 121623 - restore unable to do full restore from multi-volume dumps
Summary: restore unable to do full restore from multi-volume dumps
Alias: None
Product: Fedora
Classification: Fedora
Component: dump   
(Show other bugs)
Version: rawhide
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Jindrich Novy
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-04-23 22:03 UTC by Johnny Stenback
Modified: 2013-07-02 22:59 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-14 12:17:03 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:439 low SHIPPED_LIVE Updated dump package 2005-05-19 04:00:00 UTC

Description Johnny Stenback 2004-04-23 22:03:56 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a)
Gecko/20040422 Firefox/0.8.0+

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)

How reproducible:

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
enough data.

Additional info:

Comment 1 Stelian Pop 2004-04-25 18:01:05 UTC
Hi Johnny

Are you able to reproduce this with the latest dump version from
dump.sourceforge.net ?

Does this also happen if you restore in non-interactive mode (restore
-r) ?

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


Comment 2 Johnny Stenback 2004-04-26 22:30:12 UTC
Hello Stelian,

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!

Comment 3 Johnny Stenback 2004-04-27 06:35:22 UTC
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?

Comment 4 Stelian Pop 2004-04-27 08:31:47 UTC
FYI, the CVS has the same code as the latest released dump-0.4b36.

It would be nice to get it into fc2.


Comment 5 Jindrich Novy 2004-09-14 12:17:03 UTC
Hi Johnny, Stelian,

dump-0.4b37 (available rawhide) will be present in FC3t2 and later and
dump-0.4b36 is in FC3t1.


Comment 6 Tim Powers 2005-05-19 13:37:14 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.