Re: my log says nothing...

[Hunter Parrot]

At 8:27 AM +0200 8/18/00, jakob krabbe wrote:
>I started a script manually of all our computers yesterday and it took 6
>1/2 hours to complete. I watched it all the time and got shure everything
>was right. So I had high expectations for the automatic script at night,
>the log included below.
>
>The first computer was turned off but the second was on and has for the
>past 1 1/2 years never made any headache. When the PC didn't respond, why
>didn't it move on to the next computer? There are a total of 14
>volumes/folders/computers that are backed up and they worked during the day.
>

>
>-  2000-08-17 22.00.26: Copying Arbeten on PC_01
>   2000-08-17 22.00.26: Connected to PC_01
>   Media Request timeout after waiting 00.30.00
>   2000-08-17 22.30.57: Execution incomplete
>   Remaining: 8383 files, 1,8 GB
>   Completed: 0 files, zero KB
>   Performance: 0,0 MB/minute
>   Duration: 00.30.31 (00.30.14 idle/loading/preparing)
>
>   2000-08-17 22.30.58: Execution incomplete
>   Total duration: 00.30.31 (00.30.14 idle/loading/preparing)
>   Quit at 2000-08-17 22.31

Jakob, the third line in the log above was generated after Retrospect
waited for the correct backup media, ie tape, CD-R, whatever.  So the tape
"4 - thursday"  was not in the drive.  If you do a recycle backup to any
storageset, the corresponding member (media) of that storageset, or a blank
media, must be loaded in the backup device.

-HP


--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Problems?:   [EMAIL PROTECTED]

Re: feature request

[Hunter Parrot]

At 9:27 AM -0500 8/18/00, Jeffry C. Nichols wrote:

>My feature request would be to have a "skip" client option along with
>the "pause" and "stop" options so that either you could manually skip
>a client, or even better, set a parameter to skip a client if the
>backup on that client has exceeded "X" minutes/hours.
>

I  second the motion.  Or maybe a minimum transfer rate threshold?

HP


--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Problems?:   [EMAIL PROTECTED]

Re: CPU speed vs. Network speed?

[Hunter Parrot]

At 6:27 PM -0700 8/16/00, Pat Lee wrote:
>>> What would give better performance, a G3 upgrade to the 6100 or a 100
>>> base T card. I can only do one since the 6100 only has one slot.
>>
>> Go with the G3 upgrade. The 6100 bus is too slow to benefit from a 100Mbps
>> Ethernet card, but the G3 card will at least allow it to maximize the
>> existing SCSI and network I/O.
>
>Actually, I would not rely on a G3 upgraded original Power Mac (6100, 7100,
>8100) computer as a backup server. The reason for this is that I believe
>that stability is the most important factor in a backup server. Bottom line,
>it just need to work reliably.
>

Well, I've got 3 7100/80s running Retrospect 4.2, and I never have a
problem with them.  They don't even have G3 upgrades, and I get up to
45Mb/min from them onto HP DDS-3 drives.  I  believe I would go with the
6100 with the G3  upgrade.  The G3 will also be quite handy during day to
day backup administration, or during a restore operation when Retrospect is
searching a catalog file or two...  With just a straight 601/66, something
like that could take _forever_

-HP


--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Problems?:   [EMAIL PROTECTED]

Re: Alternate Back Up Destination

[Hunter Parrot]

At 9:17 AM -0400 8/16/00, Sara M wrote:
>I am very new to the Retrospect backup program, but looking for an alternate
>back up destination.  Currently we are running a G4/400, OS 9.0.4, ASIP
>6.3.1, Retrospect 4.2.  We have approximately 250 GB of hard drive storage
>space that needs to be backed up on a regular basis.  My goal is to do a
>complete backup monthly, with normal backups nightly.  Currently we have
>only one DAT drive.  As you can imagine, to do a full backup is very time
>consuming.  What I am wondering:  Can Retrospect back up to another server
>on the network such as a Quantum Snap Server?  Will the data be compressed?
>I looked into the internet storage, but is too costly on a monthly basis.
>Is my only option an auto loading tape drive?  Please excuse my ignorance.
>I find Retrospect a great program, and do not seem to be having problems
>with the program, I just need to figure out a timely manner to do a complete
>back up of our data.  Thanks in advance
>*
>Sara McGill
>[EMAIL PROTECTED]
>

