Databases in Exchange Server play a crucial role in the smooth functioning of an organization as all the critical information, such as emails, contacts, tasks, notes, calendars, etc., is stored in them. Sometimes, databases become corrupted due to server failure or crash, hardware faults, software issues, and many other reasons, leading to a data loss situation. To successfully restore or recover data, you need to understand more about the Exchange Server databases and their file structure. In this guide, we will discuss the Exchange database structure and its components. We will also discuss some strategies and tools that can help in swift Exchange Server database recovery.
1. Understanding Exchange Server Database Architecture
Database Components: Exchange Server database (EDB) files store all the mailbox data, including emails, calendar items, contacts, tasks, and the entire Exchange mailbox information. You can find the file with the .edb extension.
STM files are used in Exchange Server 2010 and earlier versions to hold new messages on the server until these are streamed to the mail client. In newer versions, from Exchange Server 2013 onwards, the STM (.stm) files have transitioned to Streaming data files (.dat).
Transaction logs (.log) files hold temporary data and are used as a buffer between the database and the user. This temporary data is then committed and automatically purged after a successful backup.
Checkpoint Files keep track of the transaction logs and ensure that the data is properly committed to the database while maintaining the data integrity in recovery instances.
Database States: An Exchange Server database, be it a public folder database or a mailbox database, has two states:
Clean Shutdown: This is the normal state of a working database. This indicates that the database is healthy and in a consistent state, all logs have been committed, and there are no missing or corrupt logs.
Dirty Shutdown: When a database is in Dirty Shutdown state, it means that there is a problem with the database. Until the problem is fixed, the database will not mount on the Exchange Server.
2. Causes of Database Corruption
Hardware failure or issues with the underlying infrastructure, such as SAN storage, fiber connections, disk, motherboard, faulty RAID controller, etc., are common causes of database corruption.
Malware or ransomware infection, misconfiguration of the Exchange Server, non-compatible third-party software, or other software issues could also corrupt the database or transaction logs.
Sudden power loss can also cause corruption in database as the database will not smoothly shutdown, causing issues with pending transactions and inconsistencies.
Storage issues can also cause database corruption. If the Exchange Server database exceeds the stipulated size limit, it may also cause corruption and performance issues in the database.
3. Backup Strategies
There are majorly three backup types:
Full Backup: This takes a full backup of the entire server, including the databases, drives, and state of the server. This is the ideal backup as it’s not dependent on previous backups when it comes to restore. However, it takes a lot of time to complete and a lot of storage resources to keep all the backups.
Incremental Backup: This takes a full backup for the first time and then backs up only the changes since the last backup, thus saving storage space and time. The incremental backup is dependent on each and every previous backup. So, if you have an issue with one of the previous backups, you will not be able to restore it. This is the fastest backup and uses less storage.
Differential Backup: This is similar to incremental backup, but it takes an incremental backup from the first full backup. This means that the backup is only dependent on the first full backup. This is safer than incremental backup, but it will take more time and require storage.
4. Backup Best Practices
Here are some best practices that can help in the recovery of databases from backup when the need arises:
Automate: It’s important that the backups are scheduled on a regular basis and are consistently taken outside business hours to reduce the impact on the performance of the server.
Offsite Storage: It is ideal to store the backups at an offsite location. This will ensure that if something happens to the server, server room, and site, you can recover the data and server when a local disaster happens.
Verification: Having a backup and not testing or monitoring it is like not taking a backup at all. The backups should be checked on a daily basis, and test restores should be done on a monthly basis to ensure the restorability of the backups.
5. Backup Restore Options
Here are the restore options you can consider:
Point-in-Time Recovery
This method is used in the Exchange Server to recover data at a specific point in time. This would need the Full Backup and Transaction Logs. In this process, data is replayed for a more precise recovery.
Bare Metal Recovery
This is mostly used when recovering backup of a physical server in case of a catastrophic failure. In this, the backup is restored using a bootable recovery media and you will be able to restore a server to its original state, including the operating system, Exchange Server, and data without the need of re-configuration.
6. Built-in Exchange Recovery Tools
ESEUtil is the built-in recovery tool that you can use to check the state of the database and perform the recovery process. Here are some operations you can perform using Eseutil commands:
Eseutil /r
This is used to perform soft recovery of a database if it is in a dirty shutdown state. It replays uncommitted transaction logs, fixes inconsistencies, and does not purge any data from the database. This should always be the first option when it comes to recovering a database from a dirty shutdown state.
Eseutil /p
This is used to perform hard recovery. This process helps to recover the database but will purge any data that is deemed as corrupted, including possible false positives. You should perform hard recovery as a last resort, as there is a high risk of data loss. You are advised to make a backup before running this option.
Eseutil /d
After running a recovery task on a database, you should run this command to defragment the database. This will compact the database and help improve storage and performance.
Eseutil /g
This will run a physical consistency check (Integrity Check) on the database to confirm that there are no issues or corruption.
7. Third-Party Exchange Database Recovery Tools
You can also use third-party Exchange recovery tools, like Stellar Repair for Exchange. This is one of the top Exchange server recovery software in the market when it comes to the recovery of data from corrupted Exchange Server databases. Stellar Repair for Exchange can open any version of Exchange Server databases, with no size limit and in any state. After a quick scan, it presents the full structure of the database. It can export user mailboxes, shared mailboxes, disabled mailboxes, user archives, public folders, and even purged or deleted items to PST and other file formats. It can also export the EDB data directly to a live Exchange Server database or Microsoft 365 tenant with automatic mailbox matching. The tool helps reduce the business’s RPO and RTO.
8. Alternate Recovery Methods
Here are some alternatives you can use for database recovery:
Database Portability:
This is the process when a database is mounted from one server to another within the same Exchange organization and infrastructure. The steps involve dismounting the database, transferring the database and its files to another server, and then mounting it.
Dial Tone Recovery:
This process involves the creation of a temporary dial-tone database (which is an empty database), moving the mailboxes to the dial-tone database, and then mounting the database to allow users to continue sending/receiving emails while the original database is repaired.
9. Testing and Validation
After recovering the database, it is important to check it and perform some tests.
Database Mounting:
After running a recovery process, it is important to check the state of the database. After this is complete, you can use the below command to mount the database.
Mount-Database -Identity <database name>
Check Mailbox Functionality:
After mounting the database, you should confirm and check that the users can access their mailboxes. You can also run the mailbox diagnostics from the Exchange Admin Center (EAC) to check the mail flow, performance, and other aspects.
Data Integrity Checks:
You can run the EseUtil with the /k parameter to check the physical consistency of the database.
eseutil /k <file location and file of edb file>
10. Disaster Recovery Planning
Create a Detailed Disaster Recovery Plan
Creating a disaster recovery document is crucial for backup and recovery processes when a disaster happens. This will include all the steps needed to recover the server and the data. It should also define roles and responsibilities for team members in such scenarios.
Redundancy
To reduce the single point of failure, you should consider the implementation of Database Availability Groups (DAGs) for redundancy and automatic failover. In a DAG setup, you can have more than two servers at different locations.
Regular Testing and Drills
Regular testing of the backups should be initiated, along with an annual full disaster recovery test in a sandbox environment. This helps you to test the recovery documentation so that the team is prepared in case of a real disaster.
To Conclude
In case of server failure or any other issue, you need to ensure quick recovery of the database and services. In this guide, we have mentioned various practices and strategies that can help in Exchange database recovery in case of a disaster or issue. Though backups can come in handy in case of database corruption, there is a risk of data loss if the backup is not fully updated. Therefore, it is important to keep the right tools in hand to help with quick and smooth data recovery. One such tool is Stellar Repair for Exchange, which makes the Exchange database recovery process easy and quick and with no data loss.
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.