Backup Central

As of a few weeks ago we saw our NBU7 catalog explode from 80GB to a peak of 238GB. My initial belief was this was part of us standing up a 2nd media server for the office which was linked to a Data Domain 630. But after reviewing the historical graphs, it is very clear this increase happened just a couple weeks ago. The obvious thing I started doing 2 weeks ago, is backing up our new Isilon cluster and also introduced these backups to a new Data Domain 670. More specifically, our Isilon which contains around 600 million image files that are less than 128k each.

How in the world could 10TB of image data suddenly cause the catalog to triple in size? Yet previously adding 18TB of data from a new media server (the dd630) didn’t even cause more than a 20GB increase in the catalog ?

I’m at quite a loss here to understand how this increase happened so quickly. The real issue here is that the catalog filesystem has filled up 3 times, causing nbpem to crash, and backups to grind to a halt. The last time this happened had nothing to do with the Isilon backups, but happened as a result of changing the media destination from some existing OS backups to go to a Data Domain 670, instead of their old DSSU locations. The isilon also points to this same DD670. Could that be the real issue here? Is there something different about how the catalog stores information when it resides on a Data Domain?

--
Nate Sanders Sr. System Administrator
Digital Motorworks, Inc (512) 692 - 1038


This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

There is an entry per file in the catalog, a million files at 1k each will cause more catalog space than a thousand 1tb files

Doug Preston

From: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Sanders, Nate
Sent: Monday, November 14, 2011 8:29 AM
To: VERITAS-BU < at > mailman.eng.auburn.edu
Subject: [Veritas-bu] massive catalog growth



As of a few weeks ago we saw our NBU7 catalog explode from 80GB to a peak of 238GB. My initial belief was this was part of us standing up a 2nd media server for the office which was linked to a Data Domain 630. But after reviewing the historical graphs, it is very clear this increase happened just a couple weeks ago. The obvious thing I started doing 2 weeks ago, is backing up our new Isilon cluster and also introduced these backups to a new Data Domain 670. More specifically, our Isilon which contains around 600 million image files that are less than 128k each.

How in the world could 10TB of image data suddenly cause the catalog to triple in size? Yet previously adding 18TB of data from a new media server (the dd630) didn’t even cause more than a 20GB increase in the catalog ?

I’m at quite a loss here to understand how this increase happened so quickly. The real issue here is that the catalog filesystem has filled up 3 times, causing nbpem to crash, and backups to grind to a halt. The last time this happened had nothing to do with the Isilon backups, but happened as a result of changing the media destination from some existing OS backups to go to a Data Domain 670, instead of their old DSSU locations. The isilon also points to this same DD670. Could that be the real issue here? Is there something different about how the catalog stores information when it resides on a Data Domain?

and any attachments from your system.

That makes sense for the 600mil image files, and was sort of my guess, but what about the existing policy that I simply changed the location of the image from DSSU to a Data Domain? Would just that change still warrant a 40GB growth in the catalog over a 24 hour period? We were only backing up < 100 unix hosts, I would guess.

From: Preston, Douglas [mailto:dlpreston < at > lereta.com]
Sent: Monday, November 14, 2011 10:38 AM
To: Sanders, Nate (DS); 'VERITAS-BU < at > mailman.eng.auburn.edu'
Subject: RE: massive catalog growth



There is an entry per file in the catalog, a million files at 1k each will cause more catalog space than a thousand 1tb files

Doug Preston

From: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Sanders, Nate
Sent: Monday, November 14, 2011 8:29 AM
To: VERITAS-BU < at > mailman.eng.auburn.edu
Subject: [Veritas-bu] massive catalog growth



As of a few weeks ago we saw our NBU7 catalog explode from 80GB to a peak of 238GB. My initial belief was this was part of us standing up a 2nd media server for the office which was linked to a Data Domain 630. But after reviewing the historical graphs, it is very clear this increase happened just a couple weeks ago. The obvious thing I started doing 2 weeks ago, is backing up our new Isilon cluster and also introduced these backups to a new Data Domain 670. More specifically, our Isilon which contains around 600 million image files that are less than 128k each.

How in the world could 10TB of image data suddenly cause the catalog to triple in size? Yet previously adding 18TB of data from a new media server (the dd630) didn’t even cause more than a 20GB increase in the catalog ?

