Date: Wed, 24 Jul 1996 09:06:21 +600 CDT From: "Larry Dolinar" <LARRYD@bldg1.croute.com> To: questions@freebsd.org Subject: dump is quick, restore not (?) Message-ID: <8D156DD57E8@bldg1.croute.com>
next in thread | raw e-mail | index | archive | help
greetings...
backup unit (gnome/dumphost):
hardware:
486dx2-66
16MB RAM
Adaptec 1542CF
Maxtor Panther 1GB SCSI hd
basic vga
3C509 NIC
Sony SDT-5000 4mm DAT
software:
2.1.0-RELEASE, generic
client (ishm2):
hardware:
Sparc2, 32MB RAM
variety of Seagate HDs, 1 internal, 2 external
software:
SunOS 4.1.3, generic
dump 0udsbf 61000 10240 126 dumphost:/dev/nrst0 <filesystem>,
blocksize previously set to 1024
Dumping the 5 filesystems takes about 1:45. This is somewhat comparable
to backing up our Novell network with the same unit (DOS: Arcada
BackupExec).
The surprise came yesterday when one of the designers needed to retrieve
some files off one of the dump (level 0) tapes. The dumps are stacked on
the tape, so we use
rsh dumphost mt fsf 4
(TAPE envar set to /dev/nrst0/) on the Sparc to get to the right "volume".
Pretty quick, no big deal.
We then tried the interactive mode on the Sparc:
restore -ivf dumphost:/dev/nrst0
and the bloody thing ran for two hours without comment; a separate dump
listing (restore tvf /dev/nrst0 > extdisk2.dmp.log) ran almost 6MB on
'gnome', and took less than a minute to generate. So we tried
restore -xvf dumphost:/dev/nrst0 <name of dir>
which is a jawbreaker of a path (see below). After about 45 minutes it
extracted all the directory branches, but no files, then said
You have not read any volumes.
Enter next volume#:
To which I answered "1", as it all made it onto 1 tape. Prior to
answering this question I verified that there were in fact no files in
the directory structure. After about an hour it extracted 1 file. It
ran all night; about 14 hours later it had extracted 1437 out of 1444
files, determined by
grep 14059.fld extdisk2.dmp.log | grep -c leaf
on 'gnome' (and messages on 'ishm2' compared to the above command without
-c and a quick screen count).
To my greater surprise, the files I thought still hadn't restored to
'ishm2' *were there* when I brought up a shell. The base directory was
verified missing before any of the restore activity took place, so the
files had to have come from the restore session (or alien lifeforms are
involved 8).
Clearly I'm an idiot; what am I doing wrong with the restore that it
should take many times longer to read a tape than it does to write it?
waiting for enlightenent,
larry
ps. you have to admit, most of my questions aren't run-of-the-mill...
pps. the directory name: ./cdxdata/unws/BACKZ1UPZ5TOZ4DEL.cab/14059.fld
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8D156DD57E8>