Overview
Barracuda Networks offers an Exchange Information Store backup solution that allows the MSP to select how much Exchange Information Store data to back up, protect, and recover.
Exchange Information Store backup has the following features:
Back up database and log files, with flexible scheduling.
Run automated backups in the background to avoid interruptions.
Sort by date to restore full Exchange Information Stores.
General Considerations
Back up all Exchange databases to protect your customers’ data in the event of a hardware failure or natural disaster. After you reinstall your operating system and Exchange Information Store, you can import the entire database from the last backup. This action minimizes the amount of downtime for the business.
Do not use the individual Mailbox Level backup for disaster recovery, since only one mailbox at a time is restored to Exchange, or to a .pst file that must be imported into Exchange.
Instead of selecting the Exchange database folder location in a file backup, create a new backup set in the Management Portal, and select Exchange Information Stores.
The ECHOplatform agent software must be installed directly on the Exchange server to display this backup set option.
The Barracuda Exchange plug-in backs up Exchange at the database level using Microsoft's best practices.
For Exchange 2007/2010/2013/2016 the following process occurs:
| Stage | What Happens |
|---|---|
| 1 | The ECHOplatform agent software uses Microsoft's Exchange Volume Shadow Service (VSS) copywriter. VSS takes a shadow copy of Exchange and backs up the files directly off the shadow copy. |
| 2 | Volume Shadow Copy is able to take a snapshot, from which the ECHOplatform agent software can back up directly, requiring less free Temporary Space. The ECHOplatform agent creates a persistent snapshot that is used for the duration of the backup. After the snapshot is taken, the Exchange VSS Writer is released, so that other utilities can back up Exchange. |
| 3 | During full backup, the ECHOplatform agent backs up the database files for Exchange, and then attempts to truncate the transaction logs on the machine after they are backed up. The Exchange database files are broken into 100 MB chunks that the ECHOplatform agent uploads individually to provide stability to the backup. Each chunk allows numerous retries in case the customer encounters connection issues. However, if the backup is canceled, or a particular chunk cannot be uploaded, the backup fails because not all chunks are present. |
Specific Restrictions and Recommendations
When creating an Information Store level backup, the software requires you to pick which database you want to back up. You must configure a different backup job for each database being backed up.
Stagger the start times of the jobs if you have multiple Exchange backups, making sure that jobs do not start at exactly the same time.
Schedule backup sets to run from smallest to largest.
Schedule the Public Folder database backup or smaller database backup first, so this backup is completed before the larger database backups run.
By default, the backup set schedule is configured according to Microsoft's best practice of one full backup per week with six daily incremental backups.
Your first backup of the database is a true full copy, and incremental backups afterwards contain only the transaction log changes to Exchange.
The next full weekly backup uses the ECHOplatform agent Intelliblox technology to take block-level differentials of the previous week's full backup.
Barracuda keeps a weekly retention of Exchange, and by default keeps four weeks of Exchange data. You can keep as little as one week of data.
To restore an incremental backup, the software must keep that week's differential, or full backup, and any other incremental backups from earlier in the week. This retention leads to increased usage, but is essential to ensure that you can restore your data.
The two key settings in Exchange that need to change to ensure the most data efficient backups are:
- Circular logging
- Defragmentation
Circular Logging
Make sure that circular logging is disabled on each database you are backing up. Disabling circular logging prevents Exchange from overwriting Exchange transaction logs and allows the ECHOplatform agent software to perform normal incremental backups. Incremental backups are smaller, and complete faster during the week.
Defragmentation
Set Exchange maintenance such as defragmentation to 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 Intelliblox block-level technology to make more frequent full backups.
If you use another backup utility to back up Exchange such as NTBackup or Backup Exec, set that software to Copy Only Mode to copy the Exchange transaction logs, so that the ECHOplatform agent can back them up and truncate them. Using other software to truncate the Exchanges logs means that the ECHOplatform agent software receives logs that are out of order, forcing full backups and increasing overall data storage.
Exchange Forcing Full Backups
If Exchange backups take a long time and backs up too much information, view the logs from the ECHOplatform agent software under Diagnostics > Browse Previous Actions to see if backups are full.
If backups are full, check the following conditions:
- Circular logging
- Exchange logs not being in sequential order
- Too many changes to the .edb files
Exchange logs can get out of order from other backups truncating logs or from failed backups. In addition, defragmenting can disrupt Intelliblox block-level technology.
To resolve these issues, perform the following steps.
- Disable circular logging.
- Set other utilities like NTBackup or Backup Exec to Copy Only mode for the logs.
- Set Exchange defragmentation to occur once or twice per week so as not to disrupt Intelliblox.
Exchange Information Store Usage Logic
The following table provides the decision-making stages followed by the ECHOplatform agent software as it manages Exchange Information Store content using the default 4-week retention rule policy.
| Week | What Happens | Graphic |
|---|---|---|
| 1 | Exchange is called for a full (Base) backup. Exchange truncates all Log files into the .edb, and the Backup Agent backs up all the data in the edb. |  |
| 2 | The Backup Agent calls Exchange to do log truncation, pulling all of last week’s transaction logs into the .edb. Intelliblox then processes the .edb and backs up only the new additions to the database. The blue portion represented in the graphic is not transferred or charged for, as it already exists in the week 1 full revision. |  |
| 3 | The same as Week 2. Note: To restore Week 3, day 4, you need Week 1 Day 1 and Week 3 Days 1, 2, 3, 4. Week 2 is not needed to restore data from Week 3. |  |
| 4 | The same as week 2. | NA |
| 5 | Assuming a four-week retention policy, by the end of week 5, no data is needed from Week 1 days 2-6. These files are purged. Note that all current weeks are still dependent on Week 1 Day 1. This file is not purged. | NA |
| 6 | By the end of week 6, no files are needed from Week 2. These files are purged. Note that Week 1 Day 1 is retained. | NA |