12 May Backing Up Your Exchange Server Using BackupAssist

BackupAssist is most popular in the SMB market and as a result, is often used to back up servers running Microsoft Exchange. However there is more than one way to backup Exchange server using BackupAssist, and most importantly multiple options when it comes to restoring data back to exchange. In this blog post, I want to explain the main differences available with and without using the Additional Exchange Granular Restore console add-on and hopefully explaining how invaluable a tool it is for exchange administrators.

Using Just BackupAssist Core Licence

All Job types within BackupAssist can be used to back up a Local Exchange server but there are key differences that make specific job types more suited to backing up Exchange databases over others.

How Large is the exchange database?
The size of the Exchange database will have a big difference in the time it takes to run different jobs.

Most Exchange databases we come across are in the order of 10’s GB’s some can be 100’s GB in size, and due to the fact that they change daily means that each time a backup job runs these files will be included.

If we use either of the file-based backup jobs within BackupAsisst (File protection and file archiving) then the whole Exchange ‘.ebd’  Database file will need to be backed up each time. This isn’t very efficient both in the speed of backup and space needed to store the backup. In contrast, the System Protection job uses the Windows Imaging Engine to backup files, and this works at the disk sector level. For this reason, subsequent backups of exchange databases can concentrate on just the disk sectors that have changed since the last backup. This is typically a fraction of the total data so the back speed and space used is much smaller as a result.

When can I backup the database?
It’s important to note for the time the job is running the Exchange service is utilising the Volume Shadow Copy Service (VSS) to maintain system changes to the database. This allows the database to be backed up in a consistent state while it’s not changing. So the longer the backup runs the more VSS space is used and during busy I/O periods, this load will increase. For this reason, it’s best to keep the backups of busy services like exchange as short as possible, at the quietest times of the day. In the average office, this is overnight.

For the reasons explained above its generally recommended to use the system protection job to backup exchange, as this is the most efficient backup engine. However, adding additional less frequent file protection or file archiving jobs may be possible if run in quiet times like over a weekend.

Restore options using just BackupAssist
As we can see with just the main BackupAssist core licence you can Backup an exchange database without issues, but you are limited to what you can restore. With a system Protection job, you can in effect restore the whole server (bare metal) including the exchange server back to a specific point in time, but you can also just restore the exchange database if you require. This will require you to stop the exchange services to allow you to restore the previous Exchange database back to a previous version, but with careful management it is possible.

This is great in a disaster where you want to revert the whole exchange server to a point in time but generally, customers require more granular restore options, where they can access and restore some mailbox data.

Introducing Exchange Granular Restore Console

As the name entails the EGR is a restore option. It does not affect how you take a backup of your Exchange database files but instead allows admins to look deep into the backup files and pull out key mailbox data as needed.

So how does the EGR work?
Within BackupAssist when you open the Exchange restore options any previous backups that contain an exchange database can be seen in the list. You can simply choose a version of the Exchange database (.edb file) at a point in time and open this live (directly from the backup media) within the EGR console.

This process may take a few minutes to mount, but once complete you have immediate access to all of the mailbox data for all of the users  stored within that ‘.ebd file’

From here you can navigate through users mailbox data and select any specific data you wish to restore.

This can be either individual email, folders of email or even an entire mailbox for a user.

There is also a useful search tool to help find specific missing messages in the backup.

Once the required data to restore has been selected you can either write this data to a specific PST file (to open afterwards in Outlook as required) or you push the data directly back to a specific mailbox in the local exchange server or if needed any other accessible mailbox on another exchange server.

This is very useful if you need to restore mailbox data to a different server altogether.

This gives admins multiple options when a user loses specific email, but also if needed they can restore a users mailbox to a previous point in time without affect other users on the system.