Exchange – One option to restore data from lagged database copy

Recover data from lagged copy:

1. Gather info where user resides

Usually we need to know in which database user resides

2. Check if mailbox is still in disconnected mailboxes

Get-MailboxDatabase mdb13 | get-mailboxstatistics | where {$_.disconnectdate -ne $null}

DisplayName               ItemCount    StorageLimitStatus                                                 LastLogonTime
-----------               ---------    ------------------                                                 -------------
a1			  1962                 BelowLimit                                           5/7/2013 4:01:41 PM
S 		          2075                 BelowLimit                                          6/19/2013 9:26:52 AM
Hän		          185                  BelowLimit                                          4/30/2013 9:19:26 AM

3. Mailbox is not in disconnected state

If mailbox is not in disconnected mailboxes anymore, we have another 14 days before lagged copy disconnected date expires

4. Suspend lagged copy

Suspend lagged copy by command:

Get-MailboxDatabase mdb13 | Get-MailboxDatabaseCopyStatus

Name                                          Status          CopyQueue ReplayQueue LastInspectedLogTime   ContentIndex
                                                              Length    Length                             State
----                                          ------          --------- ----------- --------------------   ------------
MDB13\SRVMBX1                          		Mounted         0         0                                  Healthy
MDB13\SRVMBX2                          		Healthy         0         2           7/9/2013 11:33:38 AM   Healthy
MDB13\SRVMBX3                         		Healthy         0         2           7/9/2013 11:33:38 AM   Healthy
MDB13\SRVPF1                           		Healthy         0         110355      7/9/2013 11:33:38 AM   Healthy

Suspend-MailboxDatabaseCopy MDB13\SRVPF1

Are you sure you want to perform this action?
Suspending mailbox database copy "MDB13" on server "SRVPF1".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): y

5. Copy lagged database to different location

To perform non destructive recovery we need to create additional copy of lagged database. This database will be restored to particular point in time.

6. Check if database is in clean shutdown

Dump headers of database by command:

eseutil /mh .\MDB13.edb

Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 14.03
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating FILE DUMP mode...
         Database: .\MDB13.edb

Checksum Information:
Expected Checksum: 0xf3fb4807
  Actual Checksum: 0xf3fb4807

        File Type: Database
         Checksum: 0xf3fb4807
   Format ulMagic: 0x89abcdef
   Engine ulMagic: 0x89abcdef
 Format ulVersion: 0x620,17
 Engine ulVersion: 0x620,17
Created ulVersion: 0x620,17
     DB Signature: Create time:01/24/2012 02:52:12 Rand:391137630 Computer:
         cbDbPage: 32768
           dbtime: 3824249608 (0xe3f16b08)
            State: Dirty Shutdown

7. Determine PIT backup time and move newer logs elsewhere

In my example I want DB to be recovered to 29.6.2013. Be careful! You need EDB file 🙂


8. Reply logs to database to specified point in time:

Newer logs than specified PIT should be moved elsewhere or deleted (better after recovery process has been done)
Chk file should be removed (checkpoint) to reply all logs present in directory.
The following command will reply logs till PIT to database

Eseutil /r eXX /a


9. Put DB to clean shutdown

If the database is still in Dirty shutdown mode, we need to run integrity check and hard repair the database

eseutil /p .\MDB13.edb /g

DB repaired

10. Check if DB is in clean shutdown after repair

eseutil /mh .\MDB13.edb

Clean Shutdown

11. Delete all log files since those are not needed anymore

12. Create recovery database

New-MailboxDatabase -Recovery -Name RDB_13 -Server SRVPF1 -EdbFilePath e:\lagged_mdb13\mdb13
.edb -LogFolderPath e:\lagged_mdb13
WARNING: Recovery database 'RDB_13' was created using existing file e:\lagged_mdb13\mdb13.edb. The database must be
brought into a clean shutdown state before it can be mounted.

Name                           Server          Recovery        ReplicationType
----                           ------          --------        ---------------
RDB_13                         SRVPF1   True            None

13. Mount database

Mount database by issuing command:

Mount-Database RDB_13

14. Gather data about mailbox, you want to restore

Display name or StoreMailbox guid. For example use this command:

get-mailboxdatabase rdb_13 | Get-MailboxStatistics | where {$_.Displayname -like "Niitty*"}


15. Restore mailbox

To restore mailbox use the following command:

New-MailboxRestoreRequest -SourceDatabase RDB_13 -SourceStoreMailbox "Surname, name" -TargetMailbox alias -AllowLegacyDNMismatch

16. Check results

Get-MailboxRestoreRequest "MailboxRestore"


Exchange 2010 – Mailbox Database Lagged Copies

Should we implement the lagged copies for our Exchange environment (mainly for backup-less solution). The choice will be dictated by personal preference, previous deployment history, our knowledge or support service level, but let’s see few things:

  • Lagged copies are recommended (also using multiple lagged copies or redundant array) by Microsoft or Symantec (they maybe know why). It can provide protection against a range of failures that would ordinarily cause data loss. There is no way how to achieve the same protection without backup. It is best practice to have at least enough room for three additional days of transaction logs, to provide for potential truncation failures or periods of excessive log file generation.
  • Lagged copies are designed for disaster recovery purposes, to protect against store logical corruption (which although rare):
    • Database logical corruption (the data is either never written to the disk or it’s written to the wrong place)
    • Store logical corruption (the data is added, deleted, or manipulated in a way that the user doesn’t expect. These cases are generally caused by third-party applications.)
    • Rogue Admin Protection (the data is  added, changed, or removed from the system in undesirable way)

Notes: If we want to replay log files up to a specific point in time, it’s a more difficult operation because we manually manipulate log files and run the Eseutil tool. The lagged copy is blank database voting member node in DAG (violates the “rule of three”).

  • If we use multiple database copies and Single Item Recovery, only the extremely rare catastrophic store logical corruption case is interesting. In the following scenarios lagged database copies can be used to recover data:
    • Recovering a log file that was deleted on the source
    • Rolling back to a point in time because of a virus outbreak
    • Recovering a deleted item that is outside the retention time (mount a lagged database as a recovery database)
  • We can use two parameters: ReplayLagTime (a delay log replay for the database copy) and TruncationLagTime (a delay log deletion for the database copy after the log file has been replayed into the database copy). The replay lag time setting has a default setting of 0 days, and a maximum setting of 14 days. The greater the replay lag time, the longer the database recovery process. Depending on the number of log files that need to replayed during recovery, and the speed at which your hardware can replay them, it may take several hours or more to recover a database. At a minimum, we should see a log replay rate of two logs per second per database.
  • Definitely, when planning for lagged database copies, we should carefully consider the implications this brings to your storage planning. Every lagged database needs sufficient disk space for holding the database as well as the log files for the configured time.

Managing Mailbox Database Copies
Activate a Lagged Mailbox Database Copy