I’m at quite a loss here to understand how this increase happened so quickly. The real issue here is that the catalog filesystem has filled up 3 times, causing nbpem to crash, and backups to grind to a halt. The last time this happened had nothing to do with the Isilon backups, but happened as a result of changing the media destination from some existing OS backups to go to a Data Domain 670, instead of their old DSSU locations. The isilon also points to this same DD670. Could that be the real issue here? Is there something different about how the catalog stores information when it resides on a Data Domain?

and any attachments from your system.


This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

The DD does not involve with NBU database.
Find the larger files in the image database and check what has change at the specific clients. (You may find that new files ware added)


From: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Sanders, Nate
Sent: Monday, November 14, 2011 6:50 PM
To: Preston, Douglas; 'VERITAS-BU < at > mailman.eng.auburn.edu'
Subject: Re: [Veritas-bu] massive catalog growth



That makes sense for the 600mil image files, and was sort of my guess, but what about the existing policy that I simply changed the location of the image from DSSU to a Data Domain? Would just that change still warrant a 40GB growth in the catalog over a 24 hour period? We were only backing up < 100 unix hosts, I would guess.

From: Preston, Douglas [mailto:dlpreston < at > lereta.com]
Sent: Monday, November 14, 2011 10:38 AM
To: Sanders, Nate (DS); 'VERITAS-BU < at > mailman.eng.auburn.edu'
Subject: RE: massive catalog growth



There is an entry per file in the catalog, a million files at 1k each will cause more catalog space than a thousand 1tb files

Doug Preston

From: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Sanders, Nate
Sent: Monday, November 14, 2011 8:29 AM
To: VERITAS-BU < at > mailman.eng.auburn.edu
Subject: [Veritas-bu] massive catalog growth



As of a few weeks ago we saw our NBU7 catalog explode from 80GB to a peak of 238GB. My initial belief was this was part of us standing up a 2nd media server for the office which was linked to a Data Domain 630. But after reviewing the historical graphs, it is very clear this increase happened just a couple weeks ago. The obvious thing I started doing 2 weeks ago, is backing up our new Isilon cluster and also introduced these backups to a new Data Domain 670. More specifically, our Isilon which contains around 600 million image files that are less than 128k each.

How in the world could 10TB of image data suddenly cause the catalog to triple in size? Yet previously adding 18TB of data from a new media server (the dd630) didn’t even cause more than a 20GB increase in the catalog ?

I’m at quite a loss here to understand how this increase happened so quickly. The real issue here is that the catalog filesystem has filled up 3 times, causing nbpem to crash, and backups to grind to a halt. The last time this happened had nothing to do with the Isilon backups, but happened as a result of changing the media destination from some existing OS backups to go to a Data Domain 670, instead of their old DSSU locations. The isilon also points to this same DD670. Could that be the real issue here? Is there something different about how the catalog stores information when it resides on a Data Domain?

and any attachments from your system.


This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

I believe using NDMP or Flashbackups the image file will be much larger than a normal backup. We saw this when some of our backups were using the flashbackup option, so we had to change them to a DataDump instead of a flashbackup so the catalog would stop growing so large

Thank you all for your suggestions. I think I may have a better explanation now.

<![if !supportLists]>1) <![endif]>600 million new files from the Isilon’s
<![if !supportLists]>2) <![endif]>Turning on TIR for an existing policy that had moved to new storage for the images
<![if !supportLists]>3) <![endif]>Improper exclusions on the backup master

After looking at folder sizes in /usr/openv/netbackup/db/images, I realized my backup server was damn near the same size as the two Isilon nodes. This seems way too large for me. After digging through some config’s I realized my existing ‘exclude’ file for the backup host was named to an old policy. In other words, I think the OS backup of the master server was including the catalog database its self. As it grew, so did the size of the master servers backup, as it was now including itself. The inclusion of the massive Isilon’s into this catalog, then backing that catalog up, resulting in an even larger catalog, became a huge snowball effect.

We do hot catalogs so there’s no need to also be backing up the catalog filesystem. I think this was the ultimate cause I was looking for.

Thanks again everyone.


From: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Sanders, Nate (DS)
Sent: Monday, November 14, 2011 10:50 AM
To: Preston, Douglas; 'VERITAS-BU < at > mailman.eng.auburn.edu'
Subject: Re: [Veritas-bu] massive catalog growth



