Backups are always slow when backing up such a large area populated with small files, which is why products like SnapImage were created, these perform block level backups, removing the issue of the many small files...

This is not just a Networker issue, its a backup issue.

this may only be one of your issues, you may be want ensure that the DiskDevice Luns are spread across the disks, and not overlapping, having 2 more Diskdevices writing to the same spindles will cause slows. Also regardless of what people say about using SATA for backup, it is still a factor in slow performance.

Teaming of NICS is done at a system level, maybe that thread you referred too was being specific regarding the Broadcomm Cards. We have numerous sites where the NIC's are teamed on the NSR servers and Storage Nodes without any issues.

using auto neg for nics and switches isnt a problem, some companies have their Network all set physical the actual speeds, whereas some vendors may specifically request that auto neg be used, i..e EMC clariions etc which your using.

you should begin by looking at the backup options for the file share, block level backups, i.e. snapimage for windows
NAS (ndmp backup using VBB, altho VBB may only be celerra, havent confirmed)

a few people may respond differently, but at least i hope the above helps.

Thanks for the reply.

Are the restores from tapes really slow with SnapImage ?
We run staging every two weeks.

Has anyone used " Windows Change Journal" (esg 55373) to improve inc. backup speed ? Are there any downsides of using it with Networker ?

Also the key issue is that one of the three servers has more than 60 % of the total file share (larage # files compared to the other two servers)

Is that 1 large backup or many smaller ones combined.
If you break down a large group into smaller ones it will run much faster because networker will run multiple sessions at the same time.
You can always set up directives so that you are not duplicating any files.

No one said that. SI will make backups faster as it is done at block level. Moving that data to some sort of filer and using block level approach like VBB will get you with better results.


Those backups will be faster as NW won't have to walk down the directory tree, but
if I remember correctly that does not work with VSS and since VSS is the MS way to go you can most probably forget about it.

I read in one of the previous threads that, " Most filesystems that are in use for longer periods of time end up with some level of fragmentation and this is what causes block level backup agents performing file level recovery (from tapes) to have problems"

Do incrementals work with SnapImage ?

Is SI more expensive than PowerSnap ?

PowerSnap and SnapImage cannot be compared here as they are used for different purposes.

SI backups can be incremental in terms that incremental block changes are captured. To quote docs:
---
With SnapImage, data is backed up live with no user lockout. During full
backups, only populated blocks are copied to tape, not the entire image.
During incremental backups, only changed blocks are backed up, not the entire
file. By further enabling backup operations to be completed in less time,
enterprises have greater flexibility in fulfilling data protection requirements
and service level demands.

Block-level backups with file level restores.
NetWorker Module for SnapImage performs faster backups without sacrificing
the ability to restore data at the file level. During the backup, SnapImage
enables NetWorker to track the blocks associated with individual files in a file
system. While restoring single files or directories, SnapImage restores these
blocks in a single scan of the tape enabling enterprises to meet recovery time
objectives.
---

Thanks for the clarification.

Shall I exclude "nsr" directory from Anti-virus scanning ? (esg 59819 ) Is it only for the NW server ?
We use SOPHOS & run "On-Access" scanning all the time on to the servers.

Has anyone seen a noticeable change in throughput after applying this fix ?

You should exclude save process from being checked by AV.

Sorry but I am not sure I understood your point.

Is it Savservice.exe ?

It looks like the incremental backups (Monday to Thursday) became really slow after upgrading NW from 7.3.3 to 7.5.1.4.

See the reports below for the largest filesystem saveset. I upgraded Networker on 9/29/09

Saveset Date Duration Size # of Files
(Min) (MB) (10^3)
J:\ 8/4/09 475 6520 144
J:\ 8/5/09 446 5224 100
J:\ 8/6/09 447 5332 97
J:\ 8/10/09 450 5171 103
J:\ 8/11/09 465 4898 97
J:\ 8/12/09 470 5301 100
J:\ 8/13/09 475 4874 94
J:\ 8/17/09 Failed Failed Failed
J:\ 8/18/09 510 6483 134
J:\ 8/19/09 481 5247 92
J:\ 8/20/09 478 5317 101
J:\ 8/24/09 501 5373 103
J:\ 8/25/09 506 7083 98
J:\ 8/26/09 506 5941 99
J:\ 8/27/09 511 4769 96
J:\ 8/31/09 592 13928 107


J:\ 9/2/09 656 6489 148
J:\ 9/3/09 539 4998 101
J:\ 9/4/09 589 5012 118
J:\ 9/7/09 499 3012 21
J:\ 9/8/09 607 5185 104
J:\ 9/9/09 674 5757 109
J:\ 9/10/09 586 6049 104
J:\ 9/14/09 684 5793 115
J:\ 9/15/09 646 5564 104
J:\ 9/16/09 623 5219 98
J:\ 9/17/09 615 5451 104
J:\ 9/21/09 669 6093 114
J:\ 9/22/09 673 6171 119
J:\ 9/23/09 675 6155 113
J:\ 9/24/09 677 10919 125
J:\ 9/28/09 675 5662 116
J:\ 9/29/09 767 5481 109
J:\ 9/30/09 743 5331 107

J:\ 10/1/09 744 5208 108
J:\ 10/5/09 781 6217 113
J:\ 10/6/09 107 694 16
J:\ 10/7/09 -- -- --
J:\ 10/8/09 816 8053 152
J:\ 10/12/09 721 1676 32
J:\ 10/13/09 888 5497 105
J:\ 10/14/09 867 5386 106
J:\ 10/15/09 884 5152 106
J:\ 10/19/09 939 5657 116
J:\ 10/20/09 943 5884 111
J:\ 10/21/09 933 6362 144
J:\ 10/22/09 971 4917 107
J:\ 10/26/09 970 5709 123
J:\ 10/27/09 999 5366 110

No, it is save.exe