I would lean toward big local storage, like a DLT library.  Backing up to a
network volume is going to be slow, unless you have gigabit ethernet, and
I'm not sure how Retro. will do that anyway.  You might be able to start
ftp service on the snap server and then have Retro backup to it using the
Internet storage type in the New Storageset window.

-HP


--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Problems?:   [EMAIL PROTECTED]

Re: OS9/TCP/Sonnet problem...

[Hunter Parrot]

At 8:11 AM +0100 8/16/00, Ken Gillett wrote:

>Whatever the reason for these communication failure problems it
>worries me that (in my case) the LAN works perfectly for everything
>else, yet Retrospect falls down every time. I realise that it hits
>the network pretty hard, but this is no surprise and shouldn't it
>have been designed to cope with that in the first place?
>
>I'm pretty fed up with its inability to perform network backups over
>an otherwise perfectly functioning network. Maybe it's not happy with
>my 10baset hub
>
>Exactly what is the 519 error? How can it lose contact with a client?
>They're still physically connected and unless the network has crashed
>surely there's no reason why communication couldn't be re-established
>for the backup to continue.

error -519 is, in my experience, caused by a number of things.  Sometimes a
screensaver will slow the client down enough to make the server drop the
connection, or maybe the user decides his machine is acting too slowly (not
knowing it's being backed up and that most people don't work at 1:30 AM)
and restarts the client.  Old versions of Eudora used to cause 519s because
their "You have mail" dialog halted processing on the client.  In nutshell,
519 is caused by any incident that causes the data stream between the
client and the server to be broken.

I'm curious as to the nature of Retrospect's relationship with Network
hardware, like switches and routers.  We have several Cisco switches on our
network (over 200 Macs and about 50 Wintel) and Cisco has told us in the
past to do things like "disable the spanning tree protocol on the port that
feeds the offending Mac".  We'd end up reenabling it and solving the
problem on the mac itself with software.  My point is that _if_ Retrospect
is sensitive to these things, then there are dozens of little factors, on
our network anyway, that could contribute to a problem, even though it
appears to be working fine in all other respects.  Retrospect is just using
a protocol, be it TCP or Appletalk, to do it's job, right?  Maybe it's a
question of how Retro. _uses_ that protocol.  Anyone from Dantz want to
jump in here?

and At 10:51 PM +1200 8/16/00, John Gee wrote:

>It would be nice if Retrospect behaved more like 56k modems, and
>automatically downgraded performance until a reliable connection was
>possible. Retrospect could go slower/safer but write a warning to the
>log like:
>"Recovering from 519 error, establishing lower performance connection"

Good idea, but I think Retro. already behaves like that.  I've sat in front
of a server, backing up a sick PC, and watched the transfer rate drop from
36Mb to 2 Mb/min.  It never actually dropped the connection, it just took 3
hours to back the thing up!  In my experience 519 is generated when the
valve is out-and-out shut off.
I think the log entry idea is a great one.  Maybe a separate entry
for the xfer speed at the start and again at the finish of a client's
backup?

-HP


--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Problems?:   [EMAIL PROTECTED]

Re: OS9/TCP/Sonnet problem...

[Hunter Parrot]

At 10:14 AM -0800 8/15/00, Matt Barkdull wrote:

>Just as another step to test, did you try going to the TCP/IP control
>panel and unchecking the "Load only when needed" button"?   I'm
>wondering if the timing factor is doing something weird to the
>interface and shutting it down.
>

