When it comes to recovery from an Exchange Server crash, failure, or database corruption, backups play an important role. So, it is important to define a proper backup and recovery strategy to ensure that data and services can be restored successfully and with minimum downtime in case of any issues or disasters.

In this article, we will discuss some best practices for Exchange Server backup and recovery that can help achieve successful data recovery and meet your organization’s recovery time objective (RTO) and recovery point objective (RPO). Here are some best practices for backup and recovery in Exchange Server:

1. Choose compatible and application-aware backup software

Backup is the most important aspect of server management. If anything goes down, it’s the only thing you can rely on. An Exchange Server must back up the following components:

  • System state: This includes local security accounts, cluster configuration (in case of a Database Availability Group [DAG]), registry, and the Internet Information Services (IIS) database.
  • Active directory: This holds all the configuration information of the Exchange Server in the Active Directory Schema.
  • Exchange databases: These include mailbox databases and public folder databases, which are live and active files. Memory and transaction logs act as a buffer. Without a full Volume Shadow Copy Service (VSS), the backup will not be complete.

Considering the above, both the Exchange Server and the Active Directory server must be fully backed up with System State and full VSS backup. So, when choosing backup software or solutions, ensure they are application-aware and compatible with the operating system and the Exchange Server version. For example, you can use the native tool, Windows Server Backup, which is fully compatible with Exchange Server and is application-aware.

2. Choose the right backup method

There are three types of backups in Exchange Server:

  • Full backup: Full backup, as the name implies, takes a full backup of the server and databases, and every backup is independently restorable. This requires a considerable amount of storage to keep all the backups. If the full backup of the server is 500GB and you need to keep a full backup of the server for seven days, then it requires 3.5TB of storage. This option should only be considered if you have ample storage, with the caveat that each backup will take a long time.
  • Incremental backup: Incremental backup will take a full backup the first time and then each day, it will take the backup of changes from the previous day. This is a fast and small-sized backup. However, if one of the previous incremental backups is lost or becomes unusable, you will not be able to restore the data, except for the full backup.
  • Differential backup: Differential backup is similar to the incremental backup but takes the changes from the full backup. So, if you need to restore, you will only need the full backup and the day’s backup.

You can choose any of the above methods, depending on your company’s needs and the resources at hand. Ideally, you should have a local backup for quick restorability and an offsite backup on tape or cloud storage with at least AES-256 encryption.

3. Monitor the Exchange Server and other resources

Monitoring the Exchange Server is important to ensure server health; issues can be tackled before they cause harm. Monitoring vitals, such as CPU, network, and memory is important but you should also monitor the storage. When an Exchange Server reaches zero disk space, it could cause interruptions or corruption in the database or transaction logs.

4. Periodic testing of backups

Taking a backup is not enough. You must perform a restore test to check that the data and server are restorable and backups are valid. It is recommended to perform a weekly test restore of a file from the backup and a monthly full restore in a sandbox environment. This will ensure the backup is done properly.

5. Have a high availability setup

With Exchange Server, you can have a high availability system; if a server is lost, users will continue to work without noticing as the system would failover automatically to other servers. The high availability option using Database Availability Group (DAG) can be set up on a standard version of an operating system and Exchange Server.

The setup involves two or more Exchange Servers where each mailbox or public folder database will have a passive copy on another server. This can be used as a load balancer where you would have four databases – two are active on one server and the other two are active on another server – with each server hosting the copies of the other server. This will complement your local/offsite backup strategy. In case of server failure, the business will not be affected.

6. Perform any server changes in a maintenance window

If you have a standalone Exchange Server, it’s important to take a backup before doing any hardware or software changes or installing any updates. Such tasks should be done in a maintenance window – if something goes wrong, you can go back without impact.

With a DAG setup, it is simpler to shift the services to one of the other nodes and put the server in maintenance mode. In any case, never perform any maintenance task on the live server.

7. Execute the right restoration plan

When disaster strikes, you need to be prepared. Companies should have a written document on how to recover from a disaster, what needs to be done, and how people should be informed. A disaster recovery test should be executed every year to ensure that the document is correct and that the RPO and RTO are met.

In conclusion

Above, we have mentioned some best practices for backup and recovery in Exchange Server. Apart from the right backup solution, you should also look into the strategy, monitoring, periodic testing, and data recoverability in case of a disaster. Though you can restore from the backup, you should also consider the data that has been changed from when the backup is taken, to when the issue has occurred. When a full restore is done, all this is lost.

In such a case, consider using a third-party Exchange Recovery software that can help recover data if the database is corrupted or the transaction log is missing. One such software is Stellar Repair for Exchange. It can complement your disaster recovery plan.

With this software, you can open any database version in any state, with no size limit. You can save the EDB data to PST or export directly to a live Exchange Server database or Office 365 tenant with automatic mailbox matching, parallel export, and priority export. The tool can process user mailboxes, archives, shared mailboxes, disabled mailboxes, and public folders.