🚀 go-pugleaf

Actually, the DLT40 was way too slow. When I was shopping for a new drive, I
think the DLT-80 had just been released, and there was the M2. I decided I
wasn't going to reward Quantum for sitting on their rear end for years
forcing people into multiple tape drive systems to perform their backups.
They were acting like a monopoly, and I didn't like it. The M2 was superior
in capacity and performance. I think it was the only viable drive at the
time. My experience as a consultant in previous years for customers who had
8mm Exabyte drives left me with the impression that:

1. The drive would break down.
2. Exabyte would be good about replacing it.

I was right. My first drive did eventually die, and Exabyte did replace it.

I never received an error when trying to restore a tape. It was always when
I was writing to the tape. I don't know if streaming below the optimal speed
can be blamed for this or not.

We do have a gigabit link for backups, and at least one of our servers is
more than capable of feeding the M2 more than it can handle. On that server
though, we only backup our source files and skip the larger output files, so
I'm backing up over 100 files per second on average, which ends up being
over 1.5 million files in about 4 hours. I think I need to consider some
sort of disk staging for this. I understand Backup Exec is supposed to have
this sort of feature. I guess I'll look into it. There is a lot of bad
sentiment for both Arcserve and Backup Exec on Usenet. Makes it tough to
choose one.

Regarding the tape load issue, I don't understand why it would only happen
on specific tapes. That is the symptom I saw when the tape drive was above
the drive cage of one of my servers also (regardless of which tape was
used). Are rack mount drives better shielded than tabletop units?

I appologize for being harsh in my original reply. The occasional drive
fault and media problem (with three tapes used per night) combined with
Arcserve's stupidity makes getting a good backup very difficult, and logging
becomes a nightmare.




"Rob Turk" <r.turk@chello.nl> wrote in message
news:3e7443be$0$2227$e4fe514c@dreader6.news.xs4all.nl...
> "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
>
>