There are two things going on here.  One is the catalog post-
processing that NetBackup NDMP must do to convert the inode-based
information provided by the NetApp into the native path-based
catalog.  This overhead depends on the number of objects in
the backup.  Starting with NetBackup 4.5 there is no longer any
catalog post-processing so this overhead is eliminated.

Secondly, dump walks the filesystem before it starts sending
backup data.  A quick google search comes up with this
short overview of dump:
http://www.usenix.org/publications/library/proceedings/osdi99/full_papers/hutchi
nson/hutchinson_html/node6.html


Jeff Kennedy wrote:
>I believe the problem is *before* the dump even begins.  I have seen
>this problem on volumes that have a tremendous number of small files or
>are terribly fragmented.  But I've never seen the problem it just start
>out of the blue, it's usually a gradual process that gets worse with
>time.
>
>~JK
>
>John D Stephens wrote:
>> 
>> Moshe -
>> I have seen huge delays between volumes as well.  What is going
>> on is this.  After NBU starts the NDMP backup, it steps out
>> of the way and idle until the filer signals NBU that the dump
>> has completed.  Then the filer sends all the meta data to NBU
>> and NBU then catalogs that data.  Depending on the size of your
>> backup and the amount of files, it takes a little while for NBU
>> to chug through the catalogs.  Hopefully, 4.5 is faster at this.
>> Check your iostat -x and look for the activity on your catalogs
>> after the filer finishes sending the NDMP job, but NBU still
>> shows it to be active.  The only way around this is to use
>> multiple streams.  Be carefull, multiple streaming does use the
>> filer's CPU more than normal.
>> 
>> Hope this helps.
>> 
>> John
>> 
>> Moshe Linzer wrote:
>> >
>> > Lately we have started seeing delays between volumes when backing up our
>> > Netapp filer.  I have a single AIT-2 tape attached to my F760, and I run
>> > a full backup of the filer, which contains 3 volumes.  The performance
>> > on the first volume is as expected, but then there is a delay of
>> > sometimes up to 12 hours before the second volume begins to be backed
>> > up!  The same thing happens before the third volume.  volume sizes are
>> > between 375-480GB.  I think this began after we applied some patches
>> > lately, but the patch descriptions don't seem to have any bearing on
>> > this problem.  Had anyone seen this type of behaviour?
>> >
>> > Thanks,
>> >
>> > Moshe
>> >
>> > _______________________________________________
>> > Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
>> > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>> 
>> --
>>   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
>>  + John D Stephens    ITS Design Systems   +
>> + Texas Instruments  12500 TI BLVD, Dallas  +
>>  + jstephens AT ti DOT com     214-480-6229       +
>>   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
>> _______________________________________________
>> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
>> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
>-- 
>=====================
>Jeff Kennedy
>Unix Administrator
>AMCC
>jlkennedy AT amcc DOT com
>_______________________________________________
>Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu


__________________________________________________________________________
Steve Kappel                       steve.kappel AT veritas DOT com
VERITAS Software (Engineering)