remotely tar files on a backup tape from another machine

remotely tar files on a backup tape from another machine

Post by Quang Dangtr » Sat, 24 Jul 1993 05:03:12



Hello,
I am trying to figure out a way to remotely backup or restore files
on a tape which is not physically connected to a machine from which
I am currently logging on.
Is there such a way?>
Thanks.
 
 
 

remotely tar files on a backup tape from another machine

Post by Thanh » Sat, 24 Jul 1993 06:28:08



>Hello,
>I am trying to figure out a way to remotely backup or restore files
>on a tape which is not physically connected to a machine from which
>I am currently logging on.
>Is there such a way?>
>Thanks.

From what I read, if you are using SYSV then RFS will allow you to share
devices. I have not tried it though. So it you succeed, please share with me.

--
--
Thanh Ma


 
 
 

remotely tar files on a backup tape from another machine

Post by Frank Thom » Sun, 25 Jul 1993 11:34:48


: Hello,
: I am trying to figure out a way to remotely backup or restore files
: on a tape which is not physically connected to a machine from which
: I am currently logging on.
: Is there such a way?>
: Thanks.

I assume that the data you want to backup is on the machine you are
logged into, and you want to restore files to that same machine.  That
being the cse, you'll find exactly that problem answered in the tar
man pages in the example section (~85% of the way down).  The commands
discussed there are:

to backup files:
        tar cvfb - 20 filenames | rsh host dd of=/dev/rmt0 obs=20b
to recover files:
        rsh -n host dd if=/dev/rmt0 bs=20b | tar xvBfb - 20 filenames

I haven't used these commands in a while, but as I recall, they worked
just fine with out all the blocksize junk.
--
___________________________________________________________________________
Frank Thomas, Lead Electrical Engineer   office 19/401
Harris Aerospace Systems                 phone 407-676-7791
PO Box 94000, MS19-4844                  fax 407-727-4016

 
 
 

remotely tar files on a backup tape from another machine

Post by Loc T. » Mon, 26 Jul 1993 04:41:01



: : Hello,
: : I am trying to figure out a way to remotely backup or restore files
: : on a tape which is not physically connected to a machine from which
: : I am currently logging on.
: : Is there such a way?>
: : Thanks.

: I assume that the data you want to backup is on the machine you are
: logged into, and you want to restore files to that same machine.  That
: being the cse, you'll find exactly that problem answered in the tar
: man pages in the example section (~85% of the way down).  The commands
: discussed there are:

: to backup files:
:       tar cvfb - 20 filenames | rsh host dd of=/dev/rmt0 obs=20b
: to recover files:
:       rsh -n host dd if=/dev/rmt0 bs=20b | tar xvBfb - 20 filenames

: I haven't used these commands in a while, but as I recall, they worked
: just fine with out all the blocksize junk.
: --
: ___________________________________________________________________________
: Frank Thomas, Lead Electrical Engineer   office 19/401
: Harris Aerospace Systems                 phone 407-676-7791
: PO Box 94000, MS19-4844                  fax 407-727-4016

        You may also take a look at GNU tar and GNU cpio. They are both
        available on prep.ai.mit.edu:/pub/gnu

 
 
 

remotely tar files on a backup tape from another machine

Post by A. Bryan Curnu » Mon, 26 Jul 1993 16:19:12



>I am trying to figure out a way to remotely backup or restore files
>on a tape which is not physically connected to a machine from which
>I am currently logging on.

Some versions of tar support remote devices, usually using
a command line that looks like

    tar tvf crusher:/dev/rst0

assuming that the remote machine's hostname is "crusher" and the
remote tape drive is "/dev/rst0".

If your version of tar does not support this, or the remote machine
does not support the "rmt" remote tape server, you may need to
install (or have your system administrator install) GNU tar, which
supports remote tape drives and includes source for rmt.

GNU tar is available via FTP from ftp.uu.net as
    systems/gnu/tar-1.11.2.tar.gz
You'll need GNU zip to
uncompress the files; GNU zip is available from ftp.uu.net in
    systems/gnu/gzip-1.2.3.tar

