sam -

How many users are you backing up?  Are you using the compare and/or verify feature with each backup?  Are you running a full backup each night?  Have you tried to update the backup drives' drivers?

These set parameters are for GroupWise servers but we have seen some great results on other applications as well. We have used these on Novell 4.x and 5.0 servers. Our ARCServe backup times (with a full compare) were cut dramatically on several servers where we put these in place.

Startup.NCF
SET Directory Cache Allocation Wait Time = 0.5
SET Directory Cache Buffer NonReferenced Delay = 30
SET Dirty Disk Cache Delay Time = 0.5
SET Maximum Concurrent Directory Cache Writes = 100
SET Maximum Concurrent Disk Cache Writes = 500
SET Maximum Directory Cache Buffers = 4800
SET Maximum File Locks = 20000
SET Maximum Packet Receive Buffers = 4500
SET Maximum Record Locks = 100000
SET Minimum Directory Cache Buffers = 4500
SET Read Ahead LRU Sitting Time Threshold = 60

Autoexec.NCF
set Maximum Outstanding NCP Searches=150
SET Maximum Service Processes = 1000
SET Minimum Service Processes = 110
SET New Service Process Wait Time = 0.3

In response to the question on the number of users and such: We have a network of about 250 users. And yes, we do a full backup nightly.

The problem with the parameters change on the server is that it worked for a while. We upgraded Arcserve and after latest patch was applied we were back to the 10 hour idle problem. We do verify, but the verification is suppossed to take place after all backups are done. It does SERVER pretty fast - It's Groupwise the one that obviously stalls because of the large amount of files. And yes: I know what you are thinking, and we checked the directories for excessive file fragmentation.

This seem to be a throughput problem. What worked before didn't seem to work now. However, I read a support document in which the changes you recommend are mentioned. But it warns you it can cause serious memory shortage while running. I will have to test it on a weekend to see if it will not crash me while live. We have had crashes on this Groupwise server before - the usually occur early in the morning when all users start logging in to their e-mail.

Is GroupWise running on a separate server or on your main file & print server? We have run the server parameters in a number of environments (3-8 LANs, 25-200+ users) without server problems.

Groupwise is a separate server. Arcserve backs it up from our main file and print server, which I called SERVER above (it's the name in our tree too). We thought in the beginning this would be a through[ut problem in the main server, but the crashes suggest it's the Groupwise server the one which needs tune up.

We saw great improvements playing with the parameters suggested above - Thanks. BUT the server is crashing every morning around 4:30 to 6:00 A.M. - now AFTER the backup gets done.

It's not crystal clear obvious to us why this is happening. The performance improvements do not seem directly related - if anything we see the crashes happening more often now.

Are you using any backup agents on the GroupWise Server?  ie: Arcserve Push agent or open file backup agent.  The open file agent is really the key, it improved our backup time by several hours.  I use both agents but if I could only have one it would be the open file agent.

Hope that helps.

We have the Push Agent. If by the open file agent you are referring to that Groupwise agent they have now - we don't haVE IT.

Anyway the backup issue has become a server issue now. A total length of about 4 hours like we have now is really an improvement for us. The problem now seems to deal with Groupwise server going down at some unspecified time at night. It hardly goes down during the day now - which I cannot explain - but usually after 12:00 a.m. or after 4:00 a.m. We are also trying to deal with an ARCSERVE.DB corruption message we get on the nightly Arcserve log.

We have ARcserveIT 6.6 backing up our GW55 server, and it was slow till we added the CA Backup Agent for GroupWise (open file agent). This type of agent must be used:

- to ensure even busy  files are backed up
- to impove backup performance
- to ensure server stability during backup

GW store many files, but the directory structure is such that messags, documents etc are stroed across 255 sub directories, ensuring access time by users or agents is not impaired.

I have seen this A LOT.... using switches (instead of Hubs).  If you are connecting the server to a switch, try setting the duplex on both the server and the hub to 'half duplex'.  I'll bet that speeds up the backup.