DPM2012 doesnt commit to database for backup RRS feed

  • Question

  •  Hi We are using DPM 2012 to backup exchange 2010 ,D2D only. retention for 3 days. but the  DPM doesn't commit to database and purged away the log after full backup job .  I can see all logs still there for many days. it did one time of commit within the past 7 days. it supposed to purge much earlier. any advice  please?Thanks

    Thanks and best regards, -- KF

    Friday, July 12, 2013 7:15 AM

All replies

  • Hi,

    DPM plays no role of when Exchange logs get truncated after a successful backup.  If this is a DAG, be sure you select to do a FULL backup of one copy of each database.  Copy-only backups do not initiate log truncation.

    Exchange Writer tells Information Store, that backup has completed. Now Information Store using its own logic can decide which logs can be truncated. Basically IS will retrieve from passive copies information about what is the oldest log not yet replayed to the database and will look for the Checkpoint at Log Generation in log header in this log. It will allow logs older than Checkpoint at Log Generation to be truncated. Approximately 200 logs should remain.

     See Tim’s excellent blog post on this subject:


    FROM:   (exch 2013)
  (exch 2012)

    Specifically, the Microsoft Exchange Replication Service manages CRCL so that log continuity is maintained and logs are not deleted if they are still needed for replication. The Microsoft Exchange Replication Service and the Microsoft Exchange Information Store service communicate by using remote procedure calls (RPCs) regarding which log files can be deleted.

    For truncation to occur on highly available (non-lagged) mailbox database copies, the answer must be "Yes" to the following questions:

    * Has the log file been backed up, or is CRCL enabled?
    * Is the log file below the checkpoint?
    * Do the other non-lagged copies of the database agree with deletion?
    * Has the log file been inspected by all lagged copies of the database?

    For truncation to occur on lagged database copies, the answer must be "Yes" to the following questions:

    * Is the log file below the checkpoint?
    * Is the log file older than ReplayLagTime + TruncationLagTime?
    * Is the log file deleted on the active copy of the database?

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Friday, July 12, 2013 9:02 PM