From owner-freebsd-questions Wed Jul 24 07:06:49 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA20747 for questions-outgoing; Wed, 24 Jul 1996 07:06:49 -0700 (PDT) Received: from croute.com (ishm2.croute.com [199.97.106.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA20736 for ; Wed, 24 Jul 1996 07:06:44 -0700 (PDT) Received: from bldg1.croute.com by croute.com (4.1/SMI-4.1) id AA01835; Wed, 24 Jul 96 09:06:41 CDT Received: from COMPUROUTE/SpoolDir by bldg1.croute.com (Mercury 1.13); Wed, 24 Jul 96 9:06:27 +600 Received: from SpoolDir by COMPUROUTE (Mercury 1.13); Wed, 24 Jul 96 9:06:26 +600 From: "Larry Dolinar" Organization: CompuRoute, Inc. To: questions@freebsd.org Date: Wed, 24 Jul 1996 09:06:21 +600 CDT Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: dump is quick, restore not (?) X-Confirm-Reading-To: "Larry Dolinar" X-Pmrqc: 1 Priority: normal X-Mailer: Pegasus Mail v3.22 Message-Id: <8D156DD57E8@bldg1.croute.com> Sender: owner-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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 , 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 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