Please confirm this fix. I have been getting the updating catalogs problem for about 6 months now. I accidentally ran a manual backup after i was getting this "Updating Catalogs" issue. After canceling the job that was hung, the manual "Copy" job was run, and all my incremental backups worked fine after that. Prior to this manual backup, the only way i could get backups to work successfully was to reboot after the "Updating catalogs" error, then run a full backup, and then continue with differentials.

My process now is Full backup on monday, then 6 more differentials the rest of the week. In addition, I run a manual "Copy Only" job every 2 days which overwrites the previous job. Since I started running the scheduled Copy job, I have not had a job hang.

The copy job was created as a policy:
Copy Method: Full - Copy the files
Compression: Hardware if available, otherwise software
use GRT: checked
Perform consistency check: checked
  * I don't believe this affects a GRT backup so it doesn't matter
Continue with backup if consistency check fails: checked
  * I don't believe this affects a GRT backup so it doesn't matter
Advanced open file option: Unchecked

Please let me know if any of this works for other people.

That sounds like you are setting the copy job settings thinking that these apply to Exchange backups when in fact you are probably messing up the Full/Incremental process by accidentally doing another full midweek - as such I hope you are keeping the results of your "copy jobs"

For information any Exchange backups ignore the settings for "Backup Method" under the General settings but instead use the setting in the Microsoft Exchange tab where a copy job is actually called "Copy - Databases and Logs". In your description you state that you are selecting "Full - Copy the files" which will not be applied as it is not an Exchange backup setting. As such would suggest you review this fix - which is NOT a fix if you are then not retaining the backup set from your "copy job"

Back to your original problem.

Symantec are aware of an issue where the updating catalogs phase can take extended periods to run and are working to try an minimize the effect.
In the meantime the options are run your Exchange Full backups slightly more often (which you already know works from your accidental fix) or setup your Incremental template with GRT not enabled - but leave GRT enabled on the full template and then make sure that your Exchange deleted message retention (Microsoft setting not a Backup Exec setting) is longer than the interval between your full backups so that your restore options are
1) Use the full set with GRT
2) Use the Outlook mechanism, to restore deleted message for the incremental dates
3) Use an RSG process if the above 2 options can't be used
4) Just restore the full and incrementals without using Granular Recovery if you have a disaster that affects the whole server.

As I believe there might be some beta code available from Symantec that can minimize the problem it is possibly worth logging an official support case with Symantec Technical Support for more information.

Note where the TN in the original post discusses tape backups similar affects are seen with B2D backups - particularly where a lot of Exchange transactions occur between your full backups (so busy Exchange servers are more likely to see the issue)

I have reviewed my settings several times and even had 2 different symantec techs review the settings. Both times both techs told me the ONLY fix was to run a full backup more regularly because my backups were too large. Indicating that I should not be running one weekly and 6 daily backups, but run 2 or 3 fulls with daily backups inbetween to get around the "updating catalog" problem.

Are you saying that because i'm doing a full (with archive bit reset & Full- Database & logs flushing committed logs) then incremental, i could be breaking my full because I do a copy in the middle? My backup method under general is Full - Copy and my exchange IS backup method is Copy - Database & logs. You are telling me that this can break my Full & incrementals in a different B2D location?

IMHO we are not that large of an organization, we have 600 employees, far less than many businesses. We are using GRT with full templates and incremental dailys as B2D instead of tape. Honestly, I don't think our server is quite as busy as most companies our size. Our exchange server is configured for:
Keep deleted items for 7 days
Keep deleted mailboxes for 30 days
Do not permanently delete mailboxes and items until the store has been backed up =  checked
 *note- backups will fail 2 to 4 days after the full with no apparent pattern to indicate why it's failing.

Up until this fix, we really didn't have any option for restoring individual emails... the clients had to restore from outlook because our daily backups have been so incredibly unreliable.

Unfortunately putting Beta software on our production servers is not the route we are going to take to try to fix this problem. We will wait until symantec provides a decent final revision to the update before we move ahead. I'm not going to apply the update and spend the next few days pushing new agents out to all our servers just to TRY a beta that MIGHT work.  I would also log another support ticket if I had a few hours to spare, and if I didn't think I would get the same answer as before (do more full backups and less dailys).

Being that all our backups for exchange are configured through a policy template, i'm as confused as you are about why this would fix it. Running a completely separate backup with different backup types to a different B2D location should not affect other backups, but it seems to be the case. I just want to see if others can reproduce my situation. It might help Symantec come up with a fix sooner. Symantec has recognized this problem since before version 11... I'm hoping this beta gets finallized soon.

Ahh OK your original post only implied you were doing a copy job under the file system area - you have only just confirmed that your exchange settings were also in copy mode - therefore most of what I said does not apply.  As such I don't know why your Exchange copy job appears to fix the issue as from my understanding it relates to the transaction log build up and this should not change with a copy job.

The Symantec techs told you one of the two known workarounds - which was run your full backups more often, the other workaround is as I said only use GRT against the full backup. You may have discovered a 3rd workaround.

The reason the hang condition occurs is because on an Incremental GRT backup an indexing process starts that has to partly re-index the full and the previous incrementals as well as the one you just ran. This means how busy your Exchange server is (in terms of transactions) does affact it - and also means that you probably won't see too much of a problem on the first incremental and maybe not the second incremental -  although the second will take longer than the first and as more incrementals are involved since the  last full the timescales get exponentially worse.

Hope this helps

Colin

That's very strange now that you mention the reasoning behind the whole issue. My incremental daily backups don't actually take longer and longer each backup. Though the size varies from day to day (in respect to what gets backed up), the times seem to reflect correctly the appropriate durations given the amount of data that are being backed up. The time it takes to run each backup does not increase dramatically over the course of the week, in fact some times are 25 minutes some are 45, the last daily of last week took 32 minutes.

The scariest part is that I've almost gone a whole month now without a failure. Being that I am overwriting my manual (copy) backup each time I run it, I sure hope it's not going to keep me from restoring one of my GRT Full or incrementals.

Is there anyone else out there that can confirm that this works? I'm not sure if this will work outside of a template though.