That makes sense for the 600mil image files, and was sort of my guess, but what about the existing policy that I simply changed the location of the image from DSSU to a Data Domain? Would just that change still warrant a 40GB growth in the catalog over a 24 hour period? We were only backing up < 100 unix hosts, I would guess.

From: Preston, Douglas [mailto:dlpreston < at > lereta.com]
Sent: Monday, November 14, 2011 10:38 AM
To: Sanders, Nate (DS); 'VERITAS-BU < at > mailman.eng.auburn.edu'
Subject: RE: massive catalog growth



There is an entry per file in the catalog, a million files at 1k each will cause more catalog space than a thousand 1tb files

Doug Preston

From: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Sanders, Nate
Sent: Monday, November 14, 2011 8:29 AM
To: VERITAS-BU < at > mailman.eng.auburn.edu
Subject: [Veritas-bu] massive catalog growth



As of a few weeks ago we saw our NBU7 catalog explode from 80GB to a peak of 238GB. My initial belief was this was part of us standing up a 2nd media server for the office which was linked to a Data Domain 630. But after reviewing the historical graphs, it is very clear this increase happened just a couple weeks ago. The obvious thing I started doing 2 weeks ago, is backing up our new Isilon cluster and also introduced these backups to a new Data Domain 670. More specifically, our Isilon which contains around 600 million image files that are less than 128k each.

How in the world could 10TB of image data suddenly cause the catalog to triple in size? Yet previously adding 18TB of data from a new media server (the dd630) didn’t even cause more than a 20GB increase in the catalog ?

I’m at quite a loss here to understand how this increase happened so quickly. The real issue here is that the catalog filesystem has filled up 3 times, causing nbpem to crash, and backups to grind to a halt. The last time this happened had nothing to do with the Isilon backups, but happened as a result of changing the media destination from some existing OS backups to go to a Data Domain 670, instead of their old DSSU locations. The isilon also points to this same DD670. Could that be the real issue here? Is there something different about how the catalog stores information when it resides on a Data Domain?

and any attachments from your system.


This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.


This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

Great, so it appears NetBackup is actually not respecting my exlcude_list. I just ran a test job and realize it is backing up DSSU’s, the catalog and a whole bunch of other things that should be and are excluded.

From: Sanders, Nate (DS)
Sent: Monday, November 14, 2011 12:36 PM
To: Sanders, Nate (DS); Preston, Douglas; 'VERITAS-BU < at > mailman.eng.auburn.edu'
Subject: RE: massive catalog growth



Thank you all for your suggestions. I think I may have a better explanation now.

<![if !supportLists]>1) <![endif]>600 million new files from the Isilon’s
<![if !supportLists]>2) <![endif]>Turning on TIR for an existing policy that had moved to new storage for the images
<![if !supportLists]>3) <![endif]>Improper exclusions on the backup master

After looking at folder sizes in /usr/openv/netbackup/db/images, I realized my backup server was damn near the same size as the two Isilon nodes. This seems way too large for me. After digging through some config’s I realized my existing ‘exclude’ file for the backup host was named to an old policy. In other words, I think the OS backup of the master server was including the catalog database its self. As it grew, so did the size of the master servers backup, as it was now including itself. The inclusion of the massive Isilon’s into this catalog, then backing that catalog up, resulting in an even larger catalog, became a huge snowball effect.

We do hot catalogs so there’s no need to also be backing up the catalog filesystem. I think this was the ultimate cause I was looking for.

Thanks again everyone.


From: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Sanders, Nate (DS)
Sent: Monday, November 14, 2011 10:50 AM
To: Preston, Douglas; 'VERITAS-BU < at > mailman.eng.auburn.edu'
Subject: Re: [Veritas-bu] massive catalog growth



That makes sense for the 600mil image files, and was sort of my guess, but what about the existing policy that I simply changed the location of the image from DSSU to a Data Domain? Would just that change still warrant a 40GB growth in the catalog over a 24 hour period? We were only backing up < 100 unix hosts, I would guess.

From: Preston, Douglas [mailto:dlpreston < at > lereta.com]
Sent: Monday, November 14, 2011 10:38 AM
To: Sanders, Nate (DS); 'VERITAS-BU < at > mailman.eng.auburn.edu'
Subject: RE: massive catalog growth



