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:jlight...@water.com] Sent: Monday, November 14, 2011 2:04 PM To: Sanders, Nate (DS); 'VERITAS-BU@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-boun...@mailman.eng.auburn.edu [mailto:veritas-bu-boun...@mailman.eng.auburn.edu] On Behalf Of Sanders, Nate Sent: Monday, November 14, 2011 2:05 PM To: Sanders, Nate; 'VERITAS-BU@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@mailman.eng.auburn.edu' Subject: RE: massive catalog growth Thank you all for your suggestions. I think I may have a better explanation now. 1) 600 million new files from the Isilon’s 2) Turning on TIR for an existing policy that had moved to new storage for the images 3) 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-boun...@mailman.eng.auburn.edu [mailto:veritas-bu-boun...@mailman.eng.auburn.edu] On Behalf Of Sanders, Nate (DS) Sent: Monday, November 14, 2011 10:50 AM To: Preston, Douglas; 'VERITAS-BU@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:dlpres...@lereta.com] Sent: Monday, November 14, 2011 10:38 AM To: Sanders, Nate (DS); 'VERITAS-BU@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-boun...@mailman.eng.auburn.edu [mailto:veritas-bu-boun...@mailman.eng.auburn.edu] On Behalf Of Sanders, Nate Sent: Monday, November 14, 2011 8:29 AM To: VERITAS-BU@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.
_______________________________________________ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
