How often do you test Disaster Recovery strategy for your Exchange server and database?
An effective Exchange Disaster Recovery Plan or DRP is not limited to configuring a backup and an alternative setup if Exchange infrastructure becomes unavailable. It also includes testing the DRP for resiliency. However, considering the costs of–current backup infrastructure, end-user downtime and data loss when recovering database from backup, it is necessary to find alternatives that can reduce cost of recovery and ensure lesser downtime.
Hardware failure – predominantly occurs when multiple server roles such as Exchange, Active Directory, File Server, SQL, etc. are implemented on the same chassis. Any discrepancy in either of the roles may cause a breakdown in the entire Exchange setup. If an Exchange software or hardware fails, multiple database copies in a Database Availability Group or DAG work to provide fast failover and ensure minimum or no data loss. This failover mechanism eliminates server downtime and ensures continued productivity. However, in the absence of DAG, there is no possibility of server availability or failover.
When a disaster strikes, the first and foremost task of Exchange administrators is to get the server up and running and recover the database. But, when backup is not available or data is missing for some mailboxes, then restoring Exchange database from available backup may result in heavy data loss.
Here are a few scenarios where Exchange server administrators perform disaster recovery in Exchange 2016, 2013, and 2010:
- When an Exchange server fails, DRP highlights processes to ‘failover and failback’ the services on separate machine. Forming clusters for servers and database ensures that the services failover to secondary server and failback when Exchange services are resumed.
- Backups not up-to-date or not working result in loss of Exchange database. Also, when an administrator tries to restore data, the backup maybe corrupt or outdated. Disaster Recovery Plan has guidelines to run proper tests in a lab-environment ensuring that administrators can mount Exchange databases and resume normal working of Outlook so that users can work on Outlook.
- Changes without a change control: Change Advisory Board or CAB is responsible for making relevant changes on any IT system, including Exchange. If CAB performs an unwanted or abrupt change and that change is not executed properly, then Disaster Recovery Plan helps in resuming business continuity with little or no downtime.
- In recent times, Ransomware attacks have become common and if Exchange server is infected, it results in encryption of the entire database. Such Exchange database issues can be resolved with third-party software such as Stellar Repair for Exchange.
Note: In Exchange 2019 and 2016, Microsoft’s preferred architecture is available with an in-built mechanism ‘Exchange Native Data Protection’ to backup Exchange data. Using this protection, administrators can back up and maintain their mailbox data on the Exchange system, and eliminate the need for traditional backup. If a disaster strikes, administrators use this high-availability, built-in feature of Exchange server backup and minimize downtime and data loss. Thus, combining the backup feature and other built-in feature such as ‘Legal Hold’, administrators can manage disaster recovery and reduce total cost of ownership (TCO) of messaging.
Methods to resolve disaster recovery issues in Exchange 2016/2013/2010
Restore Exchange database through backup
When a disaster strikes, the normal course of action to recover Exchange database is primarily performed through backups. But, ever wondered the technologies supporting backup on Exchange database?
Exchange Server supports Exchange-aware, VSS-based backups only. The plug-in in Exchange server connects directly with Windows server backup and allows administrators to make and restore VSS-based backups of Exchange database. However, the backup process requires an Exchange-aware application that supports VSS writer for Exchange server. Such Exchange-aware applications are Windows Server Backup (with the VSS plug-in), Microsoft System Center 2012 – Data Protection Manager, or a third-party Exchange-aware VSS-based application.
As per DRP, if the backup is not available in restorable state, then recover Exchange servers by using /Mode:RecoverServer switch in unattended mode of Exchange setup.
Recover Exchange server with the help of /Mode:RecoverServer switch
Prerequisites to recover Exchange server:
- Exchange administrators must set up a new hardware to recover Exchange server. In case, new hardware is not available, use an existing server that doesn’t have an Exchange server role pre-installed on it.
- Check that the Exchange server isn’t a member of database availability group (DAG). If it is a member of DAG, follow the reference (https://docs.microsoft.com/en-us/exchange/high-availability/disaster-recovery/recover-dag-member-servers?view=exchserver-2019) to recover the database.
The detailed steps to recover Exchange server are available on Microsoft site. Once the administrators have completed Exchange recovery process, they can verify the whole process with a verification process, also mentioned on Microsoft suggested sites.
The only issue with Exchange recovery and its verification is that both processes involve several steps and may take more than the required time for Exchange server recovery.
Exchange server is crucial for almost all organizations, hence, the disaster recovery process must not extend to large downtimes. An easy and fast solution to resolve disaster recovery issue in Exchange is through a third-party software.
Recover Exchange database with third-party software
When a disaster strikes, Exchange database goes into an inconsistent state. At that time, an Exchange database repair software provides a ready solution to repair the E database and bring it to consistent state. A software-based database repair solution with its simple interface resolves issues associated with Exchange server and helps administrators by exporting the data directly to a Live Exchange server. The Exchange server recovery software also helps in recovering Public folders and deleted mailboxes.
Exporting entire Exchange database to a Live Exchange server allows users to access their mailbox data and ensures minimum downtime.
Conclusion
This post was focused on disaster recovery plan to ensure that Exchange server is up and running 24×7.
An Exchange DRP must be drafted keeping in mind the various instances which can affect Exchange server and its database. Also, it must be tested periodically for resiliency. In most DRPs, Exchange administrators focus on implementing a redundant system for failover and maintaining a restorable backup of the entire database.
But, what if the failback is not successful and the backup is not available in restorable state?
A good DRP must also include methods to recover Exchange server and its database, either manually or through third-party software. Manual recovery methods are time taking and may prolong server downtime, thus increasing the cost of recovery. In comparison, third party software such as Stellar Repair for Exchange is specially developed to repair corrupt Exchange database and reduce downtime by exporting data directly to live Exchange server.
