You can find instructions for what you are asking here:
How to Backup a File System to Tape (System Administration Guide: Devices and File Systems) - Sun Microsystems
However, it is generally accepted security policy not to use rhosts and in the clear connections between systems (especially since ufsdump is typically run as root). I prefer to pipe the ufsdump output through ssh and use dd at the other end to send the dump stream to the tape. This gets a little more complicated, but it's manageable.
I set up a dump user who has access to the tape device. I set up ssh certificates for automatic login for that user, and otherwise restrict what that user can do. You can get instructions on how to do the automatic login here:
OpenSSH Public Key Authentication
I also prefer to use fssnap to snapshot the file system and then ufsdump the snapshot. That improves your odds of getting a good backup on a live system, which is a good thing to do even if you are doing it in the middle of the night and expect it (a server, say) to be somewhat quiescent anyway.
Then, when I have the ufsdump run in a script as root, the command sequence looks something like this:
WHICHSNAP=`/usr/lib/fs/ufs/fssnap -o raw,bs=$SNAPSHOTS,unlink $PARTITION`;
/usr/lib/fs/ufs/ufsdump ${LEVEL}cnlTfuN 2h - $RAWDEV $WHICHSNAP | \
su - backup -c "ssh $TAPESERVER \"dd obs=64b of=$TAPDEV\"';
/usr/lib/fs/ufs/fssnap -d $PARTITION;
That's a somewhat simplified extract from a script I've been using on Solaris 9 systems with a dds/3 drive for a couple of years. Obviously, on the other system, you have to stage the tape and make sure it is available. When you toss in error checking/reporting and so in, it gets more complicated. At some point, it works alright, but you say to heck with it and jump to a more serious backup solution like Amanda. All depends on where you are on the curve and how many systems you have to deal with.
You should do man pages on ufsdump and fssnap to understand the parameters they are called with and how they work.
