Prior to running Exchange Server Backup Extraction you have to configure your backups to become “Exchange-aware”. From the VMs list on the left select the specific VM(s) running MS Exchange Server, provide its Domain Administrator Credentials. You can add several VMs running Exchange.
Optionally you can choose to Automatically truncate the Exchange Server transaction logs after backup. Selecting this feature allows to actually back up the Exchange Server Database including all the database updates that occurred during the backup time. The feature is disabled by default.
Note that for enabling the Exchange-aware backup, you have to provide guest OS login credentials for the selected VM(s) running MS Exchange server. This means that you have to specify a user with domain administrator privileges. User Account Control (UAC) technology introduced in Windows Server 2008 operating system is not natively supported by Acronis vmProtect 8 since the product accesses the VMs data in agent-less mode. So, if UAC is enabled for the user you specify, we would suggest the following possible solutions (either one is acceptable):
Note that while vmProtect 8 is not a cluster-aware software, it is still possible to perform Exchange-aware backups of Exchange cluster nodes (Exchange 2003 SP2+ versions are supported). During the backup Acronis vmProtect 8 can back up the Exchange databases available for the specific VM (node of Exchange cluster) at the given moment of time. While there are many different types of Exchange cluster (SCC, CCR, DAG) which all have their own specifics, the main thing you should ensure is that the Exchange databases data is actually accessible from the VM you are backing up with "Exchange-aware" option. The same approach applies to transaction logs truncation option – they will be truncated for the accessible databases only.
For example, it does not matter which node of Exchange 2010 DAG cluster you are backing up, since in this case each node can host active databases and passive databases (i.e. replicas of databases from other nodes), and all these databases will be properly backed up as they are accessible from any node. Note that the logs will be truncated for both active and passive databases in this case.
The exception from this rule is SCC cluster where database is located on shared storage and therefore is inaccessible for vStorage API used to get access to the VM data. SCC clusters are NOT supported.
If you are planning to extract the Exchange database from the backup and perform recovery to the point of failure, which implies replacing the database with the backup copy and rolling up the transactions logs on top of it, then you should make sure to extract the very latest version of the database, so that the existing transaction logs can be applied to this copy. If any of the transactions logs are missing in the chain then their roll up will not be possible.