Forum Discussion

dhill82's avatar
dhill82
Level 3
12 years ago

Exchange 2010 "Out of page buffers"

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 I...
  • IS2's avatar
    12 years ago

    Update - but not necessarily good news.

    For the past week I did the following with the indicated results:

    • Separate the System and Information Store jobs into two jobs - GOOD
    • Use “Differential” for the Information Store - Didn't make a difference and actually seemed to cause move issues when GRT was turned on.
    • Use “Incremental” for the System - GOOD
    • Do NOT allow the “Differential” and “Incremental” to run at the same time - MAKES SENSE
    • Do NOT turn on Snapshotting (Advanced File Open) for the Information Store job - UNNECESSARY - In reality, BE uses Microsoft VSS automatically on Exchange backups.
    • Turn on GRT for both the System and Information Store jobs - BAD - on the Infostore backups, using GRT created different issues.

    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:

    • System and Infostore jobs are separated
    • System - Full with incrementals using GRT and DEDUP storage
    • Infostore - Full with incrementals using GRT and DISK storage

    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:

    • Because of the dynamic nature of the Exchange database, Dedup storage is not the recommended storage media for Exchange databases. Even though my results were pretty good using Dedup, apparently the BE resources necessary to determine what needs to be written to Dedup are substantial. And, the further away you get from the full backup, the greater the resource requirement becomes - which may be why the incremental jobs die after a few days.
    • One possible solution (which I am not going to try) is to run full backups every night using GRT and Dedup. I may try this at some point, but I'm going to give the Disk backup a shot first.
    • Using Disk instead of Dedup will provide for much faster recovery time for an individual mailbox or mailbox items.
    • Be sure that your Exchange database maintenance jobs do not run at the same time the backup is running.  This is documented in the Best Practices Guide.

    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.