Tag Archives: transaction log files

Exchange 2013 Mailbox database Disaster Recovery

In Exchange 2010 Microsoft introduced the Database Availability Group to implement redundancy on mailbox server level and mailbox database level. If a mailbox database (or a server) fails, another one can take over. This concept is carried forward into Exchange 2013 and Exchange 2016 and has improved ever since.

There are still customers that do not use a Database Availability Group and rely on a single server and a solid backup software solution. A backup of the mailbox database is created every night and this continue to run for years. You hope. Until disaster strikes…..

image

I got a call earlier today from a customer. He has been patching his Hyper-V host, and after a reboot his Exchange 2013 server didn’t come up properly. Well, after questioning it turned out that the Exchange server booted correctly, but that only one of three Mailbox databases mounted properly. So, two Mailbox databases (approx. 250 GB in size) seem to be corrupt and this is where the pain begins.

To ‘resolve’ the issue the customer tried to reboot the box again, tried to restore the databases from backup, tried a ‘soft repair’ and tried a ‘hard repair’. No idea what the latter are by the way, but that was according to the customer. But if you know anything about Mailbox databases in Exchange, then you also know that most destruction happens in the first 15 minutes!

If you rely on a single server and a backup solution for restoring services or a disaster recovery scenario you have to know the basics of Exchange database technology. Know what a mailbox database is (except for a large .edb file), know what transactional logging is and how the mailbox database, the transaction log file and the checkpoint file relate to each other. And related to this, it is of utmost importance that you know how to replay transaction log files into a Mailbox database.

Although old, these are good starting points:

Furthermore, you have to know how your backup solution works, and how to restore mailbox database into a production environment. There are streaming backups, but these are rare these days and VSS snapshot backups. You can find more detailed information in the following articles:

Besides the technical knowledge about the Mailbox database technology you have to perform regular ‘fire drills’. Restore a Mailbox database into production, restore using a recovery database, perform replaying of transaction log files, get your hands on ESEUTIL and see what the /G, /K, /P and /R are doing. It will save you a considerable amount of time when you know the technology and the tools, it will reduce risk of data loss and you are able to give a proper planning to your users/manager/customer when the mailboxes are available again.

If you don’t know this you’re playing with fire, and it will backfire to you, believe me!

LUN Design and Hardware VSS

This posting is written by Michel de Rooij, thanks for posting it here as well…

I had a question why you need to design seperate LUNs for Exchange database and log files when using a hardware based Volume Shadow Copy Service (VSS) backup solution, as mentioned in this TechNet article: Understanding Exchange 2010 LUN architecture

To deploy a LUN architecture that only uses a single LUN per database, you must have a database availability group (DAG) that has two or more copies, and not be using a hardware-based Volume Shadow Copy Service (VSS) solution.”

The reason for this requirement is that hardware VSS solutions operate at the hardware level, i.e. the complete LUN. Therefor, if you put the Exchange database and log files on a single LUN, it will always create a snapshot of the whole LUN. This restricts your recovery options, since you can by definition only restore that complete LUN, overwriting log files created after taking the snapshot. So, changes (log files) made after the snapshot are lost and you have no point-in-time recovery options.

For example, with the database and log files on a single LUN, suppose you create a full backup on Saturday 6:00. Then, disaster strikes on Monday. By definition, you can now only restore the database and log files as they were on Saturday 6:00; log files which were created after Saturday 6:00 are lost.

With the database and log files on separate LUNs, you can restore the database LUN, which leaves the LUN with the log files intact. Then, after restoring the database, you can start replaying log files.

So, keep this in mind when planning your Exchange LUNs in conjunction with the backup solution to be used. Note that the Mailbox Role Calculator supports this decision by letting you specify Hardware or Software VSS Backup/Restore as the Backup Methodology to be used.

If you’re interested in more background information on how VSS works, I suggest you check out this TechNet article: Volume Shadow Copy Service