Backup take long time in Networker client for Netware

Well, we might need some more info about your environment, to find where is the bottleneck.
At least the tape devices you're using and how is the network (dedicated or not, speed).
Then we could suggest something.

[]'s

In this case, I would suggest using BIGASM to do some tests. Try to backup using bigasm and see how it goes. If it takes a long time too, you might try to verify your network for errors or misconfiguration.

If it works fine, than you have an I/O problem. The data you're trying to backup is in a Storage or in local disks? Do you see any difference backing up these two kind of data?

Unfortunatelly, performance problems are hard to solve, we only can try to find where the bottleneck is.

HP MLS6000 tape library with two Ultra tape drive 200GB/400GB
Networkr backup server connect to tape library through SAN

Network backup server to Netware File printing server through 1G Cisco switch same as communication lan

We schedule backup job at 8:30PM, some time it finished at second day morning around 8:30AM, some time it would take even longer to noon or to night.

During backup precess, I check the console of netware server, and I saw that "Writing, xxGB" under "Device" section lots of time, some time writing rate is only few hundred kb or even less. I check the log, for small server, it finished with minutes, but for those file printer server, it takes more than 7 hours, and we have three these kind servers.

Hi Jacky,

I have no clue about NetWare, but just wish to clear something here; you said incremental backup is slow - what about full backup - is that one slow too or it doesn't matter?

If it doesn't matter, then second thing is to check network performance. Try to initiate ftp from server to client and then from client to server (push and get). One thing to check is NIC and switch setting of course. I remember in past with NetWare clients there use to be some performance problems with duplex settings and with half-duplex things would work fine - do NOT take this as advice, but rather suggestion to test things out. If I understood correctly you are backing up to backup server and not remote storage node. In case that you are backing up to remote storage node than data path goes over the backup server for 4.22 and you will need NetWorker for NetWare 7.2 first to fix this if I remember correctly. Actually, there is number of reasons that may look appealing to switch to 7.2 clients so give it a thought.

To test network you could also try to use blaster - I remember Legato had blast.nlm for NetWare clients. Blaster used to be unsupported tool for network performance test burried on Legato ftp in unsupported area - not sure if it still lives there.

Full backup will take about 17 hours, some time take longer,
We schedule Satursday night to do full backup, some time in sunday night, regaully backup can not start because the full backup did not finished yet.

BIGASM is a feature that allows you to backup fake data without reading from the client disk. So you can avoid any I/O problem, and test you network.

To not just copy and past the "how to" here, take a look at the knowledbe base, Support Note 53018. All the procedures are there.

Also, the suggestions above to test the network are very good too.

I will try it, but I think I need to do this after hours.
Thank you very much!


Message was edited by: jzhang8

Bigasm is special internal directive. I will give you an example:

1. Create empty file called ble1, ble2, ... bleX (or whatever you want to call it). On Windows you could do that with "> ble1" (without quotes) and on UNIX using touch command eg. "touch ble1" (no quotes). No idea how to do it on NetWare.

2. Then create directive called something with following entries:
<< Your_path_here_where_created_files_are >>
+bigasm -S2000MB : *

3. Change your saveset to be:
- Your_path_here_where_created_files_are\ble1
- Your_path_here_where_created_files_are\ble2
etc...

4. Include directive for your client and run backup

Now, above is what will work for UNIX and NT (top of my head). Now, you will need to tweak this somehow to make it work for NetWare as I know this is different there and I have no clue of NetWare so I wish you a good luck. Example above will see each file I created as 2GB file.

I hope this helps... Perhaps someone else can give you more tips who had experience with bigasm on NetWare.

Please note that last time I used bigasm (on Solaris box running 7.1.2) I found there was some kind of memory leak which caused machine performance degradation during the test if size of file was set too high. So, start with small values first.

EDIT: Just take a look at support note 53018 as Daniel said. I assume you will have to create client side directive with NetWare...


Message was edited by: hcrvelin

Data saved in SAN storage.

What is BISASM? how can I do this?

Thank you!

You may also want to check the netware volume and insure comrpession is not turned on - I spent weeks trying to figure out what was slowing down some of my netware backups only to find that the server admin had accidently turned on volume compression.

Good luck.

Yes, There is auto sense in port setting,
but in netware server, there are only Auto/100Full/100Half/10Full/10Half
and there is no 1000Full or 1000Half setting

There are many reasons why the 4.22 client can go slowly. The first and best recommendation that I can give you is to started testing and moving over to the 7.2 client as it solves many of these issues. I will "briefly" describe some of these.

1. The 4.22 client uses an older protocol then the 7.x clients. With this old protocol, much more of the backup logic runs on the central backup server, rather then the client netware server. This means there is a lot more chatting going back and forth on what needs to be done, rather then moving the data itself.

2. I have packet traces that show that there are different tcp/ip delays when a backup is going on depending on what host o/s you are running the central server on. In my cast I was comparing solaris to suse linux. The solaris box has huge delays between ack it got a patch, and sending out the next request. This combined with issue #1 make backing up netware from solaris painful at best. It was actually faster to backup to my linux box that only has a 1.1MB/s tape drive in it rather then going to that solaris box that had 20MB/s (now it has 30MB/s) drive installed.

Quick Test: If you do a manually upgrade from networkr.nlm running on the client, the communications is much much different as it is in control of the backup. In my case this showed a huge different in speed. Unfortunatly, I was never able to get anyone to address is issue with 4.22.

Other posters have mentioned things like duplex settings and such. While that can be a problem, you can disprove that pretty quick if you running tsatest.nlm to show some benchmarks.

So, I would go to 7.2. Put on the patches that they tell you to in the instuctions. And if you go to nw65sp4 (or 4a), you'll need to backrev the tcp/ip stack to the version in the doc otherwise you start getting rpc errors.

Expectations, Now keep in mind that an incremental backup may have to look thru a lot of files to first find the files that need to be backed up, so speed on that is always going to be slower then a full backup. (Well it really doesn't have to be with the "Modified File List" feature that novell has, but I don't know of any backup vendor that is using that).

I upgrade one server to 7.2 client, and there is no big different.
I need to try things one by one, and see what cause problem.

It is a known issue that Netware backups struggle to get a good performance; you could try splitting your data into several savesets and see if that gives you an improved performance.

There are two documented issues in the Release Supplement which I suggest you check - one relates to using HyperThreading technology with earlier versions of Netware than 6.5 SP4; recommendation is to disable HyperThreading; the other one relates to using tsafs.nlm with limited licenses - tsafs.nlm uses an authenticated connection for each thread so you need to ensure you have enough licenses available else use tsa600.nlm.

Other things I have seen that affect performance - use of OFM can cause significant performance issues if there are a lot of files open. Check there are no disk issues such as fragmentation.

As recommended you should check using ftp, bigasm etc what sort of rates you are able to achieve across your network so you can verify there is no external issue.

Networker for Netware 7.2 is meant to fix several long term issues for backing up Netware so it may be sensible to think about upgrading in the near future.

another thing I found, in server console, under Messages:
...
Tue 6:18:54 AM Sadmin:Vol1: Done saving to pool 'DAILY' (M4L39L2)5123MB
Tue 6:18:58 AM Sadmin:Vol1: saving to pool 'DAILY' (M4L39L2)

Looks like vol1 has been prcocess second backup ?!!

Any idea what about this?