Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!husc6!rice!sun-spots-request
From: maine@elxsi.dfrf.nasa.gov (Richard Maine)
Newsgroups: comp.sys.sun
Subject: Re: Filesystem Backup using /etc/dump fails.....
Keywords: SunOS
Message-ID: <2026@brazos.Rice.edu>
Date: 9 Oct 89 22:16:05 GMT
Sender: root@rice.edu
Organization: Sun-Spots
Lines: 61
Approved: Sun-Spots@rice.edu
X-Sun-Spots-Digest: Volume 8, Issue 157, message 2 of 14

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]