08-08-2012 10:50 AM
We have been running Backup Exec 2012 with all patches as of today (8/8/2012) to back up our Exchange 2010 (also fully up to date) for a few months. Full backups always complete successfully, then Incrementals will run for 2-3 days just fine. After a few days, Incrementals start to fail with the error "V-79-57344-759 - Unable to complete the operation. The following error was returned when opening the Exchange Database file: '-1014 The database is out of page buffers. '". After this happens, the Incrementals fail with the error "The last backup job was not run by Backup Exec" until the weekly Full backup runs. This happens every week.
The Backup Exec temp files are not be scanned by the antivirus, and I can't find anything on the Exchange server that would run at these times that would use extra resources during the backup windows. Circular loggin is not enabled. I tried changing the registry entries mentioned in the MS KB article that discusses Exchange running out of page buffers (don't remember the KB# off the top of my head).
I've also tried modifiying the backup windows (changing the day the Full runs, changing the times, etc). Still happens within a few days. Is there anything that could be causing this, or settings I can change to avoid this going forward?
Solved! Go to Solution.
10-12-2012 12:14 PM
Thanks for the update. Nothing I've done has worked, and setting up off-host backup failed miserably. Not sure what else to do, so hopefully Symantec can get this straightened out.
10-12-2012 05:35 PM
Symantec is escalating the issue on Monday. In the meantime, I was successful this week by simply turning off the GRT option. This won't work for me long-term, but at least I have a backup of the Exchange Server in case something goes wrong.
10-17-2012 12:45 PM
Update: Symantec Tier 3 support has suggested the following (which I will try for a week).
I’ll give this a shot and let you all know how it works. Obviously, we won’t know much until the end of next week.
10-17-2012 03:00 PM
Having the exact same problem. Fulls work great and Inc seems to not be able to handle the load. I also have a case open with Sym. My tech should talk to your tech.. Case 420-132-318 Thx, Larry
10-18-2012 08:08 AM
I just made the changes that IS@ESPC received from Symantec as well. I set my full backup to run tonight, so we'll see what happens in a few days. I also added 4GB of RAM to my Exchange VM. Probably won't make a difference with the backup, but it's possible.
10-23-2012 07:50 AM
Just checking in to see if the problem still exists for dhill82 and all.
I have the exact same symptoms but with Exchange 2007. Breaking out the File backup to its own job and adding the VFF timeout entry (up to the max of 600) to the registry on the Backup Exec server seemed to help but not cure the problem. I no longer have to restart the services after adding the VFF entry when the job fails.
Restart all the Backup Exec Services for the changes to take effect.
10-26-2012 07:10 AM
Just got this error on my Exchange Inc today for the first time. Similar setup. Exchange 2010 on Hyper-V. BE 2012 on 3600 R2 Appliance (installed 2 months ago). Hyper-V agent backup with GRT runs on Fri night, then Exchange agent Full on Sat night and Incrementals Sun-Thur night. Haven't had any issues until last nights' backup. Read the TECH articles referenced earlier. Will try the fixes IS@ESPC mentions.
Have had sporadic problems with different backups ever since install. Open case for SharePoint failures. Have been nothing but frustrated with BE and Symantec for the last 2 months. We've been using BE for years and have never had the issues we've experienced with 2012 and this appliance. Don't know who to blame it on. Did Symantec release a product that wasn't ready for prime time or have M$ and others made changes/updates that make it difficult to backup their products? Would love to be able to go even one day without worrying about backups. I'll get down off my soap box now...
10-28-2012 10:21 AM
Update - but not necessarily good news.
For the past week I did the following with the indicated results:
The Symantec Tech I talked to recommended that we simply get away from backing up the Infostore using Dedup. While not necessarily documented, using Dedup for Exchange, due to the overhead required, isn't an efficient way to go.
So, what I am now doing, and it appears to work fine, is the following:
The obvious downside is the need to use a lot more disk. I like to keep four weeks of fulls and two weeks of incrementals. I won't be able to do that with this technique. So, I've also added a "Duplicate to Tape" step on the Infostore so that I can have access to older copies of the Infostore.
Here are some of the salient points of my discusison with Symantec Technical Support:
Finally, just in case you haven't seen this link, it's worth checking out. It doesn't really help this situation (unless the documenation has been updated), but there are some good things to consider.
http://www.symantec.com/business/support/index?page=content&id=HOWTO74626
I will update this post next weekend after I've had a chance to let a full week go by using the solution outlined above.
10-29-2012 12:11 PM
I've had good luck so far with the changes that IS@ESPC mentioned on the 17th. I had one backup fail, but the others ran fine afterwards. Before when one failed, they would continue to fail until the next Full backup. I have noticed that since the 25th my logs haven't been getting deleted as they should be, but that's probably an unrelated issue. SQL logs on other servers are deleting as normal, it's just Exchange that's having the problem.
10-29-2012 06:13 PM
I should have mentioned that the 'differential' will not delete log files - by design. Since the differential contains everything since the last 'full', it needs to keep all the logs in case of a restore.
Glad to hear the 'differential' is working for you.
10-30-2012 05:29 AM
I didn't think of that. Of course, now that I said something yesterday, last night's backup failed with the error "V-79-57344-759 - Unable to complete the operation for the following reason: VFF Open Failure. This can be caused by low memory or disk resources." Ugh...
11-02-2012 08:02 AM
Well, after a week of using the following configuration, I have had no problems. See previous post from 10/28 for more details on why this works.