Actually, that was one of the 1st things Dantz recommended, but it didn't
help.


and at 2:33 PM -0400 8/15/00, Philip Chonacky wrote:

>Retrospect pushes the limits in tcp/ip mode in order to achieve the best
>backup speed.
>
>I would reeccomend backing up using Appletalk since that sems to produce
>the most reliable backup, albeit slower.
>
>my $.02

I would like to stick with TCP instead of Appletalk, since Appletalk is
being phased out and it's slower.  And with a mix of platforms on our
network, it's nice to have them all talking the same language.

-HP



--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Problems?:   [EMAIL PROTECTED]

Re: OS9/TCP/Sonnet problem...

[Hunter Parrot]

At 6:36 PM +0200 8/15/00, jakob krabbe wrote:
>Hi and thanx for your post! That was a good one to be the first one! Maybe
>that explains some of our problems related to some clients. They also just
>stops for no clear reason, running Sonnet and 8.6. You are talking about
>the processorupgrade, right!?

The sonnet crescendo G3 processor upgrade, version 1.4.2 to 1.4.4, yup.
I'm not having the problem with OS8.6 machines, I actually only have 1 6100
with 8.6 installed  and it does have the same problem, but since there's
only one of them I didn't include that fact in my original post.
But let me add another thing now.  I just backed up a 6100 with the
crescendo and OS9.  I've got it's disk divided into three partitions with
OS9, 8.6 and 8.5 respectively for testing this very problem.  The remote
generated error -519 while backing up the first partition, but then it went
on and successfully backed up the other two partitions!  Does "Network
Communication" happen on a volume-by-volume basis, or machine-to-machine?
It seems like if network communication fails, the whole machine would then
be down for the count.  In fact, I know this to be true  because other macs
with more than one volume will generate a -519 error and any volumes on
that mac not yet backed up will _not_ get backed up.
Could this have anything to do with DHCP?  All our macs get their
IP numbers from a DHCP server, but the leases are currently set to never
expire (don't ask why)

-HP


--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Problems?:   [EMAIL PROTECTED]

OS9/TCP/Sonnet problem...

[Hunter Parrot]

Hi.  1st post on this list, I'll try to keep it as condensed as possible,
but this problem

I've got a large number of Mac 6100s with Sonnet Crescendo G3 cards
installed, running OS9  I'm using Retrospect 4.2 over TCP/IP.  The problem
is that these macs will often return an error -519 (network communication
failed) at different points in the backup; sometimes while the remote is
being scanned, sometimes 10% of the way through, or 70%, or during the
verification.  These errors happen immediately, meaning the server doesn't
display the "Net Retry" window and try to reconnect.  It, or the remote,
just drops the connection like a hot potato.  After that happens, I can
Immediate -> Backup the remote right away and either finish the backup or
see the whole thing happen again, depending on my luck.
If I remove the Crescendo card from the remote or disable the
driver for it, the problem goes away.  If I keep the hardware as it is and
switch to backing up over Appletalk, the problem goes away.  A 6100 without
a Crescendo will have a spotless backup record until I install a Crescendo
in it, but the TCP/Appletalk factor indicates that the problem is a little
deeper than just hardware.  6100s with Crescendos and OS 8.x backup fine
too.  Finally, Macs other than 6100s and 7100s, but with OS9 and a
crescendo G3 have no problem.

SO. what's up with Retrospect, TCP, Sonnet Crescendos and 61/7100 macs?
Is anyone else experiencing problems like this, or NOT having these
problems with this same hardware?

TIA

-Hunter

Hunter Parrot,  I.S. Administrator
New England Biolabs Inc.  32 Tozer Rd.  Beverly, MA. 01915
978-927-5054 ext 329  Fax: 978-921-1350
800-632-5227
http://www.neb.com




--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:<http://list.working-dogs.com/lists/retro-talk/>
Problems?:   [EMAIL PROTECTED]