There is an entry per file in the catalog, a million files at 1k each will cause more catalog space than a thousand 1tb files

Doug Preston

From: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Sanders, Nate
Sent: Monday, November 14, 2011 8:29 AM
To: VERITAS-BU < at > mailman.eng.auburn.edu
Subject: [Veritas-bu] massive catalog growth



As of a few weeks ago we saw our NBU7 catalog explode from 80GB to a peak of 238GB. My initial belief was this was part of us standing up a 2nd media server for the office which was linked to a Data Domain 630. But after reviewing the historical graphs, it is very clear this increase happened just a couple weeks ago. The obvious thing I started doing 2 weeks ago, is backing up our new Isilon cluster and also introduced these backups to a new Data Domain 670. More specifically, our Isilon which contains around 600 million image files that are less than 128k each.

How in the world could 10TB of image data suddenly cause the catalog to triple in size? Yet previously adding 18TB of data from a new media server (the dd630) didn’t even cause more than a 20GB increase in the catalog ?

I’m at quite a loss here to understand how this increase happened so quickly. The real issue here is that the catalog filesystem has filled up 3 times, causing nbpem to crash, and backups to grind to a halt. The last time this happened had nothing to do with the Isilon backups, but happened as a result of changing the media destination from some existing OS backups to go to a Data Domain 670, instead of their old DSSU locations. The isilon also points to this same DD670. Could that be the real issue here? Is there something different about how the catalog stores information when it resides on a Data Domain?

and any attachments from your system.


This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.


This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

Yeah that’s exactly what I have. I verified it is more than just the backup server, it appears to be all policies (or at least all of the ones I checked) that are not following exclude files. I opened a critical case with Symantec, who of course has not called me back. Big shock there.


From: Lightner, Jeff [mailto:JLightner < at > water.com]
Sent: Monday, November 14, 2011 2:04 PM
To: Sanders, Nate (DS); 'VERITAS-BU < at > mailman.eng.auburn.edu'
Subject: RE: massive catalog growth



The exclude list should be named “exclude_list.<POLICY>” for the specific policy name you’re using and is case sensitive (at least for UNIX/Linux it is).

e.g. Here we do an OS policy to get what are mainly OS components of a server and exclude application/database specific directories from that then create separate policies for specific applications/databases that have their own exclude lists. So for a server named billybob we might have policies: BILLYBOB-OS, BILLYBOB-DB and BILLYBOB-BINARIES. We’d then create an exclude list named exclude_list.BILLYBOB-OS.






From: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Sanders, Nate
Sent: Monday, November 14, 2011 2:05 PM
To: Sanders, Nate; 'VERITAS-BU < at > mailman.eng.auburn.edu'
Subject: Re: [Veritas-bu] massive catalog growth


Great, so it appears NetBackup is actually not respecting my exlcude_list. I just ran a test job and realize it is backing up DSSU’s, the catalog and a whole bunch of other things that should be and are excluded.

From: Sanders, Nate (DS)
Sent: Monday, November 14, 2011 12:36 PM
To: Sanders, Nate (DS); Preston, Douglas; 'VERITAS-BU < at > mailman.eng.auburn.edu'
Subject: RE: massive catalog growth



Thank you all for your suggestions. I think I may have a better explanation now.

<![if !supportLists]>1) <![endif]>600 million new files from the Isilon’s
<![if !supportLists]>2) <![endif]>Turning on TIR for an existing policy that had moved to new storage for the images
<![if !supportLists]>3) <![endif]>Improper exclusions on the backup master

After looking at folder sizes in /usr/openv/netbackup/db/images, I realized my backup server was damn near the same size as the two Isilon nodes. This seems way too large for me. After digging through some config’s I realized my existing ‘exclude’ file for the backup host was named to an old policy. In other words, I think the OS backup of the master server was including the catalog database its self. As it grew, so did the size of the master servers backup, as it was now including itself. The inclusion of the massive Isilon’s into this catalog, then backing that catalog up, resulting in an even larger catalog, became a huge snowball effect.

We do hot catalogs so there’s no need to also be backing up the catalog filesystem. I think this was the ultimate cause I was looking for.

Thanks again everyone.


From: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Sanders, Nate (DS)
Sent: Monday, November 14, 2011 10:50 AM
To: Preston, Douglas; 'VERITAS-BU < at > mailman.eng.auburn.edu'
Subject: Re: [Veritas-bu] massive catalog growth



