Best Practices
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 backup. Mailbox Level backups are suited for archival purposes.
Configuration
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 recommended 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.
Exchange Considerations
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 Backup Agent 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 encounter logs which are out of order, forcing a full backup and increasing overall data storage.
Database Size
While Exchange allows you to create mailbox databases up to 16 TB in size, we find the ideal size for individual, non-replicated databases between 200 - 250 GB. Since backup and restore times scale with database size, this database size range keeps those times within a reasonable window. This differs for replicated databases, which can grow up to 2 TB before becoming unwieldy. Since Intronis cannot back up replicated databases, we advise you try to keep your clients' mailbox databases close to that 200 - 250 GB size. If you have a mailbox database that is far outside this range, our recommendation is to create a new mailbox database and move some of the user mailboxes to the new database.