🚀 go-pugleaf

"Captain Obvious" <someone@somewhere.net> wrote in message
news:ZkLca.44798$JE5.43634@news2.central.cox.net...
> Depending on the server in question, my average speed is between 5.5 and 8
> MB per second.
>
> Regarding reliability, it's like this: I'll put a tape in, and Arcserve
> can't see the tape. Another tape will work fine. Another problem I've
> discovered is that my external M2 drive is poorly shielded. When I placed
it
> on top of another rackmount server, it would not function if it was above
> the drive cage area of the server. We also run into tape drive media
errors
> on occasion. Maybe your explanation applies to that particular problem.
>
> Regardless of whatever "excuses" you have to offer, and regardless of the
> supposed superiority of the media, I get errors frequently. I backup my
> Nonstop server with DLT 40. In the last three years, I've had ZERO errors.
> None. DLT 40 had the same track record when I was using it to backup NT
> servers before the M2 drive also. Maybe my technique is wrong, but for me,
> M2 has not been reliable enough for me to consider running full backups on
> the weekend, and partials during the week. I run full backups every day.
>
> A lower speed drive isn't an option since I'm considering purchasing
> Netbackup someday to be able to multiplex jobs to the tape at one time. If
> doing so would actually increase the reliability of my tapes, I should
> probably consider doing that now.
>

First of all, if my intent was to give you excuses, then I could have simply
ignored your message and make life easy on myself. I don't get paid to be
present on these newsgroups.

Your message shows exactly why it's important to look at the cause of your
issues. Your description about how moving the drive from one spot to another
changes it's behaviour is a clear sign of electrical trouble. M2 is just as
well shielded as any other decent product in the market, it wouldn't get
accepted by FCC or any OEM if it wasn't. If the drive is in Exabyte's
original external enclosure, it's surrounded by a full steel case, RF
shields included. Your symptoms point to bad grounding, ground loops, faulty
cables, or a bad power supply. Did the drive post an error on it's display,
or did the *software* tell you the drive was bad? More on that later...

Your DLT40 is a perfect match for you 5-8MB/s data rate. It is driven
exactly how it needs to be driven. Your Mammoth2 needs 12-30MB/s and it's
starved for data. Your server isn't bad, your M2 isn't bad, the two are
simply not a good match. Since you mention considering software to increase
throughput, I'd suggest doing that sooner rather than later. When/if you
migrate to another fast technology like SDLT or LTO-1/2, you'll need all the
performance you can squeeze out of your system to keep them running. Make
sure the rest of your environment can actually handle such high speeds.
8MB/s sound pretty much like a maxed-out 100Mb/s Ethernet segment, consider
using a Gigabit trunk if you want to benefit from multiplexed backups. And
be aware that multiplexing increases restore time...

Backup software is a single piece of the entire backup chain. That chain
goes all the way from your client disk, OS and 'client software', through
your network, and then through your backup server OS, drivers, hardware onto
the tape. The software driving it (ArcServe in your case) has the most
powerful interface to you as the user, as it's in your face when you run it.
When a failure of the chain occurs, the software gets to bring the bad news.
It chooses which error to display. When something unexpected occurs, it will
*ALWAYS* point to some other component and blame it for the failure. In your
case, did the M2 drive actually post an error? If so, I'm sure you can send
a diagnostics dump to Exabyte support and have it checked. What associated
error showed up in your server's system event log? The point I'm trying to
make is that your software may not be flawless.

Two weeks ago I spent a week in the lab at Exabyte HQ collecting SCSI bus
traces and logs on a symptom just like the one you describe, but on Netware.
ArcServe loads a tape in the tape drive, rapidly sends out three SCSI Load
commands to which the drive responds it's busy loading the tape, then all
activity on the SCSI bus just stops. The software never checks back if the
drive has completed the load cycle. It just sits there, claiming there's no
tape in the drive. Stopping ArcServe and starting my own diagnostics shows
that the tape is perfectly accessible. Running BackupExec shows it's
perfectly accessible too (with it's own set of idiosyncracies..)

You are not the only one seeing this. Other people are running into the same
issue, also with other technologies like VXA and Sony's AIT. CA sofar has
been a brick wall, they say everything is just fine. They blame Exabyte,
Sony, Adaptec, Novell and their mother-in-law for all failures, but their
software is perfect. They don't want to look at the data we gathered that
shows differently. Only now, after talks on corporate level, are we starting
to make headway on getting this resolved.

Good luck on your next technology choise.

Rob