Date: Wed, 20 Nov 2002 16:45:21 GMT From: mike.curtis@imagination.com To: FreeBSD-gnats-submit@FreeBSD.org Subject: bin/45530: multi-volume dump has restore fail Message-ID: <200211201645.QAA96665@mailgate.imagination.co.uk>
next in thread | raw e-mail | index | archive | help
>Number: 45530
>Category: bin
>Synopsis: multi-volume dump has restore fail
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Wed Nov 20 08:50:01 PST 2002
>Closed-Date:
>Last-Modified:
>Originator: Mike Curtis
>Release: FreeBSD 4.5-RELEASE (TESTARKMRC) #3: Sat Aug 31 16:05:12 GMT 2002
>Organization:
Imagination Ltd.
>Environment:
Dell PowerEdge 6450, 1Gbyte ECC RAM
FreeBSD 4.5-RELEASE
dump and restore versions as shipped with FreeBSD 4.5
>Description:
I have a RAID enclosure with 2 x 600Gbyte logical drives. I use one for the
company's work, and the other as a 'spare' of sorts.
Backup of work is obviously my prime concern.
I'm using dump to create multiple 35Gbyte files on the 'spare' disk at night,
then cut these files to DLT tape during the day.
I do this for two reasons:
i) Since 95% of our restores are for 'stupidity recovery', it makes sense to
dump them 'close by' and then restore any 'lost' files interactively using
restore -v -i -f .....
ii) This spare-disk method gives me a week's window in which to cut (using dd
- haven't got that far yet because of this bug) at the very least Friday's
multiple 'full' dump files to DLT tapes, without the need for an expensive
autochanger or jukebox affair.
Dump appears to work fine. However, interactive restore fails across these
multiple dump files.
>How-To-Repeat:
Repeatable known-bad example:
get virgin file system eg /dev/da1s1a
mount it on eg /mnt
make four files on it like this:
mount /dev/da1s1a
cd /mnt
dd if=/dev/urandom of=hello1 bs=1k count=1k
dd if=/dev/urandom of=hello2 bs=1k count=1k
dd if=/dev/urandom of=hello3 bs=1k count=1k
dd if=/dev/urandom of=hello4 bs=1k count=1k
umount /mnt
Make the dump:
cd /tmp/testdump
dump -0 -B 2048 -f 1,2,3,4 /dev/da1s1a
this makes four dump format files
when you try to restore it goes wrong:
restore -i -v -f 1
restore > ls
... 5 hello3 ...
restore > add hello3
restore > extract
If we try the restore in order:
Specify next volume: 1
(tape name) 1
2
2
We get this error:
resync restore, skipped 51 blocks
3
3
You don't get your file back!
hello3 starts somewhere in file '2'
I believe that the bug is in restore rather than dump because
if you do
cat 1 2 3 > 123
restore -i -v -f 123
you can get your file 'hello3' back; however, I don't want to
waste any time potentially having to cat multiple 35Gbyte files
together in an emergency, plus further testing of this produced
differing results.
Here's the script I actually use:
# dodiffbakdisk1
# 7-day differential backups using dump, full on Saturday
# mrc/imagination/06.08.2002
set -e
set -x
DOW=`/bin/date -u +%A`
STAMP="`/bin/date -u +%Y%m%d%H%M%S`__$$"
TAG=dodiffbakdisk1
DUMP=/sbin/dump
DATE=`/bin/date -u +%Y%m%d%H%M%S`
BACKMEUP=/disk/1
# mrc/imagination/23.10.2002: specify multiple 35Gbyte volumes, dump only uses
# as many as it needs. Filesystem is 600Gbytes, so need 18:
BACKUPFILE="bigbox__disk_1__${DATE}_dump.1,bigbox__disk_1__${DATE}_dump.2,\
bigbox__disk_1__${DATE}_dump.3,bigbox__disk_1__${DATE}_dump.4,\
bigbox__disk_1__${DATE}_dump.5,bigbox__disk_1__${DATE}_dump.6,\
bigbox__disk_1__${DATE}_dump.7,bigbox__disk_1__${DATE}_dump.8,\
bigbox__disk_1__${DATE}_dump.9,bigbox__disk_1__${DATE}_dump.10,\
bigbox__disk_1__${DATE}_dump.11,bigbox__disk_1__${DATE}_dump.12,\
bigbox__disk_1__${DATE}_dump.13,bigbox__disk_1__${DATE}_dump.14,\
bigbox__disk_1__${DATE}_dump.15,bigbox__disk_1__${DATE}_dump.16,\
bigbox__disk_1__${DATE}_dump.17,bigbox__disk_1__${DATE}_dump.18"
OPTIONS="-u -B 36700160 -f"
case $DOW in
Saturday) level=0;;
Sunday) level=1;;
Monday) level=1;;
Tuesday) level=1;;
Wednesday) level=1;;
Thursday) level=1;;
Friday) level=1;;
*) exit 1;;
esac
CMD="$DUMP -$level $OPTIONS $BACKUPFILE $BACKMEUP"
logger -t $TAG start $STAMP
$CMD > /tmp/log/dump__$STAMP 2>&1
logger -t $TAG stop $STAMP
# end
>Fix:
Don't know, need help.
Our version of restore has tape.c 1.16.2.6 2001/08/01
.... and it looks like there may be an issue with this already:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/restore/tape.c.diff?r1=1.16.2.6&r2=1.16.2.7&only_with_tag=RELENG_4&f=h
Any help much appreciated: big project deadline looming, can't finish without
multiple test bare-metal recoveries!!!
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200211201645.QAA96665>