Troubleshooting
Problem
Data Protection for Exchange restores a FULL and INCREMENTAL backup without any errors, but the mount of this Exchange database fails.
Symptom
After a successful FULL and INCR restore with Data Protection for Exchange, the database will not mount. The following error can be seen in the Windows Event Log:
Couldn't mount the database that you specified.
- RDB01;
- An Active Manager operation failed. Error: The database action failed. Error: An error occurred while trying to select a database copy for possible activation. Error: The database 'RDB01' was not mounted because errors occurred either while validating database copies for possible activation, or while attempting to activate another copy. Detailed error(s):
Cause
The DAGNODE is not specified in the tdpexc.cfg for the FULL and INCR backups that are being performed on more than one Exchange Server in the DAG, and this truncates the log files that are needed for the restore.
Diagnosing The Problem
Check the Windows Event log, on the machine where the restore is being performed, for messages indicating that there are Exchange log files missing. For example:
Information Store (5216) Logfile Integrity-Check (F:\EXCHRESTORE\TEMPLOG\RDB01\_restoredLogs\E01): The range of log files E:\EXCHRESTORE\TEMPLOG\RDB01\_restoredLogs\E010000BBFC.log to
E:\EXCHRESTORE\TEMPLOG\RDB01\_restoredLogs\E010000C111.log is missing (error -528) and cannot be used. If these log files are required for recovery, a good copy of these log files will be needed for recovery to complete successfully.
The adsm.sys\vss_staging subdirectories contain audit files which list the Exchange logs that are included in the backup. These *audit.txt.log files can be reviewed to determine whether the missing Exchange logs were backed up. In this example, the audit.txt.log file for the FULL backup shows that the .edb file and the Exchange logs, from E010000B5EA.log thru E010000BBFB.log, where included. The next incremental backup, on the same machine, shows that it includes the logs E010000C112.log thru E010000C1B6.log
Notice the gap in the logs from E010000BBFB.log until E010000C112.log (the exact same logs that are indicated as missing in the Windows Event Log error message above).
If there are backups of the Exchange Server database being performed on multiple machines, then look at the audit.txt.log file on the other machine(s) to see which Exchange logs were backed up. For this specific problem we would see that the "missing" log files were actually backed up from another machine.
Resolving The Problem
In an Exchange Server 2010 DAG environment, each database is considered to be exactly the same on all machines in the DAG (not another copy, but the same entity). The logs for this database are
also the same on all of the Exchange Servers in the DAG and are kept in synch with a "log shipping" methodology; whereby the logs are controlled by the active copy of the database and then "shipped"/updated on the other machines by the exchange replication service.
Each FULL backup of the Exchange database will include the log files since the last backup and then truncate the log files. This truncation will be performed by the active database and then the truncated log files will be removed from all the Exchange Servers within the DAG.
If FULL and INCREMENTAL backups are performed on more than one Exchange Server within the DAG, and the DAGNODE is not configured in the tdpexc.cfg file, this can lead to the log files not being in sequence for a restore from a specific machine. For example, if the backup scenario has 1 full back up and 7 incremental back ups performed as follows:
Machine-1 | Machine-2 | |
| Bkup1 | FULL | |
| Bkup2 | INCR | |
| Bkup3 | INCR | |
| Bkup4 | INCR | |
| Bkup5 | INCR | |
| Bkup6 | INCR | |
| Bkup7 | INCR | |
| Bkup8 | INCR |
This would save 2 of the incremental backups on the Tivoli Storage Manager Server under the Exchange Server that is on Machine-2. Thus if doing a restore of the full and all the incremental backups, from Machine-1, this would be missing those logs saved from Machine-2.
To work around this type of scenario it is necessary to perform the restore with the RECOVER only being specified for the very last INCR restoration. These restore operations should all be executed from one machine.
Machine-1 | Machine-2 | ||
| Bkup1 | FULL | TDPEXCC RESTORE db01 FULL /FROMEXCSERVER=MACHINE1 /ERASEEXISTINGLOGS=YES | |
| Bkup2 | INCR | TDPEXCC RESTORE db01 INCR /FROMEXCSERVER=MACHINE1 | |
| Bkup3 | INCR | TDPEXCC RESTORE db01 INCR /FROMEXCSERVER=MACHINE1 | |
| Bkup4 | INCR | TDPEXCC RESTORE db01 INCR /FROMEXCSERVER=MACHINE2 | |
| Bkup5 | INCR | TDPEXCC RESTORE db01 INCR /FROMEXCSERVER=MACHINE2 | |
| Bkup6 | INCR | TDPEXCC RESTORE db01 INCR /FROMEXCSERVER=MACHINE1 | |
| Bkup7 | INCR | TDPEXCC RESTORE db01 INCR /FROMEXCSERVER=MACHINE1 | |
| Bkup8 | INCR | TDPEXCC RESTORE db01 INCR /FROMEXCSERVER=MACHINE1 /RECOVER=APPLYALLLOGS |
It is recommended to always back up the same database from the same Exchange Server to avoid this type of cumbersome restore process when the log files do not exist within the backups for a specific/single Exchange Server.
It is important to understand that each INCREMENTAL backup of the log files is associated to the last FULL that was performed. In the following scenario, the intervening FULL on Machine-2 would limit the restore for Machine-1 to only be able to restore its FULL and the single INCR (Bkup2) that follows. Bkup6-Bkup8 would now be associated to the FULL (Bkup3) that was performed on Machine-2.
Machine-1 | Machine-2 | |
| Bkup1 | FULL | |
| Bkup2 | INCR | |
| Bkup3 | FULL | |
| Bkup4 | INCR | |
| Bkup5 | INCR | |
| Bkup6 | INCR | |
| Bkup7 | INCR | |
| Bkup8 | INCR |
If it is necessary to back up the same Exchange Server database on two different machines, it is suggested to use a COPY type backup on the second machine so that the log files will not be truncated.
Product Synonym
TSM DP
Was this topic helpful?
Document Information
Modified date:
17 June 2018
UID
swg21600153