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: Always 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:
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 happening. Stelian.
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!
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. Stelian.
Hi Johnny, Stelian, dump-0.4b37 (available rawhide) will be present in FC3t2 and later and dump-0.4b36 is in FC3t1. Jindrich
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. http://rhn.redhat.com/errata/RHBA-2005-439.html