remote DLT backup error

remote DLT backup error

Post by Jerr » Thu, 12 Dec 1996 04:00:00



I'm trying to backup to a remote DLT drive (using ufsdump),
and I'm getting the following error:

#!/bin/sh
ufsdump 3uf agsun03:/dev/nrst28 /

  DUMP: Writing 32 Kilobyte records
  DUMP: Date of this level 3 dump: Tue Dec 10 03:00:01 1996
  DUMP: Date of last level 0 dump: Mon Dec 09 09:40:13 1996
  DUMP: Dumping /dev/rdsk/c0t3d0s0 (agsun02:/) to agsun03:/dev/nrst28.
  DUMP: Mapping (Pass I) [regular files]
  DUMP: Mapping (Pass II) [directories]
  DUMP: Mapping (Pass II) [directories]
  DUMP: Mapping (Pass II) [directories]
  DUMP: Mapping (Pass II) [directories]
  DUMP: Estimated 150 blocks (75KB).
  DUMP: Protocol to remote tape server botched (in rmtgets).
  DUMP: Lost connection to remote host.
  DUMP: Bad return code from dump: 1

The DLT drive is a Quantum DLT4000, and it works fine when used
locally. Remote backups to other machines with the same type
DLT drive also work fine. We're running Solaris 2.5 on Sparc 10's.

Any ideas?

Thank you very much,

Jerry Cunningham
UNIX System Administrator
U.S. Census Bureau

 
 
 

remote DLT backup error

Post by Dave Greunk » Thu, 12 Dec 1996 04:00:00



> I'm trying to backup to a remote DLT drive (using ufsdump),
> and I'm getting the following error:

> #!/bin/sh
> ufsdump 3uf agsun03:/dev/nrst28 /

>   DUMP: Writing 32 Kilobyte records
>   DUMP: Date of this level 3 dump: Tue Dec 10 03:00:01 1996
>   DUMP: Date of last level 0 dump: Mon Dec 09 09:40:13 1996
>   DUMP: Dumping /dev/rdsk/c0t3d0s0 (agsun02:/) to agsun03:/dev/nrst28.
>   DUMP: Mapping (Pass I) [regular files]
>   DUMP: Mapping (Pass II) [directories]
>   DUMP: Mapping (Pass II) [directories]
>   DUMP: Mapping (Pass II) [directories]
>   DUMP: Mapping (Pass II) [directories]
>   DUMP: Estimated 150 blocks (75KB).
>   DUMP: Protocol to remote tape server botched (in rmtgets).
>   DUMP: Lost connection to remote host.
>   DUMP: Bad return code from dump: 1

> The DLT drive is a Quantum DLT4000, and it works fine when used
> locally. Remote backups to other machines with the same type
> DLT drive also work fine. We're running Solaris 2.5 on Sparc 10's.

> Any ideas?

> Thank you very much,

> Jerry Cunningham
> UNIX System Administrator
> U.S. Census Bureau

First of all.... It would be a lot easier to reply to you if somewhere
in you message there was a return e-mail address. Please check you mail
configuration as my system cannot figure out how to send e-mail to
"Jerry".....

