You need to separate here between Logical and Physical corruption:
Physical corruption:
Will occur when the database from an ESE structure is no longer valid in some way. Those corruption couldn´t replicate. Its simply not possible by Microsoft design (Exchange performs multiple steps to validate the logfiles; more infos here). So if the structure from an ESE perspective is no longer valid (e.g. “Dirty Shutdown” due to a hardware failure) you couldn´t bring the EDB online.
Logical corruption:
Will occur when the data within the database is no longer valid, but the structure from an ESE perspective is valid. Those corruption can replicate (but will also occur in a stand alone Exchange server). However you have different ways to deal with them:
- You can move the mailbox, thereby deleting the bad data. Useful, especially when logical corruption occurred outside the backup retention window. (Check the baditemlimit options, more info's here)
- You can implement and use single item recovery and restore the original item. Useful when editing message caused corruption (client app caused corruption scenario).
- You can use the Calendar Repair Assistant to detect and correct inconsistencies (Since Exchange 2010 SP2) See more info's here.
- You can use New-MailboxRepairRequest which can address corruptions with search folders, item counts, folder views, and parent/child folder issues (See more info's here and here).
- You can maintain an Exchange backup (VSS backup or lagged copy if backup retention window is between 0 and 14 days) (See here for more infos).
Conclusion:
A DAG will not help you really to avoid corrupt elements inside the mailbox. But without a DAG you will also have those corrupt elements and need to deal with them anyway. And if one node (during startup) discover that the EDB is corrupt, it will not bring it up (e.g. its in a “Dirty Shutdown”). You need to fix the issue here (e.g. you can create a new DB copy, more other options can be seen here).
