D'oh! Backup issue solved

Well, my server, just for my little operation here, has 8 GB of storage at the moment, and I easily can fit that on a 112 meter 8mm tape costing about $4. The EXB8505XL is capable of writing to tape at only 30 MB/min but can accept data at around 20 MB/sec in synchronous mode and buffering it until the buffer's full enough to warrant writing data to the tape. If data comes over the (100 Mbps) net at a rate slower than the tape, it has enough buffer memory to mask the start-stop time. However, there's quite a bit of overhead and the buffer isn't deep enough to buffer backup and resync operations followed by search for the appropriate record to start writing where it left off. I went from standard coax to fast ethernet (TP) just to make certain MY backups would happen over night. My server's TEENSY by comparison with some people's. The family-history-center at a friend's church has on the order of 200 GB of data expanded over the course of several days' time from CD. If they lose one of their drives, it's easier to restore from tape than to spend the time redoing the expansion. That's why backups are preferable. They got an EXABYTE tape library with two of Exabyte's fastest drives in it and a capacity of 48 (?) 14.5GB tapes. NT doesn't handle libraries well with its internal backup SW. It's probably because the driver used to integrate the backup device into the system isn't comprehensive enough. They don't have to run backups often, in fact, only after new material has been added to the system. Expanding a 100 CD set takes lots of time and it should be automatic from the tapes. I'm afraid to see what happens when they try it. please see additional comments below. Dick ----- Original Message ----- From: ajp166 &lt;ajp166(a)bellatlantic.net&gt; To: &lt;classiccmp(a)classiccmp.org&gt; Sent: Saturday, September 02, 2000 7:07 PM Subject: Re: D'oh! Backup issue solved This doesn't push the tapes at all. The 85-90 MB/min isn't that fast. The trick, however, is to keep the tape moving uniformly in one direction. Ethernet, on its best day with a tailwind and a lightly loaded LAN will top out (except in test situations) at about 10-12 Mbytes/minute. With highly structured tests, it can do much better, but for random traffic, with (mostly) only two stations loading the net, that's what I see very often. The tape has to wait for the transfer, so it's got to start the tape moving, find the append point, and go from there until the data runs out again. Each time, it takes longer to move the tape than to transfer the data, yet the data transfer is the rate-determining step. The computer's timing is screwed up if there's any effort to synchronize, the tape drive's efforts are wasted if the computer's behavior is constantly changing, and I haven't a clue what the software does with all this, except that three out of four attempts, no matter which Windows package is used, end in failure. I think it's a flow-control problem that is brought about by the limited imagination of the creators of the software. Sooner or later someone will bring it off. It may be the wrong tool, but it makes all the claims suggesting it should work. SInce the NT tool works so reasonably, I'm disappointed that the Windows tools all seem to fall flat. Up to the time the motherboard I was using croaked, I had an NT box running a mirror of my Netware server, with RAID-5 AND compression (more to increase performance than capacity) as well as the pretty faithful emulation of the Netware interface so I could talk to it from DOS and Win31x without having to load the inordinately large drivers that go with ethernet interface code other than what comes with Netware (and that's plenty big enough). The NT package looks to the DOS stations like a normal Netware server. Whereas I managed to get that part of the setup to work, I hadn't yet managed to get the "easy" part, the Win9x <=> NT interface to work. I figure I can phase out the old Netware if I can get this setup to come to life again. Statistical access LANs are like that. What's more, there's plenty of overhead. With the degenerate case, i.e. only two stations sending lots of data and the remainder mostly quiet, you can get appreciably more, though not as much as I'd like. I only have four stations operating these days, and often two are asleep. It's no trouble doing the backup, yet it takes most of the night. With standard ethernet, even under DOS when I could use the really GOOD software that worked EVERY TIME, I couldn't transfer and record the whole server every night, because it took more than the whole night to do it. With all the drives on the network, it takes more than 24 hours to do the daily "full" backup. Incrementals suck, so I don't use them.