Next, the last time I saw a problem similar to this it was caused by a
badly configured .cshrc file on the machine that has the tape drive.
Basicly, the ufsdump on your machine needs to start a non-interactive
shell on the machine with the tape drive to run /etc/rmt which talks to
the tape drive locally. If that shell trys to do an interactive type
thing (like stty) to this non-interative shell you'll see that kind of
error. Fix the .cshrc (if you're running csh) and everything should work
properly assuming this is the same type of problem.

Good luck...

        Dave

--
-------------------------------------------------------------------------------


Noran Instruments, Inc.     |
Middleton, WI.              |
(608)836-4125               |

Look, look, see Windows 95.  Buy, lemmings, buy!  
Pay no attention to that cliff ahead...            Henry Spencer

(C) 1996 Dave Greunke

Redistribution via the Microsoft Network prohibited
The above opinions are my own and probably do not reflect those of my
employer.

 
 
 

remote DLT backup error

Post by Rene Barbi » Sat, 14 Dec 1996 04:00:00



>I'm trying to backup to a remote DLT drive (using ufsdump),
>and I'm getting the following error:

>#!/bin/sh
>ufsdump 3uf agsun03:/dev/nrst28 /
[snip]
>  DUMP: Protocol to remote tape server botched (in rmtgets).
>  DUMP: Lost connection to remote host.
>  DUMP: Bad return code from dump: 1
>The DLT drive is a Quantum DLT4000, and it works fine when used
>locally. Remote backups to other machines with the same type
>DLT drive also work fine. We're running Solaris 2.5 on Sparc 10's.

I tried to send this by E-mail but your address is not complete.

From the SUN admin FAQ :

62)     My rdump is failing with a "Protocol botched" message. What do I do?

        The problem produces output like the following:

          DUMP: Date of this level 0 dump: Wed Jan  6 08:50:01 1993
          DUMP: Date of last level 0 dump: the epoch
          DUMP: Dumping /dev/rsd0a (/) to /dev/nrst8 on host foo
          DUMP: mapping (Pass I) [regular files]
          DUMP: mapping (Pass II) [directories]
          DUMP: estimated 8232 blocks (4.02MB) on 0.00 tape(s).
          DUMP: Protocol to remote tape server botched (in rmtgets).
         rdump: Lost connection to remote host.
          DUMP: Bad return code from dump: 1

        This occurs when something in .cshrc on the remote machine prints
        something to stdout or stderr (eg. stty, echo). The rdump command
        doesn't expect this, and chokes. Other commands which use the rsh
        protocol (eg. rdist, rtar) may also be affected.

        The way to get around this is to add the following line near the
        beginning of .cshrc, before any command that might send something
        to stdout or stderr:

        if ( ! $?prompt ) exit

        This causes .cshrc to exit when prompt isn't set, which
        distinguishes between remote commands (eg. rdump, rsh) where these
        variables are not set, and interactive sessions (eg. rlogin) where
        they are.

HTH,

--

IRIS                            http://www.irislink.com/
Rue du Bosquet 10
B-1348 Louvain-la-Neuve Belgium

 
 
 

1. Remote backup error.

When I run the next shell script in the host "machine1":

tar cvfb - 20 \
        /edesur/datos/d04/TOPO/DATOS_AUX* \
                | rsh machine2 dd of=/dev/rst0 obs=20r

to make a remote back up on the "machine2" tape, I get the follow
output:

a /edesur/datos/d01/PROD/cntrlPROD.dbf 57 blocks
stty: TCGETS: Operation not supported on socket
a /edesur/datos/d02/PROD/cntrlPROD.dbf 57 blocks
a /edesur/datos/d03/PROD/cntrlPROD.dbf 57 blocks
a /edesur/oracle/dbs/cntrlPROD.dbf 57 blocks
a /edesur/oracle/dbs/PROD/log_01.log 30721 blocks
a /edesur/oracle/dbs/PROD/log_02.log 30721 blocks
a /edesur/oracle/dbs/PROD/log_03.log 30721 blocks
a /edesur/oracle/dbs/initPROD.ora 4 blocks
a /edesur/datos/d01/PROD/DATOS_AUX_01.dbf 20484 blocks
a /edesur/datos/d02/PROD/ORO_01_01.dbf 102404 blocks
a /edesur/datos/d03/PROD/INDICES_01_01.dbf 1945604 blocks
a /edesur/datos/d04/PROD/INDICES_02_01.dbf 1638404 blocks
3191927+864322 records in
189966+0 records out

What means " stty: TCGETS: Operation not supported on socket "?
Otherwise the backup ends ok.

Environment

OS              Solaris 1.1     Sun OS 4.1.3
Machine         Sparc Station 10
Tape            8mm 2.5 Gb External SCSI

Thanks in advance
                                        Diego Sanchez
------------------------------------------------------------------------------
* SION Telematica *
Buenos Aires - ARGENTINA
Voice: +541-469-1334 -> Modem: (+541)656-9195 / (+541)469-1335
------------------------------------------------------------------------------

2. how remove to big files

3. ?Automating backup + remote backups?

4. Ugrade from linux-jdk to native

5. Large DLT tape backup system...

6. Linux and Adaptec SCSI

7. Problems with DLT tape backup unit

8. Anyone using Slimnote8 and/or CL7543?

9. dlt backup/autoloader

10. DLT 7205-311 (DLT 7000) settings

11. DLT/8mm backup solutions

12. backup software and DLT libary

13. DLT backups, cpio or tar?