Did you change from a Windows master to a Unix master? Maybe Unix based catalogs are inherently larger? Can anyone comment on this?
If your master has always been, and still is, on Windows, then did the upgrade to v6.5.x remove any "compress after N days" set in your master server attributes? Maybe your catalog is no longer being compressed after N days. i.e. maybe there's a bug in the upgrade that doesn't honour/maintain the "compress after N days" setting?
Did you recently implement multi-plexing where there was no multi-plexing at all before? If so, your catalog will have many many more fragments to keep track off, and will be quite a bit larger.
If you did already have some multi-plexing, have you recently increased the multi-plexing? If so, you might not necessarily have many many more fragments to keep track of, BUT there will very likely be "some" more fragments to keep track of, and thus a larger catalog to some degree.
Did your upgrade over-write any special retention levels? I.e. default NetBackup has retention values pre-set for levels 1 to 9, and 10 to 24 are, by default, infinite. BUT, I'm wondering if you had some special retention levels set in the 10 to 24 range, that have since been overwritten by the upgrade and are now inifinite - and thus schedules still using those retention levels 10 to 24 are no longer creating backups that will expire?
Also, wondering if you have checked the retention levels on all schedules in all policies to confirm that they are as you expect them to be.
Finally, you may be affected by this:
BUG REPORT: Using catalog compression will result in backup images not being properly removed from the netbackup/db/images directory.
...see tech note here:
http://seer.entsupport.symantec.com/docs/283306.htm
...which itself was found in the 30 day digest for NetBackup Enterprise Server, here:
http://seer.support.veritas.com/docs/NBUESVR_digest.htm
