malc@tahoe.unr.edu (Malcolm L. Carlock) (10/11/89)
It looks as if we will soon have a number of MS-DOS PC's attached to our TCP/IP network here, and there is some interest in backing up these PC's onto a central, networked tape drive or drives. My questions: - Are there any packages allowing full and incremental backups/restores of MS-DOS machines over a TCP/IP network to a tape drive - on a remote Unix system ? - on a remote MS-DOS system ? I'd be interested in both recommendations and experiences regarding such software (if it exists...) I will summarize email responses to the net. I would also be interested in hearing any folkore regarding doing such things over Novell networks, etc. Thanks in advance, Malcolm L. Carlock malc@unrvax.unr.edu uunet!unrvax!malc
les@chinet.chi.il.us (Leslie Mikesell) (10/12/89)
In article <3029@tahoe.unr.edu> malc@tahoe.unr.edu (Malcolm L. Carlock) writes: >It looks as if we will soon have a number of MS-DOS PC's attached to our >TCP/IP network here, and there is some interest in backing up these PC's >onto a central, networked tape drive or drives. My questions: >I would also be interested in hearing any folkore regarding doing such >things over Novell networks, etc. I just tried something that I didn't expect to work using AT&T's starlan DOS server. I made a link from /dev/rmt/c0s0 (a 125M streaming tape in a 386 unix server) to a file named "tape" in my home directory which is linked as drive H: to a PC on the network. From the PC, I used GNUtar (compiled for DOS) and from drive C: (local hard disk) executed: tar cvf h:tape . and it actually created a tape that I could read back under dos or unix. Amazing... and I was just about to waste a month or so cobbling up some kind of netbios<->tli connection to do exactly that. Les Mikesell
dab@asylum.SF.CA.US (Dave Bridgham) (10/13/89)
FTP's PC/TCP also provides a way to backup PC's over the net. If your unix machine is a berkeley derivative (i.e. has rexec or rsh and rmt) then you can backup directly to a tape (or file) using the tar program. It also can do a form of incremental backup. The incremental backup was supposed to be patterned after unix's backup/restore, but I didn't understand fully and it's a little different. Quite usable, but potentially confusing to people who are used to unix. David Bridgham
keithe@tekgvs.LABS.TEK.COM (Keith Ericson) (10/19/89)
In article <9792@chinet.chi.il.us> Les Mikesell writes: >I just tried something that I didn't expect to work using AT&T's starlan >DOS server. I made a link from /dev/rmt/c0s0 (a 125M streaming tape >in a 386 unix server) to a file named "tape" in my home directory which >is linked as drive H: to a PC on the network. From the PC, I used >GNUtar (compiled for DOS) and from drive C: (local hard disk) executed: >tar cvf h:tape . >and it actually created a tape that I could read back under dos or >unix. Amazing... and I was just about to waste a month or so cobbling >up some kind of netbios<->tli connection to do exactly that. I just tried the same with an AT386Clone (Intel 301-based) running AT&T SysVR3.2 with Wollongong TCP/IP and their NFS for the server and another AT386Clone (Everex STEP/25) running DOS3.3 and Sun's PC-NFS. I got what Les expected: it didn't work... Firstly, the first UNIX system had /usr and root as separate file system. so I couldn't create the link from /usr/me/tape to /dev/rmt/c0s0. Additionally, that system didn't have the Wollongong NFS installed on it, either and when I tried to install it the X11.3 conflicted with it. So I decided to (just?) rebuild the system from scratch with root and usr on the same filesystem and without the X Windows... OK, got that done, and install the Wollong TCP/IP and NFS packages. Make the link from /usr/me/tape to /dev/rmt/c0s0 (and tapen --> c0s0n). Turn back to the DOS/PC-NFS machine to see what I can do. Not much... The files "tape" and "tapen" simply don't exist, EXCEPT that I can't create a file named tape or tapen in the /usr/me directory, so it kinda' knows it's there. Dir, ls, and PC-NFS's "ls" command all fail to report the presence of the "tape" file. OK, maybe its 'cuz I'm still running version 3.0 PC-NFS. Dig out the 3.01 release and do the upgrade. Finally get that done, except that unfortunately I had copied - and was using - some (incompatible, as it turns out) 3.0 utilities (in aliases) so I spent the morning re-installing 3.0 AND 3.01 again to get that resolved. But in the end I'm unable to even SEE my tape file/link from the PC, much less tar or cpio into it. I can cpio to a "real" file on the remote directory (and the UNIX cpio reads it with a "lost file header" error at the end of the extraction - everything looks ok...) Anyway, Les has had better luck than I. Must be that the Starlan is a DOS server? Any suggestions? Is it hopeless? kEITHe
les@chinet.chi.il.us (Leslie Mikesell) (10/19/89)
In article <6183@tekgvs.LABS.TEK.COM> keithe@tekgvs.LABS.TEK.COM (Keith Ericson) writes: >OK, got that done, and install the Wollong TCP/IP and NFS packages. Make >the link from /usr/me/tape to /dev/rmt/c0s0 (and tapen --> c0s0n). Turn >back to the DOS/PC-NFS machine to see what I can do. Not much... The files >"tape" and "tapen" simply don't exist, EXCEPT that I can't create a file named >tape or tapen in the /usr/me directory, so it kinda' knows it's there. Dir, >ls, and PC-NFS's "ls" command all fail to report the presence of the "tape" >file. How about FIFO's? Can you: /etc/mknod fifo p and see the resulting fifo from the DOS machine? If so, you might be able to execute: dd <fifo >/dev/rmt/c0s0 from unix and write into the fifo from dos (reverse to read). This was the approach that I tried first, but the Starlan Dos server apparently sets the O_NDELAY mode which makes a write() return with an error if the pipe fills instead of waiting for the process on the other end to catch up (pretty useless IMHO). I would prefer to use something like that because it would allow talking to an arbitrary unix program from any dos program that reads/writes files sequentially, and in the case of the tape drive it would allow reasonable block sizes to be used to keep the tape streaming longer. Les Mikesell les@chinet.chi.il.us
dan@rna.UUCP (Dan Ts'o) (10/23/89)
In article <6183@tekgvs.LABS.TEK.COM> keithe@tekgvs.LABS.TEK.COM (Keith Ericson) writes: )In article <9792@chinet.chi.il.us> Les Mikesell writes: ))I just tried something that I didn't expect to work using AT&T's starlan ))DOS server. I made a link from /dev/rmt/c0s0 (a 125M streaming tape ))in a 386 unix server) to a file named "tape" in my home directory which ))is linked as drive H: to a PC on the network. From the PC, I used ))GNUtar (compiled for DOS) and from drive C: (local hard disk) executed: ))tar cvf h:tape . ))and it actually created a tape that I could read back under dos or ))unix. Amazing... and I was just about to waste a month or so cobbling ))up some kind of netbios<->tli connection to do exactly that. ) )I just tried the same with an AT386Clone (Intel 301-based) running AT&T )SysVR3.2 with Wollongong TCP/IP and their NFS for the server and another )AT386Clone (Everex STEP/25) running DOS3.3 and Sun's PC-NFS. I got what )Les expected: it didn't work... ) )Firstly, the first UNIX system had /usr and root as separate file system. so )I couldn't create the link from /usr/me/tape to /dev/rmt/c0s0. Additionally, )that system didn't have the Wollongong NFS installed on it, either and )when I tried to install it the X11.3 conflicted with it. So I decided to )(just?) rebuild the system from scratch with root and usr on the same )filesystem and without the X Windows... A small point: UNIX shouldn't care whether the tape device is called /dev/rmt/c0s0 or /usr/me/tape. Instead of trying to link them, which you can't across filesystems, just make another inode called /usr/me/tape as a duplicate of /dev/rmt/c0s0: /etc/mknod /usr/me/tape c ## ##. No need to make root and /usr the same filesystem. It sounds like Starlan DOS server supports device sharing, even if inadvertently, while Wollongong doesn't and assumes any special UNIX files (devices, fifo's, etc) should be hidden from DOS... too bad.