SUMMARY: backing up an SGI 02 to Sun Tape drive

From: Lisa Weihl (
Date: Fri Apr 24 1998 - 12:13:02 CDT

Hi all--

Here is the summary of replies to my request for help in trying to backup
an SGI workstation using xfsdump to a tape drive on a Sun server.

Quite a few people are using a tar|rsh dd type or xfsdump to stdout| rsh dd

Joel Turoff, Mark Bergman, Mike Salehi and Eric Greenwade hit the nail on
the head when they said rmt on the SGI doesn't match the rmt on the Sun.
Mark told me that depending on which version of IRIX you are running (6.3
on my O2) you may need to patch you xfsdump.

I contacted the admin who is setting up these machines on campus to ask
about getting the maintenance contract # to try and get the patch. In the
process I found out he had been patching the remaining systems he has and
he now had version 3.0 of xfsdump whereas mine was version 2.0. I had no
-m or -b switches as many of you (including my local admin) recommended
using until I patched it.

I have patched but haven't tried it. I thought I was getting through using
rsh but....I'm still having problems even doing a simple rsh to the Sun
machine as root from any of our other machines. That was a separate post I
had which I'm going to summarize after this.

Thanks to the following for their replies:

Mark Bergman
Joel Turoff
Mike Salehi
Eric Greenwade
Rik Schneider
David Fitzgerald
Colin Melville
Brian White
David Thorburn-Gundlach
Mark Hargrave
Anthony Worrall
Philip Plane
Bill Armand
Phillips Nguyen
Chris Marble


Selected text from resposnes below.......

tar cvfb -20 files | rsh remote_host dd of=/dev/nrst0 obs=20b has worked
for me from a Solaris 2.6 to Solaris 2.5.1 box. If tar is the same on the
O2 perhaps this will give you at least some type of backup.


I have used amanda, a backup package from the University of Maryland, to
back up mixed networks including Sun, SGI, DEC, DG, Linux. It's free and
it works well. Setting up the first time can be a struggle, but it's worth
the effort.

Home page is at


I think you also need the -m option when the remote machine is non-SGI. This
will force ufsdump to use version 1 rmt protocol for all remote tape drives.
The block factor can be specified by -b.


I haven't had much success in backing up our SGI's to our
remote Sun tape drive. Someone gave me this example of
a possible remote command to try:

rsh sgi -n xfsdump -l 0 -F - / | dd of=/dev/nrst0 obs=128k

Where: /dev/nrst0 is the local tape drive on the Sun.


Finally, xfsdump on an SGI is problematic, depending on the version of the
OS you have. There is a bug in xfsdump that prevents it from working
properly on some systems. There is a patch out there for some versions.
What you'll need to do is logon to and do a search on
xfsdump. You will see a lot of posts to Usenet about the problem and
should be able to determine whether your system can be patched.

I have a script that uses xfsdump in conjunction with rsh and dd to backup
an SGI to a sun. Here's the script. It seems to make a backup, but I
haven't taken the time yet to determine the inverse command sequence to
restore files. I'll burn that bridge when I get there (unless you feel
motivated and want to send me the commands :-). Anyways, here's the
script. The remote machine is called sun and the tape drive is /dev/rmt/0:

xfsdump -l 0 - / | rsh sun dd obs=56k of=/dev/rmt/0n
xfsdump -l 0 - /disk2 | rsh sun dd obs=56k of=/dev/rmt/0


Are you _sure_ that as root on the O2, you can issue commands to the
remote Sun? What about something simple, like:
        O2 # tar cf - /etc | rsh maestro dd if=- of=/dev/nrst0
just for confirmation?

You don't say which version of Irix, or what xfsdump patch version
you are running. That is important. I've also got an O2 that I back
up remotely to my Sun tape drive. The key is that xfsdump assumes
that it's talking to another SGI, and uses version 2 of the rmt
protocol. Sun only speaks version 1 of rmt. The easy solution is to
make sure that you've got the most current version of xfsdump (the
version on my Irix 6.3 CD was not the most current), as the new
version supports the -m (minimal rmt protocol) option. That option
also requires the -b (block size) option.

My xfsdump command line looks something like:
/usr/sbin/xfsdump -F -m -l $DUMPLEVEL -b 245760 \
        -f $BACKHOST:$NRTAPEDEV $filesystem 2>&1 | \
         grep -v "^remote shell program that invoked \/etc\/rmt does not
exist" > $TEMPFILE

The weird grep line is because xfsdump _still_ tries the newer rmt
protocol before falling back to level 1, and generates spurious
error messages. I want to filter out those errors.


Try something like this from your SGI machine:

  bru -cvf - <filesystem_to_back_up> | rsh <SUN_tape_host> dd bs=1024

Just make sure that the backup user on the SGI machine is listed in the
.rhost file on the SUN machine.


Lisa Weihl, System Administrator E-mail:
Department of Computer Science Office: Hayes 225
Bowling Green State University Phone: (419) 372-0116
Bowling Green, Ohio 43403-0214 Fax: (419) 372-8061

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:39 CDT