We recommend backing up Exchange on the database level for disaster recovery. If there is a disaster recovery situation, you can import in the entire database as it was at the time of the last backup, minimizing the amount of downtime for your business. While you can select the actual mailbox database (.edb) file using a File and Folder backup type, backing up Exchange this way is not a supported configuration.
We want to stress that Mailbox Level backup should not be relied on for disaster recovery purposes since restoring one mailbox at a time back into Exchange or to a (.pst) file which must be imported into Exchange is a lengthy process and will take much longer than restoring from an Exchange Information Store. Mailbox Level backups are suited for archival purposes.
When creating an Information Store level backup, the software requires you configure a different backup job for each mailbox database you wish to backup. We recommend spacing out the start times of Exchange Information Store jobs if you have multiple ones. Generally, it is recommend you schedule the Public Folder database backup or smaller database backup first so it runs to completion before any larger databases are backed up.
By default, the backup set schedule is configured according to Microsoft's best practice of one full backup per week and six incremental backups. Your first backup of the database is a true full copy, and from there, incremental backups only contain the transaction log changes to Exchange. The next weekly full backup will be a block-level differential of the previous week's full backup.
We keep Exchange Information Store backups according to a weekly retention, by default keeping 4 weeks of backups. You can keep as little as 1 week of data or you can set up a custom retention rule. Keep in mind, to restore an incremental backup, the software must keep that week's differential or full backup and any other incremental backups earlier in that week. Because of this, the software will keep an entire week's backups if any incremental backup dependent on that week's differential or full backup is still in retention. This leads to more usage than you might expect, but this is essential to ensure you can restore your data.
There are two key settings in Exchange that we recommend changing to ensure the most data efficient backups:
Make sure that circular logging is disabled on every database you are backing up. Disabling circular logging will prevent Exchange from overwriting its transaction logs and allow our software to perform normal incremental backups. Incremental backups will be much smaller which will allow backups to complete in a timely manner during the week.
Turn down Exchange maintenance such as defragmentation to only run once or twice per week. Exchange defragmentation shifts data around in your database files which saves you space locally, however, frequent defragmentation shifts the blocks around in the files too much, forcing our block level technology Intelliblox to take more frequent full backups. Defragmentation should be scheduled for some time backups are not running, as overlap between backups and defragmentation may cause errors to be thrown during backup.
If you use another backup utility to backup Exchange such as NTBackup or Backup Exec, it is recommended you set that software to copy the Exchange transaction logs so ours can back them up and truncate them. Using other software to truncate the Exchanges logs will mean our software will receive logs which are out of order, forcing a full backup and increasing overall data storage.