kjh@visual1.jhuapl.edu (Kenneth J. Heeres) (04/24/91)
I have a DECstation 5000 running Ultrix 4.1 and I do not have
a decent way of backing up the system. I do not currently have
any tape device attached to the system and I do not have control
of another UNIX system that has a large capacity tape drive.
I do have:
A large MVS system running IBM's TCP/IP with tape drives up
the yazzoo. This system does not support rdump.
A VMS system running VMS Ultrix Connection with Exabyte drives.
This system does not support rdump.
I have looked at ftp's the dump up to these systems but it looks
as though all alternatives require that I have room on the work-
station for the dump. Is this true????
Does anybody have any cost-effective alternatives or suggestions.
ken
--
==========================================================================
Kenneth J. Heeres The Johns Hopkins University
INTERNET: kjh@visual1.jhuapl.edu Applied Physics Laboratory
Johns Hopkins Road
Laurel, MD 20723-6099bennett@mp.cs.niu.edu (Scott Bennett) (04/25/91)
In article <1991Apr24.140354.25607@aplcen.apl.jhu.edu> kjh@visual1.jhuapl.edu (Kenneth J. Heeres) writes: >I have a DECstation 5000 running Ultrix 4.1 and I do not have >a decent way of backing up the system. I do not currently have >any tape device attached to the system and I do not have control >of another UNIX system that has a large capacity tape drive. > >I do have: > A large MVS system running IBM's TCP/IP with tape drives up > the yazzoo. This system does not support rdump. > > A VMS system running VMS Ultrix Connection with Exabyte drives. > This system does not support rdump. > >I have looked at ftp's the dump up to these systems but it looks >as though all alternatives require that I have room on the work- >station for the dump. Is this true???? dump(8) can do a dump to a specified file, which is also how you dump to a tape device other than the default tape. Does your MVS system have the NFS server support running? If so, how about dumping to a file on that server via NFS? That way you wouldn't need rdump(8). If your MVS system doesn't have enough disk space to hold a complete backup cycle, you could then offload each dump file to tape from MVS once it had been created via NFS from your DECstation. > >Does anybody have any cost-effective alternatives or suggestions. > >ken > >-- >========================================================================== >Kenneth J. Heeres The Johns Hopkins University >INTERNET: kjh@visual1.jhuapl.edu Applied Physics Laboratory > Johns Hopkins Road > Laurel, MD 20723-6099 Scott Bennett, Comm. ASMELG, CFIAG Systems Programming Northern Illinois University DeKalb, Illinois 60115 ********************************************************************** * Internet: bennett@cs.niu.edu * * BITNET: A01SJB1@NIU * *--------------------------------------------------------------------* * "Spent a little time on the mountain, Spent a little time on the * * Hill, The things that went down you don't understand, But I * * think in time you will." Oakland, 19 Feb. 1991, first time * * since 25 Sept. 1970!!! Yippee!!!! Wondering what's NeXT... :-) * **********************************************************************
duncan@comp.vuw.ac.nz (Duncan McEwan) (04/26/91)
In article <1991Apr24.140354.25607@aplcen.apl.jhu.edu> kjh@visual1.jhuapl.edu (Kenneth J. Heeres) writes: >I do have: > A large MVS system running IBM's TCP/IP with tape drives up > the yazzoo. This system does not support rdump. > > A VMS system running VMS Ultrix Connection with Exabyte drives. > This system does not support rdump. All that is needed to support rdump is a way of running "/etc/rmt" via the rcmd(3) library call (ie via rsh(1). /etc/rmt should be relatively easy to port to a non-unix environment. If your VMS or IBM machines don't support rsh(1) then it gets a little harder... Duncan
mjr@hussar.dco.dec.com (Marcus J. Ranum) (04/26/91)
duncan@comp.vuw.ac.nz (Duncan McEwan) writes: >All that is needed to support rdump is a way of running "/etc/rmt" via >the rcmd(3) library call (ie via rsh(1). It's actually easier than that. Since /etc/rmt expects to be reading and writing to its standard output, you can just put it (on a UNIX box, anyhow) where inetd will launch it. On other machines, you might need to put a few little hacks into it to make it bind a known port. /etc/rmt doesn't have any notion of permissions, so I have a version that reads an /etc/tapecap file with host/device/user permissions and a bunch of similar stuff. This code is going to be released when I've tested it for a while longer. (along with other useful supporting code) There is some brain-damage in the rmt protocol - the tape ioctl commands *assume* that the values of the mtops are the same, which is a bit of a nono, and, more amusingly, in some spots it passes data structs back and forth, without any concern at all with respect to byte order, and whatnot. (the status/'S' op, for example). Unfortunately, lots of people seem to use it, so it's hard to make it right. I thought about fixing it for my version, but that meant I'd have to hack dump/rdump, too, which is pure evil. For non-dump/rdump archives I have a client that just handles talking directly to the remote rmtd and stores its standard input. mjr.
vince@bcsaic.UUCP (Vince Skahan) (04/26/91)
In article <1991Apr24.140354.25607@aplcen.apl.jhu.edu> kjh@visual1.jhuapl.edu (Kenneth J. Heeres) writes: >I have a DECstation 5000 running Ultrix 4.1 and I do not have >a decent way of backing up the system. I do not currently have >any tape device attached to the system and I do not have control >of another UNIX system that has a large capacity tape drive. > >I do have: > A large MVS system running IBM's TCP/IP with tape drives up > the yazzoo. This system does not support rdump. > > A VMS system running VMS Ultrix Connection with Exabyte drives. > This system does not support rdump. > >I have looked at ftp's the dump up to these systems but it looks >as though all alternatives require that I have room on the work- >station for the dump. Is this true???? > >Does anybody have any cost-effective alternatives or suggestions. sure...we (have to) do it this way for many of the same reasons... 1. nfs-mount either the (shudder...) IBM or the (slight shudder) Vax. 2. dump to a file on the remote system with the tape drives via NFS. 3. have the remote system do the backups for you. I've successfully gotten up to 125 MB dump files across to a Vax 6410 running UCX 1.2, but the vax was starting to choke at that size. In a previous job, management was planning to ram the IBM solution down our throats but we fought 'em off and got 5 8mm devices fro the 100 apollos. Here, they keep cutting the 8mm's out of the budget (sigh...). -- Vince Skahan vince@atc.boeing.com ...uw-beaver!bcsaic!vince This is your brain on Phillies baseball. Get the picture?
bennett@mp.cs.niu.edu (Scott Bennett) (04/27/91)
In article <1991Apr26.134612.10406@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. Ranum) writes: >duncan@comp.vuw.ac.nz (Duncan McEwan) writes: > >>All that is needed to support rdump is a way of running "/etc/rmt" via >>the rcmd(3) library call (ie via rsh(1). > > It's actually easier than that. Since /etc/rmt expects to be >reading and writing to its standard output, you can just put it (on a >UNIX box, anyhow) where inetd will launch it. On other machines, you >might need to put a few little hacks into it to make it bind a known >port. > > [remainder deleted --SJB] It's actually easier than that. The originator of this thread said that his network had on it an MVS system running IBM's TCP/IP. IBM's TCP/IP also has software to run an NFS server on the MVS system, so rdump and rmt are not needed for this job. dump(8) can dump to a file specified as a command line option and restore(8) can restore from a file in the same way. All that appears necessary is 1) the MVS system must have an NFS server running that exports a dump data set to the UNIX system and 2) a dump command that dumps to the data set exported from the MVS system. To restore, just specify the same dump data set in the restore command. It is reasonable to assume that the MVS system is frequently backed up to tape. If the UNIX dump data set(s) take(s) up too much space on the MVS system to leave it/them there, it/they can be unloaded to tape and then deleted from the MVS system's disk(s). Scott Bennett, Comm. ASMELG, CFIAG Systems Programming Northern Illinois University DeKalb, Illinois 60115 ********************************************************************** * Internet: bennett@cs.niu.edu * * BITNET: A01SJB1@NIU * *--------------------------------------------------------------------* * "Spent a little time on the mountain, Spent a little time on the * * Hill, The things that went down you don't understand, But I * * think in time you will." Oakland, 19 Feb. 1991, first time * * since 25 Sept. 1970!!! Yippee!!!! Wondering what's NeXT... :-) * **********************************************************************
edler@jan.ultra.nyu.edu (Jan Edler) (04/30/91)
In article <1991Apr24.140354.25607@aplcen.apl.jhu.edu> kjh@visual1.jhuapl.edu (Kenneth J. Heeres) writes: >I have looked at ftp's the dump up to these systems but it looks >as though all alternatives require that I have room on the work- >station for the dump. Is this true???? At least with the 4.3bsd ftp program, you don't need to have room for your dumps on the workstation. Essentially all you have to do is ftp bighost user xxx yyy cd zzz account www binary put "|dump 4uf - /filesys" remote-filename quit Where xxx is the user name on the remote host, yyy is the password, and zzz is directory and account information, if needed. To do a restore, you basically just reverse the procedure, e.g., get remote-filename "|restore ivf -" Of course you can do all this in a shell script run in the middle of the night, and you can be arbitrarily fancy. E.g., ours figures out what level dumps to take, and removes old dumps. Jan Edler NYU Ultracomputer Research Laboratory edler@nyu.edu