That makes sense for the 600mil image files, and was sort of my guess, but what about the existing policy that I simply changed the location of the image from DSSU to a Data Domain? Would just that change still warrant a 40GB growth in the catalog over a 24 hour period? We were only backing up < 100 unix hosts, I would guess.

From: Preston, Douglas [mailto:dlpreston < at > lereta.com]
Sent: Monday, November 14, 2011 10:38 AM
To: Sanders, Nate (DS); 'VERITAS-BU < at > mailman.eng.auburn.edu'
Subject: RE: massive catalog growth



There is an entry per file in the catalog, a million files at 1k each will cause more catalog space than a thousand 1tb files

Doug Preston

From: veritas-bu-bounces < at > mailman.eng.auburn.edu [mailto:veritas-bu-bounces < at > mailman.eng.auburn.edu] On Behalf Of Sanders, Nate
Sent: Monday, November 14, 2011 8:29 AM
To: VERITAS-BU < at > mailman.eng.auburn.edu
Subject: [Veritas-bu] massive catalog growth



As of a few weeks ago we saw our NBU7 catalog explode from 80GB to a peak of 238GB. My initial belief was this was part of us standing up a 2nd media server for the office which was linked to a Data Domain 630. But after reviewing the historical graphs, it is very clear this increase happened just a couple weeks ago. The obvious thing I started doing 2 weeks ago, is backing up our new Isilon cluster and also introduced these backups to a new Data Domain 670. More specifically, our Isilon which contains around 600 million image files that are less than 128k each.

How in the world could 10TB of image data suddenly cause the catalog to triple in size? Yet previously adding 18TB of data from a new media server (the dd630) didn’t even cause more than a 20GB increase in the catalog ?

I’m at quite a loss here to understand how this increase happened so quickly. The real issue here is that the catalog filesystem has filled up 3 times, causing nbpem to crash, and backups to grind to a halt. The last time this happened had nothing to do with the Isilon backups, but happened as a result of changing the media destination from some existing OS backups to go to a Data Domain 670, instead of their old DSSU locations. The isilon also points to this same DD670. Could that be the real issue here? Is there something different about how the catalog stores information when it resides on a Data Domain?

and any attachments from your system.


This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.


This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.



Athena®, Created for the Cause™
Making a Difference in the Fight Against Breast Cancer

---------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------


This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

Great, so it appears NetBackup is actually not
respecting my exlcude_list. I just ran a test job
and realize it is backing up DSSU's, the catalog
and a whole bunch of other things that should be
and are excluded.

And we all assume it's not _really_ named "exlcude_list", right?

Not that I've seen every NetBackup problem by any means, but since
NetBackup 3.1, I have never seen {ex|in}clude_list processing not work
correctly.

Maybe this is that first time, maybe not. Suggest you look at your
bpbkar log; it (at verbosity 1, IIRC) will show all of the *clude_list
processing, file by file. When I don't understand why something is
included or excluded, that has always shown me my error.

Also, related to your catalog growth. There's a technote or two
explaining the per-file catalog entry. Often, each file is
generalized to take up 100-130 bytes (less with binary catalogs).
That number is a good working average, but can be way off if the
pathnames--almost always the longest part of each entry--are long.
Backups of Windows clients with a lot of filer shares mounted often
have paths over 400 bytes long, IME. The size of the files file of a
backup of that sort of path could be five-or-more times larger than
the same number of files with normal-length paths. FWIW, the one
Isilon box I ever dealt with had very long paths if backed up from the
root.

bpflist is a cantankerous command, but its 17 fields will clearly show
how much of the differences in your older backups and newer ones are
due to path lengths. Even simpler, divide the size of the .f file by
the number of files backed up by that stream to compute your own
metrics on bytes-per-file-entry.

If you're still having difficulty, it could be helpful to post
platform and NetBackup versions of the master and clients involved,
our exclude list and bpbkar log entries that illustrate the problem.


_______________________________________________
Veritas-bu maillist - Veritas-bu < at > mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

We are running nbu 7.0.1 and there is a know issue with the exclude list not working in cluster nodes. There is a hotfix available to fix this issue.
http://www.symantec.com/business/support/index?page=content&id=TECH150081