This is a discussion on Re: Backup Exec slow as Molasses, fast if you spend more $$$ - Veritas Backup Exec ; You must have misunderstood me, I stated I was having throughput problems with all of my drives (including an SDT-7000 and two SDT-9000), not just the TR5. Switching to TCP/IP did in fact solve the problem. As for "shoe-shining", my ...
You must have misunderstood me, I stated I was having throughput problems
with all of my drives (including an SDT-7000 and two SDT-9000), not just
the TR5. Switching to TCP/IP did in fact solve the problem.
As for "shoe-shining", my SDT-7000 was a master at this. Often times, I couldn't
even fit *4GB* on a 4/8GB DAT!
I don't recall saying anything about my TR5 giving a varying capacity, not
sure what you mean by this. I know that BE often times will report a lesser
amount of MBs after backing up. This has nothing to do with Netware's file
compression, btw. I'm talking a straight DIR command compared to what BE
reports. I don't see how anyone could confuse 400MB with 600MB. But BE can.
I don't believe this has happened with version 8.5.
Anyhow, now that I have TCP/IP going my TR5 drive doesn't shoe-shine as much,
hardly at all. 1500KB is pretty close to its max throughput.
>I've had such horrible luck with TR-4 drives on servers (three
>installed, three removed and replaced with DATs, all failed
>within a year, or never really worked) that I haven't
>even looked at the TR-5s, but I really doubt that switching to
>TCP/IP will resolve your problem...
>The TR-4 drives (I'm going to assume the TR-5s are much the same)
>require a very fast data stream, otherwise, they have an data
>underrun, which causes the "shoe shine effect" you noticed (the
>stop, back up, stop, go forward again, repeat cycle). I've
>noted that some of the IDE TR-4 drives on Windows 9x do better,
>as they will figure out they aren't getting the data stream they
>need, and they slow down accordingly (and by slowing down the
>tape speed, they actually speed up the backup process!). I've
>not seen that in the server (SCSI) drives (or is it the server
>DAT drives (and Exabyte 8mm drives, too) handle slower data
>speeds much more elegantly. Well, sorta. The tape moves much
>slower, so they don't do the stop, backup, stop, resume cycle,
>they just stop. MUCH less mechanism wear, much less noise,
>better performance on a slow data stream, etc. Problem is, you
>LOOSE the data space where the tape coasts to a stop. The more
>underruns you have on a DAT or 8mm drive, the lower the actuall
>data capacity of the drive. Thus, it is impossible to tell on a
>DDS or DDS2 drive how much space is left on a tape until it
>ejects and says "Give me another" (at which point you know:
>zero! I recall seeing somewhere that either DDS-3 or DDS-4 was
>supposed to address this. Not sure if software would help you
>on this, even if my memory is correct). Now, elsewhere, you
>reported that your TR-? drive was giving varying capacity, which
>*isn't* supposed to be the case, as I understand it! Perhaps
>they did something DATish on the TR-5?
>Anyway, the TCP/IP *may* give you better performance, but I
>doubt it will be sufficient to keep a TR-5 drive "fed" over the
>wire. I think your *real* only solution would be to either put
>a backup drive on the workstation, or switch to DAT. (The backup
>on the WS is probably the cheapest solution...)
>I'm curious to see how your TR-5 experience goes.
>>I'm using Netware SB 4.2 and BE 8.0. My workstation backups are pretty
>>I did a bit of research and it turns out this is due to BE using the SPX
>>protocol. My highest throughput rate is about 750KB. This causes my tape
>>drives (SDT-7000s/SDT-9000s/Aiwa TD-20001) to stop, wait for data, go,
>>wait, go. This slows things down even more. Also, I end up wasting GB's
>>tape space, not to mention the added wear on the motors.
>>After reading the tech notes it looks like the only solution is to use
>>however, after searching through more tech notes I discovered 'TCP/IP'
>>be selected in the Job Manager/Options/Agent window UNLESS I purchases
>>Enterprise Edition. We're talking huge $$$$ here. Are there any other remedies
>>or should I be looking at another backup program?