Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

High data change rates, but why?

Created: 04 Feb 2013 • Updated: 16 Apr 2013 | 10 comments
This issue has been solved. See solution.

All,

 

I am experiencing very high data changes rates in a particular backup pool that has been stable for nearly a year. I would like to know if there is some way that I can view change rates for all my servers and see which ones are growing the fastest so I can try to find out why. I'm currently running Netbackup 6.5.3. Upgrading would not help/is not an option.

Comments 10 CommentsJump to latest comment

Mark_Solutions's picture

What exactly do you mean by data change rates?

If you have NOM you may be able to run reports with a larger history than NetBackup but otherwise it is just running reports and saving them out to a text file (which imports nicely into excel) and then sort by client, next date and see which ones are growing the fastest.

NOM would be best if you have it but again it depends on if you have the analytics license

Hope this helps

Authorised Symantec Consultant

Don't forget to "Mark as Solution" if someones advice has solved your issue - and please bring back the Thumbs Up!!.

eagle470's picture

So I my UNIX environment has doubled in size in the last month after not growing in the last year, and no one seems to know why.

 

Thats the issue, as faras NOM goes, no, I don't have it. And running daily reports is only useful going forward. Is there no way to view daily change rates and data growth going backwards without NOM?

Mark_Solutions's picture

You can run a Client Backups rreport in the admin console which should go back a reasonable length of time into the past  and will give kb sizes

You can save that out to see which client(s) are the culprits.

The Images on Tape report will also give you similar results and will let you go as far back as your retentionj periods that exist

Authorised Symantec Consultant

Don't forget to "Mark as Solution" if someones advice has solved your issue - and please bring back the Thumbs Up!!.

eagle470's picture

Well that won't work because I need to look at my weeklies (which we are only retaining a week) and that mean I have nothing farther back than last Tuesday.

 

I appreciate the effort but it appears I am up a creek right now.

Nicolai's picture

Then you are out of luck. Talk to the UNIX admin then - maybe they can explain the change

Assumption is the mother of all mess ups.

If this post answered your'e qustion -  Please mark as a soloution.

Nicolai's picture

Easy and maybe half half-hearted way: Using the activity monitor sort after incremental backup and size.

If data change rates changes the incremental backup will indicate this.

 

Assumption is the mother of all mess ups.

If this post answered your'e qustion -  Please mark as a soloution.

Mark_Solutions's picture

As Nicolai says .. if your retentions are only a week then without NOM /OpsCenter there is little you can do to find out where the change has come from, unless your incrementals and fulls are the same size in which case something like Anti Virus may have caused your issue.

Reports are kept for 28 days by default so a clients backup report or even an all log entries report may give you 28 days or information?

Authorised Symantec Consultant

Don't forget to "Mark as Solution" if someones advice has solved your issue - and please bring back the Thumbs Up!!.

Stumpr2's picture

run once a day

for i in `bpplclients -allunique -noheader | awk '{print $3}' | sort`; do bpimagelist -U -client $i  -hoursago 24 ;done

of course this is just a single command and you could do some scripting to make it fit your needs. But, this will give you the output you can save in a spreadsheet or whatever.

 

VERITAS ain't it the truth?

SOLUTION
Marianne's picture

Something else to consider: 

Check for multiple policies for client: 
bppllist -U -byclient <client-name>

Check for duplicate filesystem backup within policy:
If Backup Selection is ALL_LOCAL_DRIVES, check that 'Cross Mount Points' is NOT selected in policy attributes.
Check that 'Follow NFS' is not selected in policy attributes.
 

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

Stumpr2's picture

also check the exclusions as new databases sometimes come online. For example exclude all *.dbf for oracle databases. These are large files that will change everyday and are useless for restores unless the database is brought down for the backup.

 

I also came across this path that has several large new files every day:

/C/ProgramData/Symantec/Definitions/VirusDefs

maybe some similar antivirus definitions path may be changing daily.

VERITAS ain't it the truth?