(Both are available elsewhere, but I'm not on the Internet so I
can't quickly check the exact locations at other sites...)
--
Bryan Curnutt                                  Stoner Associates, Inc.

 
 
 

remotely tar files on a backup tape from another machine

Post by Raymond Shwa » Mon, 02 Aug 1993 02:31:54



>From what I read, if you are using SYSV then RFS will allow you to share
>devices. I have not tried it though. So it you succeed, please share with me.

        Yes, it can be done using RFS. From two of our SVr4 boxes (one
using Dell 2.2, the other USL SVr4.2) we "export" /dev/rmt (including the
device file c0s0 referencing our 4mm R-Dat). On another box, we "mount"
system:/dev/rmt under /dev/system. We can then access that R-dat as
/dev/system/c0s0. We were transcribing at least 200kb/sec over the net.
Real nice, and more intuitive (not to mention more secure) than using rsh.

        Sadly, though, RFS is not widely supported due to its UNIX-only
focus, and many vendors are expected to *drop* that support. Perhaps someone
in the know will advise whether AFS or DCE support remote device mounting.
--


 
 
 

remotely tar files on a backup tape from another machine

Post by Leslie Mikese » Wed, 04 Aug 1993 12:38:18



>    Yes, it can be done using RFS. From two of our SVr4 boxes (one
>using Dell 2.2, the other USL SVr4.2) we "export" /dev/rmt (including the
>device file c0s0 referencing our 4mm R-Dat). On another box, we "mount"
>system:/dev/rmt under /dev/system. We can then access that R-dat as
>/dev/system/c0s0. We were transcribing at least 200kb/sec over the net.
>Real nice, and more intuitive (not to mention more secure) than using rsh.

How does throughput compare to a pipe to "rsh host mtio" with some
appropriate buffering parameters to mtio?  (Or more likely, rsh'ing
tar or cpio on the remote, piping to a local mtio on the machine with
the tape drive which makes it easier to put several filesystems
sequentially on the non-rewinding device).

Quote:>    Sadly, though, RFS is not widely supported due to its UNIX-only
>focus, and many vendors are expected to *drop* that support. Perhaps someone
>in the know will advise whether AFS or DCE support remote device mounting.

The real problem with RFS device access is that ioctl structs are passed
directly from the remote machine to the device driver, and thus will
only work among machines with the same bit and byte order and the same
struct padding.

Les Mikesell

 
 
 

remotely tar files on a backup tape from another machine

Post by Greg A. Woo » Tue, 10 Aug 1993 03:00:47



> The real problem with RFS device access is that ioctl structs are passed
> directly from the remote machine to the device driver, and thus will
> only work among machines with the same bit and byte order and the same
> struct padding.

This is not quite true.

The original RFS protocol specification specifies that ioctl()
arguments should be transfered using DUICOPYIN and DUICOPYOUT
messages, and that any UNIX data structures that are sent in messages
must be converted to XDR network canonical format.  The routines
tcanon() and fcanon() should be called to perform message conversion.
I believe the newer RFS specification goes even further.

I would suggest that any current full implementation of RFS should
provide transparent device access in a heterogeneous environment.

I have been told that tapes and tty's can be shared between u3b2's and
i386's with UNIX SysVr3.2 and version 2 RFS, though I've never actually
seen this done in practice.

It would be truely sad to see RFS support dropped by the vendors.
--
                                                Greg A. Woods


+1 416 443-1734 [home]                          Toronto, Ontario; CANADA

 
 
 

remotely tar files on a backup tape from another machine

Post by Leslie Mikese » Wed, 11 Aug 1993 04:45:55





>> The real problem with RFS device access is that ioctl structs are passed
>> directly from the remote machine to the device driver, and thus will
>> only work among machines with the same bit and byte order and the same
>> struct padding.

>This is not quite true.

>The original RFS protocol specification specifies that ioctl()
>arguments should be transfered using DUICOPYIN and DUICOPYOUT
>messages, and that any UNIX data structures that are sent in messages
>must be converted to XDR network canonical format.  The routines
>tcanon() and fcanon() should be called to perform message conversion.
>I believe the newer RFS specification goes even further.

How is this supposed to work?  Ioctl() can pass arbitrary structs. How
is a routine going to convert them without needing to know the types
of the contents which may only be known by the sending application and
the driver?

Quote:>I have been told that tapes and tty's can be shared between u3b2's and
>i386's with UNIX SysVr3.2 and version 2 RFS, though I've never actually
>seen this done in practice.

I've tried.  I can't even get tty's to work completely across identical
machines.  Tapes sort-of work among similar machines but you can't
keep them streaming.  It might be reasonable with a DAT or similar
tape with a large on-drive buffer, but otherwise I think you are better
off rsh-ing to a buffering program.

Quote:>It would be truely sad to see RFS support dropped by the vendors.

If NFS had decent file/record locking performance we could probably
live with it instead.  I like the way RFS handles FIFOs but without
a stock method to start a server on the remote machine, everyone will
keep programming with sockets anyway.   RFS has some serious disadvantages
too, like killing off all the processes associated with a mount point
in any way when a link is broken.

Les Mikesell