Backups are essential for protecting data, for archival purposes, for compliance, and most importantly for recovery when disaster strikes. When it comes to restoring Exchange Server data from backup, the challenge is to restore it in a timely fashion. With complexity of the setups, which would include Database Availability Groups (DAG), traditional backup alone is not enough. In this article, we will be talking about the challenges and other factors that you would need to know when recovering backups in Exchange Server.
Reasons Why Backups alone are not Enough to Guarantee Complete Exchange Recovery
Backups are a very important aspect of protecting data, but they are not enough to guarantee full recovery. Let’s explore why.
RTO and RPO Compliance
Recovering a large infrastructure from backup can result in a very long recovery process, since there are large databases which can take hours to restore. When doing a full restore of the server, you must either compensate the resources or restore on a new site. There are also other factors you need to consider if you have Database Availability Group (DAG) such as reseeding and log replay tasks would decrease the performance of the server. There are also a number of checks that you must perform post recovery, such as integrity checks, where large databases could take a considerate amount of time. Restoring the database would not help you to meet the Recovery Time Objective (RTO). You would also need to consider the data loss, business loss and the effort of the restore.
Gaps in Recovery
A full, incremental, or differential backup takes backup of the database/server at a particular point in time. If you would restore the database from backup taken a day before, this would mean that all the data in between will be lost. For medium to large companies, this would be a compliance nightmare apart from the data/ business loss.
The backups can protect the databases but these cannot protect against a number of corruptions.
- Logical corruption, where corruption is inside the database. When it goes unnoticed, it will be introduced into the backup. Additionally, if there is any corruption at storage level of the server, this will also affect the backups. You would end up with unusable backups as the restore would introduce the same corruption back to the server.
- Failed or incomplete backups would also impact the recovery. If your backup solution is incompatible or not application aware, then this would mean that the restored data would be corrupted or unusable.
No Granular Restore
There are a number of backup solutions that provide granularity when restoring Exchange Server databases. However, the native tools, such as Windows Server Backup, do not support granularity. This means that you would need to go through the following steps to recover an item from a mailbox or public folder.
- Restore the entire database as a Recovery Database (RDB).
- Run a smooth recovery to run an integrity check.
- Mount the Recovery Database (RDB).
- Export the mailbox using the New-MailboxExportRequest command.
- Import the restored item into the resource.
- Cleanup the process.
As you can see, recovering an item would take a considerable amount of time and resources, since you have to recover the entire database.
Vulnerability of Backups
Like the server, the backups are not immune to vulnerabilities as modern ransomware and malware can target not just the database but also the following:
- Backup repositories.
- Hypervisor snapshots.
- Network shares containing backup data.
Many companies have ditched the tape backups and moved to NAS or other type of network storage. This would mean that the backups are exposed on the network and could be attacked by malware. Some backup solutions support immutability of the backups but if older backups are attacked, this could cause issues. With modern backups, there is the option to have a cloud backup, which would be encrypted and not reachable directly by the local network. However, this would end up in an even longer recovery process, which would go beyond the company’s Recovery Point Objective (RPO) and Recovery Time Objective (RTO).
Strengthening the Exchange Database Recovery
You must always build a resilient Exchange Recovery Strategy. Although backups are important, you must have a specialized Exchange recovery tool to complement the backups so that data recovery can be quick, smooth, and seamless. Tools such as Stellar Repair for Exchange can open any version of Exchange Server be it healthy or corrupted and of any size.
With this tool, you can granularly recover user mailboxes, user archives, public folders, disabled mailboxes, and deleted and purged items with just a few clicks and without having a running Exchange Server. You can export the recovered data to PST and other file formats as well as to a live Exchange Server database or Office 365 tenant. It offers features such as automatic mailbox matching, parallel exports, and priority exports, thus help in reducing the recovery time to the minimum, and respecting the Recovery Point Objective (RPO).
Conclusion
Exchange Server is an essential part for a company. Therefore, it is important to understand that backup alone is not enough to ensure recoverability in the least possible time and with the least possible impact. It is important to consider not just the recoverability, but the business and data loss. You need to also consider the impact that a lengthy recovery process would have on the operations. To reduce the recovery time and minimize the impact, it is essential to keep an Exchange recovery tool, such as Stellar Repair for Exchange, in hand.
