Arcserve Slow Backups - Help Needed Urgently 1

[rpreston]

We are using AS 2000 on a Win2000 network. We backup a number of servers across the network, all in the same domain, with no issues apart from one.

This particular server takes almost 10 hours to backup 5.5Gb across the network. The average throughput is only 9.65Mb/Min on a 100Mb ethernet switch. Both servers are on the same switch.

All other servers backup at normal throughput rates.

I can perform large file copies between the backup server and the problem server with no throughput issues, so it isn't a fundamental network problem.

I've exhausted all of the possible problems that I can think of, and haven't yet found a solution.

Has anyone out there come across this before, or can you see a possible cause ?? I've got nothing left at the moment !!!

Thanks for any help.

Rob

 

[speshalyst]

Rob,

try a NT backup and check the thruput between these two servers..
This will give us a fair knowledge of whjat u can expect ARCserve to do

cheers
SPeshalyst

So it Shall be Written!
So it Shall be Done!!

 

[davidmichel]

If the Client Agent is used, try it without.
If the Client Agent is not used, try it with.
There is always Performance Monitor.
Does this target have more than one NIC?
If so the agent can be configured to use one or the other.
Was the exact same data used for the copy and the backup?
Does the server have more than one volume?
If so compare the throughput for each volume.
Perhaps one volume has lots of small files and the copy was done from the other volume.
Is the backup done with Compare verification?

 

[Cyklops]

Also check all network cards in the network to be configured the same way (the backup program likes half-duplex best but more important is that thay are all set the same) and check the virusscanner for this particular server. Does it run ? Inbound/outbound ?? Inbound only ??

regards

 

[Stat1c]

If it's a file server, when did u last run diskeeper on it?

 

[rpreston]

Cyklops,

Both servers have twin NICs, adapter teamed for fault tolerance. The connections at the NIC and switch port are all set to 100Mb/Full Duplex.

There is no AV software curently running on either of the servers.
--------

Stat1c,

Diskeeper ? That's a new utility on me. Where can I find it ?

--------
DavidMichel,

- The client agent is not used, but it isn't used on any of the other servers and they all backup at normal throughputs.
- Performance monitor shows that the source and target servers are both running at well below capacity during the backup, and the NIC stats are so low it's almost negligible.
- The server only suffers the throughput degradation on the C: drive. The other drives on there run at normal throughput.
--------

Other info....

- Drive C: is 33.9Gb in size, of which 23.4Gb is in use by 66,740 files. The partition is spread across 3x18Gb disks at hardware RAID5.

- If I do a straight copy of a large file from the problem server to the backup server, it runs at normal speeds.



Rob

 

[davidmichel]

A few thoughts.
1) the Client Agent thing was provided more as a test than a solution. Agent and do a local read and then send the data, server has to do a read over the network and then send it.

2) diskeeper is a defrag util, been around a long time. OS defrag comes from them.

3) Performance monitor can be used to monitor at a very detailed and low level. For instance if a specific drive is having a problem. One drive with a firmware glitch can hog a lot of bus time and greatly degrade performance. I saw it once with HP drives. Per Mon pointed out the drive, as it turned out that drive had older firmware, as it turned out that firmware was not certified for that version of Windows, as it turned out when that drive was replaced with one that matched the other drives the performance problem went away.

4) If all the files are the same size then they would be around 350k but they are not going to be. If there are a lot of small files they will cause a lot more over head that a few large files. Point is a copy of one large file is an apples to oranges comparison. A true comparison would be a copy and back of the exact same data. For instance setup an ARCserve Copy and Backup job of that same data and see how they compare to a Windows copy again of the exact same data.

 

[rpreston]

One more piece of information for you.

If I go into Job Status while the job is running, and bring up the monitor window, I can see each file being backed up and they all take far too long, right from the start.

I can watch files that are less than 1Kb in size take a number of seconds to be backed up.

I don't know if this is of any more use in pinpointing the problem.

Thanks.


Rob

 

[gabu]

Are you connecting to that server using an agent, or just going through the network? What antivirus software does that server use? Is it a member server or domain controller? What kind of a server is it? (Exchange, SQL, ...?) Some more information may help reveal where the problem is.

 

[gabu]

Sorry - I missed that this thread had seven responses already, I guess the thread above it had 0, so I didn't scroll down to see that my suggestions had already been made.

Since the problem resides on your C, I was wondering if that is the same partition your swap file is on? If so, maybe that would be why the C on this server is slower than the other servers? (Assuming that on the other servers they are not using the swap as heavily or that you are not backing up the partition containing the swap file on the other servers.)

 

[rpreston]

gabu,

the server is a member server, which forms one half of a failover cluster using MSCS. It's running SQL, but no AV software. Arcserve is backing up across the network, but the SQL and Open File agents are installed.

Drive C: has only one partition on three 18Gb drives at hardware RAID5. There is plenty of free space remaining. The swap file is currently 1536Mb, with the maximum set to 3072Mb.

It has one NIC running the cluster heartbeat, and a pair of NICs adapter teamed for the public link running at 100/full on a Cisco 100Mb switch. File copies across the network to the backup server run at normal speeds, so the network config doesn't appear to be the problem.

What confuses me is that I can watch the backup running using the monitor screen, and it runs slowly after just the first two or three files. It doesn't seem to matter what file is being backed up, how big it is, or where it resides. I can watch even small files taking an age to backup.

Thanks.

 

[rpreston]

All,

I've identified an application which generates a log file each time it encounters an error. It hasn't ben working properly and occasionally creates a large number of small files. These have been removed and the backup time has now halved.

Thanks for all of your help and patience with this issue.



Rob

 

[dspare]

We've found that a virus checker can get in the way too. You might want to turn off the virus checker on the backup server and optionally turn it off on the source server. Use the pre and post scripting options to make sure it is turned back on as the job finishes.

We had this problem on a filesystem that had millions of small files. When the backup job ran, the virus checker on the source computer was scanning the files as they were accessed because the archive bit was changing and the virus checker on the backup server was scanning each file as it arrived before being passed off to the tape drive. When we turned off both virus checkers the job throughput improved by a factor of 10 or more.

Hope this helps.