[comp.sys.sun] Filesystem Backup using /etc/dump fails......

WINSTON@NUSEEV.BITNET (10/08/89)

I have this problem when trying to do a level zero (0) backup of my SUN
3/140's filesystem. I have done numerous backups before but have never
encountered this problem. I followed the steps as recommended, that is,
first shutdown the system to single user mode, then do a /etc/fsck. After
that then the backup using the following command:

    /etc/dump 0ucbsf 126 3825 /dev/nrst8 /dev/rsd0g

I use 1/4" cartridge tapes for backup, and this is the command that I was
told to use when I attended a system administration course conducted by
the local distributor. /dev/rsd0g is the 'g' partition that is mounted on
/usr.

The problem that I am facing now is as in the following error messages
from /etc/dump,

DUMP: Date of this level 0 dump: .....
DUMP: Date of last level 0 dump: .....
DUMP: Dumping /dev/rsd0g (/usr) to /dev/nrst8
DUMP: mapping (Pass I) [regular file]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 139822 blocks (68.72 MB) on 0.17 tape(s).
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: 35.32% done, finished in 0:09
DUMP: 68.76% done, finished in 0:04
DUMP: Tape write error 5739 feet into tape 1
DUMP: NEEDS ATTENTION: Do you want to restart? :......
 ...

Initially, I thought its due to a faulty tape. But after trying repeatedly
with different tapes, even brand new ones, I still get the same error.
Restarting the dump process doesn't help either.

Has anyone encountered this problem before, and what is the remedy?  I
would be most grateful for whatever advice, remedies, suggestions that you
may have. You can email directly to me or thru Sun-Spots.

Thanks very much.

Winston Seah
Dept of Electrical Engineering
National University of Singapore
Bitnet: winston@nuseev.bitnet

maine@elxsi.dfrf.nasa.gov (Richard Maine) (10/10/89)

In article <1978@brazos.Rice.edu> WINSTON@NUSEEV.BITNET writes:

>  I have this problem when trying to do a level zero (0) backup of my SUN
>  3/140's filesystem. I have done numerous backups before but have never
>  encountered this problem. I followed the steps as recommended, ...
>      /etc/dump 0ucbsf 126 3825 /dev/nrst8 /dev/rsd0g
>
>  I use 1/4" cartridge tapes for backup, and this is the command that I was
>  told to use when I attended a system administration course conducted by
>  the local distributor. /dev/rsd0g is the 'g' partition that is mounted on
>  /usr.
>
>  The problem that I am facing now is as in the following error messages
>  from /etc/dump,
>  ...
>  DUMP: estimated 139822 blocks (68.72 MB) on 0.17 tape(s).
>  ...
>  DUMP: Tape write error 5739 feet into tape 1
>  DUMP: NEEDS ATTENTION: Do you want to restart? :......
>   ...
>  Initially, I thought its due to a faulty tape. But after trying repeatedly
>  with different tapes, even brand new ones, I still get the same error.
>
>  Has anyone encountered this problem before, and what is the remedy?  I
>  would be most grateful for whatever advice, remedies, suggestions that you
>  may have. You can email directly to me or thru Sun-Spots.

Yes, I've been greatly annoyed by this.  The problem basically is that
unix is incredibly stupid about handling end-of-tape situations.  Feel
free to truncate the previous sentence after the "stupid". :-(
Encountering an end-of-tape is considered an error; there is no way to
tell it to just go on to the next tape.  The dump utility relies on being
able to estimate how much will fit on a tape and making sure to not try to
put more than that (minus some pad) on a tape.  That's why dump needs to
know the length of the tapes.

The second part of the problem is that you are not getting dump correctly
informed about the length of your tape.  I can tell because it is
estimating that your 68 megabytes will only take .17 tapes (Somehow, I
doubt that this is right).

The third part of the problem is that it is incredibly obscure exactly how
to tell dump what the tape length is.  If you can figure out what to do
from the man page, you are better than I am.  I finally latched onto

    dump 0cuf /dev/...

just leaving out the bs arguments.  This seems to work ok for 450 foot 1/4
inch tapes (even though the man page says the default is 1700 feet -
argh).  But don't try to use a 300 foot tape.  Thats when I got the error
messages you are seeing.  You can use a 600 foot tape if you want, but 150
feet of it will just be wasted.

You might try the dump command shown above.  If that doesn't work, diddle
with the size parameter until the estimated number of tapes reflects
reality.  You may be able to find someone else that can give you a more
"scientific" interpretation of what the size should be in place of my
"diddle with it".  But I am sure that this is basically your problem.

Richard Maine
maine@elxsi.dfrf.nasa.gov [130.134.1.1]

emv@math.lsa.umich.edu (10/10/89)

It looks like the instructions you're giving to dump make it
think that the tape is much longer than it really is.  (That
would explain the line that says 65 mb on 0.17 tapes -- really
it should take more than 1 tape.)

dump 0fcsnu /dev/rst8 600 $rdevice

is what I use to dump to a 600' cartridge tape on a Sun 4.

--Ed

Edward Vielmetti, U of Michigan math dept.

WINSTON%NUSEEV.BITNET@cunyvm.cuny.edu (10/12/89)

Many thanks to all who responded to my message on /etc/dump problem.  The
cause of it lies in the new version of the /etc/dump command supplied with
SunOS 4.0.x; the size of tape parameter now expects the actual length of
the tape and not the product of number of tracks times length of tape as
in SunOS 3.5. I have tried with the following command and it worked fine,

    /etc/dump 0ucbsf 126 600 /dev/nrst0 /dev/rsd0g

Lastly, many thanks again to all those who responded.

Winston