Forum Discussion

Stashek's avatar
Level 3
9 years ago

Lag Copy for Exchange journaling database.

Hi all.

Exchange lag copy database is definitely something what you must have. All PROs are clear and obvious.

But does it make sense to keep 1 lag copy for journaling database? Under "journaling database" I mean dedicated mailbox database with journal mailboxes only (no uses mailboxes there).

Our DAG contains 4 exchange servers: 1 DB is mounted, the rest 2 servers get replicate immediatelly, and the last server keeps lag copy db.

I can't tell any scenario when this LAG database may be in use. Do you?



5 Replies

  • when the journal archiving task is working properly, you should have no more than 5 minutes worth of email sitting in the journal mailbox.

    does that help with your decision?

  • Not sure that I understood it well.

    As of now lag copy is configured to replicated data with 2 days delay. For lag copy it doesn't metter how long an item has been sitting in journal mailbox: 1 minute or 1 hour.

    Should I use lag copy only in case if items sit in journal mailbox more then 5 minutes?  surprise

    Is there any recomendation for EV regarding Exchange lag configuration?


  • i dont have any customers using lag copies for journaling and not sure how it would make sense or what benefit you would get but i'm open to the discussion

  • My 2 cents:

    As Journal Archiving processes an inbox almost immediately (as Andrew states within 5 minutes) I do not see a point to keep lagged copies for Journal Mailbox Databases. You only add additional resource asking on Exchange. Logreplication, replaying, storage.

    In general, Journal Archiving task scans Journal Mailbox for items to archive, waits for 5 minutes to see if multiple same messages arrive, then archives. The items (when securly archived) are then deleted from the inbox.

    When your journal archiving is running fine I would not use lag copy. As items are archived, and leave no shortcuts, and it is all automatic, there is no risk of an 'accidental' delete of a source item, which takes away the need to have the ability to get the item from a lagged copy.



  • Gents.

    I really appreciate your answers, but looks like we have different undertsanding how DAG works. (please, note, I said 'different'). But there is should be the only one correct. :)

    I am reading right now docs regarding how DAG works and among other things:



    Specify the following information when creating a mailbox database copy:


    The amount of time (in minutes) for log replay delay. This is the replay lag time, which sets how long to wait before the logs are committed to the database copy. You can turn off log replay delay by setting the value for it to 0.




    Continuous Replication–Block Mode

    Exchange Server 2010 SP1 included continuous replication–block mode, and you could implement it to reduce your exposure to data loss on failover. This is achieved by replicating Extensible Storage Engine (ESE) log buffer writes to the passive database copies in parallel to writing them locally. Block mode automatically becomes active when continuous replication file mode is up to date with the database copies. The continuous replication block mode process is as follows:


    From my point of view: every message (journal report\normal one) causes creating log which will be commited to mailbox database. There is no exclusion from this process. So, these logs are being replicated to all Exchange servers within DAG. Logs are commited to each copy of database, and commited to lag copy with some preconfigured delay. This commitment process will occur regardless of time how long this message was sitting in journal mailbox - 5 minutes of 1 hour. In another words I can't understand how journal reports (which has stayed in journal mailbox longer then 5 minutes) may (or may not) cause something related to Exchange lag copy?

    I'll be happy to hear your opinions.


    We use lag copy on journal mailbox databases because we apply the same approach to journal dbs as for normal mailbox db, but it should be reconsidered. I personally think that it makes no sense to create lag copy for journaling database, but I use completely different justification.