Steinar.Haug@elab-runit.sintef.no (Steinar Haug) (03/22/91)
I have a problem when using dump to backup an HP-97549 disk. The dump goes to an Exabyte connected to a Sun workstation. I have used dump on the same machine previously to backup an HP-97548 disk with no problem. Btw, both disks have long filename file systems. The HP is a 9000/400s running HP-UX 7.03. Dump reports: rsh faust -n /etc/dump 0usdf 90000 43200 aida:/dev/nrst8 /mnt DUMP: Date of this level 0 dump: Thu Mar 21 17:14:12 1991 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /mnt to /dev/nrst8 on host aida DUMP: bad sblock magic number DUMP: The ENTIRE dump is aborted. (while on the 97548 disk I get: rsh faust -n /etc/dump 0usdf 90000 43200 aida:/dev/nrst8 / DUMP: Date of this level 0 dump: Sun Mar 10 15:08:14 1991 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/rdsk/0s0 (/) to /dev/nrst8 on host aida DUMP: This is an HP long file name filesystem DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 187753 tape blocks on 0.01 tape(s). DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: 16.99% done, finished in 0:24 etc.) I can use the filesystem, fsck with no errors, etc. Just not dump it. Why? On a related note, does anybody know of software which will allow me to use fbackup/frecover on the HPs for remote dumps to a Sun? I assume I need a somewhat enhanced rmt driver... Using fbackup/frecover would presuambly give me better speed than dump/restore. Steinar Haug, system/networks administrator SINTEF DELAB, University of Trondheim, NORWAY Email: Steinar.Haug@delab.sintef.no, sthaug@idt.unit.no, steinar@tosca.er.sintef.no
Steinar.Haug@delab.sintef.no (Steinar Haug) (03/25/91)
A few days ago I reported on a problem I had when using dump to backup an HP-97549 disk. I found the solution myself this weekend, and thought I would share it with the net. From my original posting: > I have a problem when using dump to backup an HP-97549 disk. The dump > goes to an Exabyte connected to a Sun workstation. I have used dump on > the same machine previously to backup an HP-97548 disk with no problem. > Btw, both disks have long filename file systems. The HP is a 9000/400s > running HP-UX 7.03. > > Dump reports: > > rsh faust -n /etc/dump 0usdf 90000 43200 aida:/dev/nrst8 /mnt > DUMP: Date of this level 0 dump: Thu Mar 21 17:14:12 1991 > DUMP: Date of last level 0 dump: the epoch > DUMP: Dumping /mnt to /dev/nrst8 on host aida > DUMP: bad sblock magic number > DUMP: The ENTIRE dump is aborted. The problem was that the file system was not mentioned in /etc/checklist. I had mounted the filesystem using 'mount /dev/dsk/1s0 /mnt' and simply assumed that this would be okay. I have to say, though, that the error message given by dump is rather far off the mark... Since /etc/checklist *is* mentioned in the man page for dump, I suppose this behavior could be regarded as a feature, though it was not at all obvious to me. On a related note, does anybody know of software which will allow me to use fbackup/frecover on the HPs for remote dumps to a Sun? I assume I need a somewhat enhanced rmt driver... Using fbackup/frecover would presuambly give me better speed than dump/restore. Alternatively, does anybody have a faster dump for HP-UX? On most of our Suns we see dump speeds of around 12 MByte/minute, which is close enough to the Exabyte advertised maximum of 246 kByte/s that I'm not going to complain. On the HPs, the speed is around 6 MByte/minute, ie. only half of the speed of dump on the Suns. I would guess this is because Sun has done a better job of optimizing the dump I/O behavior. Steinar Haug, system/networks administrator SINTEF DELAB, University of Trondheim, NORWAY Email: Steinar.Haug@delab.sintef.no, sthaug@idt.unit.no, steinar@tosca.er.sintef.no