Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!blake!ogccse!verdix!nomad From: nomad@verdix.com (Lee Damon) Newsgroups: comp.sys.hp Subject: Re: backup HP-UX systems over e-net Message-ID: <269@verdix.verdix.com> Date: 16 Mar 89 00:41:01 GMT References: <263@verdix.verdix.com> <210005@speclab.bgp-usgs.gov> Sender: netnews@verdix.com Reply-To: nomad@verdix.com (Lee Damon) Organization: Verdix Western Operations; Aloha, OR Lines: 110 Here are the solutions that were suggested. I thank all of you, plus the people who posted. Yes, RDUMP _is_ necessary, unfortunatly... nomad ------------- From: Steve Fullerton You might take a look at the afio program which should be on most of the usenet archives. It supports very large blocks as well as some network support (afio must be installed on both systems). I'm not sure of the speed as it also utilizes remsh. You could also try to write a simple program on the HP that opens a socket and sends across large buffers and on the remote BSD system, utilize the inetd daemon to monitor the socket, and then schedule the necessary program to open the tape drive and write. I did this a while back and it went something like: find / -depth -print | cpio -oBc | netsend -h hostname The netsend program opened the socket and sent across buffers of 5120 bytes (standard cpio). On the other system, I had a program called netrecv that was scheduled by inetd that opened the tape device, read the buffers, and wrote them to tape. Simple handshaking was implemented to support multiple volume tapes. I haven't used this since I started with afio, but I still build enough of a local backup to restore a system that can then restore files across the net; otherwise, that backup on the other system doesn't do much good. ------------ From: Dave Taylor Organization: guest of Hewlett-Packard Laboratories Something that I like is the backup scheme being implemented by Epoch Systems for their Epoch-1 NFS-based network file server; the client machines 'subscribe' to a backup service on the Epoch-1, and then simply make their file systems available for remote NFS mounting. The server regularly initiates an NFS connection with the client and grabs a copy of whatever has changed on that file system, copying it onto the local file system (either winchester or optical, it supports both). An easy way to apply this in a typical situation would be to devote a machine + disk or two to "backup services" and then to have the machine regularly mount the 500 Meg (Eagle?) disk remotely and spin across it, copying any changed files onto its *own* hard disk. Once that is done, the connection is dropped and the backup server would then begin the slow process of writing the data onto a slower media. Actually, thinking about it, this algorithm could be considerably speeded up by having the machine with the 500 Meg disk create what we could call a 'prefetch data file' that contains the fully-qualified names of all files that have been changed or otherwise require backing up. The remote connection would then be much much faster because instead of opening every directory on the remote file system, it would request just the files that it needs to have. In addition, the prefetch file could also contain an indication of file sizes, aiding the remote machine in ascertaining on-the-fly whether there is enough local storage space available. Another approach would be to have a shadow or other duplicate of the 500 Meg disk and swap 'em back and forth as a backup strategy... this is not a great solution unless your site is under great stress since it's very performance expensive to do true disk shadowing, and the off-line alternatives end up with just as much of a performance hit as doing the slow backup in the first place! The places this makes sense are typically high demand data processing centers, like banks, airline reservation systems, and so on. An easier solution would be to purchase a faster backup media or system. There are a number of different solutions from Hewlett-Packard in this domain that you might consider, including the relatively new 9145 dual-density cartridge tape drive, which gives you twice the capacity on the same tape AND is supposed to write to the tape significantly faster. HP is also rumored to have a digital audio tape backup system queued for release some time in early 1989, if they haven't already released it to the public. That will give you, through the HP/Sony DAT format, massively greater storage facilities (like you could make a COMPLETE copy of your disk on one tape, I believe!!) and considerably faster I/O throughput speed. [HP-IB is slow...] It's because of this bus problem that writing directly to the network could prove to be a win; I don't know what the exact performance numbers are, but I wouldn't be suprised to find that you could dump data out onto a low-traffic network faster than you could to a slow HP-IB device. ------------ From: uunet!stepstone.com!aad@verdix.com (Anthony A. Datri) My solution has been to mount the things I want backed up via nfs and tar it off onto tape. This works for me becuase the total of our hpux disks is less thana 2400 foot tape. If your total is bigger than your biggest remote tape drive, then you might use the publically-available pdtar, which will run everything through compress on its way to the tape. Or, buy an exabyte, like I'm trying to. -------------------- ============= Lee Damon work: verdix!nomad or nomad@verdix.com \ play: {agora,tessi,verdix}!castle!nomad or nomad@castle.fidonet.org \ fidonet: The Castle BBS, 1:105/302, 503-641-3161 / \ "God" created man in its image, and man being ever humble returned the favor.