The best approach to Microsoft Exchange backup relies on it’s own organization. Since having only one file to store the database can slow backup, restoring and eventual differential backups, it’s better to configure Exchange to store it’s database in several smaller files, according to the developer:
Exchange supports multiple databases and storage groups on the same server. This support permits you to split a single logical database into multiple physical databases. You can back up and restore these smaller physical databases much faster than larger databases. Additionally, you can help improve overall system reliability by using multiple physical databases because you can restore an individual database from a backup while other databases continue to service client requests.
Make sure that Exchange database files have different file names. Having two stores with same database names will cause errors after the restore if both of those stores are being restored at the same time.
For example, if First Storage Group has two Mailbox Stores and both of them have database files named “Priv1.edb” and “Priv1.stm,” this problem will occur if both of those stores are backed up and restored at the same time.
In order for restore to work correctly when you have multiple stores on Exchange server, make sure that database files have different names.
Additionally, make sure that multiple databases in the same Storage Group are uniquely named. Otherwise, during a restore process of the whole Storage Group, the associated patch files will be generated with the same file name and will be overwritten. This will cause the restore to fail.
Backing up stores that have database files with same names separately (one by one) will work
Besides of splitting Exchange database per size, witch can be done to match each user mailbox quota[1] its probably also a good idea to create Archive Mailboxes for each user in different databases also to store old emails. Since they are most unlikely to change, hopefully incremental backups will save some backup storage.
Bacula:
Microsoft Exchange in 2013 version typically stores its database information on this path, that should be included in server backup FileSet:
C:Program FilesMicrosoftExchange ServerV15MailboxFirst Storage Group
Bacula includes solid VSS support since version 2.0. This should allow you to safely back up a consistent snapshot of an Exchange database. But bacula does not involve the VSS writers in any sophisticated way, so even if you run a full backup, this is not registered by Exchange, the last full backup timestamp is not set and the transaction-logs are not flushed. This is the way it is built and not a bug.
Note that the VSS Writer for Exchange appears to be disabled by default in some versions of Windows Server. You may verify this is the case by examining the VSS messages, which will look like this:
27-Mar 03:45 exchange-fd: VSS Writer (BackupComplete): "System Writer", State: 0x1 (VSS_WS_STABLE)
27-Mar 03:45 exchange-fd: VSS Writer (BackupComplete): "FRS Writer", State: 0x1 (VSS_WS_STABLE)
27-Mar 03:45 exchange-fd: VSS Writer (BackupComplete): "MSDEWriter", State: 0x1 (VSS_WS_STABLE)
Note the lack of an Exchange Writer entry. This Microsoft knowledge base entry discusses how to enable it, which will allow you to use 3rd party backup packages such as Bacula.
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q838183
You may also find the ExMerge program useful. It is a Microsoft application that allows you to extract and merge individual mailboxes as PST files from and to an Exchange server. It should allow you to extract all of the individual mailboxes into seperate PST files, which would then be backed up by bacula.
[1] https://technet.microsoft.com/en-us/library/ee832796%28v=exchg.141%29.aspx#item
Disponível em: 
Português
