X-Vers: Weeg cc:Mail/SMTP translation (originally by A. Marshall)
Newsgroups: bit.listserv.novell
Date:         Wed, 15 Apr 1992 10:23:00 CST
Reply-To:     Novell LAN Interest Group <NOVELL@SUVM.BITNET>
From:         Netman@PHYSLOG-PO.PHYSLOG.UIOWA.EDU
Subject:      Re: Problems with Cheyenne Arcserve (reprive)
X-To:         Novell LAN Interest Group <NOVELL%SUVM.BITNET@uga.cc.uga.edu>

      Yo Campers!

      Thanks to all who have responded to my earlier problem with
      Cheyenne Arcserve 4.0 losing all my jobs.

      As it turns out, all of your guesses and suggestions
      were entirely off base.  But what the heck, give yourselves a
      big pat on the back for trying! :-)

      Actually, the problem turned out to be hardware: it was the nut
      behind the wheel.  Indeed, a kludge of mine--creating a bogus
      user to avoid all the nagging messages sent by Arcserve--did me
      in when the bogus user's account expired.

      Oddly enough, the process of determining this problem revealed
      another.  (Details later.)

      Several of you have asked me for more particulars on other
      problems with Arcserve, so I have attached some notes I wrote
      for Cheyenne techs.

      -- Cliff


___________________________________________________________________________
Cliff Missen                    |  Other Interests:
Systems Analyst                 |     Third World Development (Africa esp.)
Physiology and Biophysics       |     Appropriate Technology
University of Iowa              |     Computer graphics
(319)335-7880                   |     Desktop Publishing

Internet:  Cliff-Missen@UIOWA.EDU



---------
ATTACHMENT:


Hardware:  IBM Model 80 PS/2
           Adaptec 1640 SCSI controller
           WangDat 2000SE DAT  (2G)


Problems with Cheyenne Arcserve:

I have had the server crash in the following instances:

--when an unformatted tape was mistakenly left in the tape drive
--when a tape formatted by Palindrome was in the drive
--when a tape was full

In these cases, the controller card, which also had the server's
hard disk attached, was reset--causing the server crash.  I know
I could alleviate a good part of the problem by installing a
second SCSI controller for the DAT, but it is and expensive
hardware solution to what appears to be a software problem.

Following each of these crashes I was encouraged by Cheyenne
techs to reinstall Arcserve.  This is not only a time consumming
process, it rendered the database of my past backup sessions
inaccessible.

My recent troubles started with a mistake of my own.  In order to
avoid the incessant Arcserve messages sent to whomever submits a
backup job, I created a bogus user called NETBACK to submit the
numerous repeating jobs and ignore the messages.  (Yes, I know
one can globally silence the messages, but individual users need
to know the disposition of the random jobs they've submitted.)

Well, this message-swallowing bogus user's account expired while
I was out of town.  After the queue's jobs were executed and
Arcserve tried to resubmit the jobs according to their repeat
interval, the jobs were lost since the user NETBACK no longer
existed.

It took me a few days to figure out where all my jobs went.  The
Cheyenne techs were as puzzled as I.  All the while I was
submitting jobs under my own ID and they performed flawlessly.

This story would have stopped with my red-eared discovery of the
expired NETBACK account except for one thing:

As we were experimenting to find out what happened to the missing
jobs, I was prompted by a Cheyenne tech to create a bogus queue.
I did.  I called it BOB.

After discovering the true source of my grief, I resubmitted all
the jobs to their respective queues and later deleted queue BOB.

As BOB disappeared, a message flashed on my screen saying, more
or less, that changes would take effect when Arcserve was
activated next.

That evening, I could not log into the network and found ARCSERVE
error messages on the server console stating the the "queue could
not be found."  I then unloaded the Arcserve NLM, which produced
a message about "Module did not release resources".  Seconds
later I experienced my first ABEND.  The main error message
stated that "Checkmemory found contiguous fragments not pointing
to each other."

As far as I can tell from this experience, deleting a queue can
cause an ABEND!  No fun whatsoever.

Interestingly enough, after rebooting the server, upon the
resumption of backing up the server, I got a message that the
tape was full--although at the finish of the previous backup the
log showed 1.2GB still left on the tape.

I don't know what to say about these problems.  If this were a
perfect world I would not leave unformatted tapes in the drive,
nor would I let my error-swallowing bogus user expire.  But I
don't think that such oversight should bring my server to its
knees.

In such cases, I would expect Arcserve to be able to recover more
gracefully.  Certainly I should not have to reinstall the
software and lose my previous data.  This seems to run counter to
the entire notion of archive security.

Any ideas?
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU