A lot has been said in the Exchange community about the decision by Microsoft to remove (or not provide) Exchange Server 2007 awareness from the built-in backup utility shipped with Windows Server 2007. The MS Exchange Team blog explains that a little here :
About 2 years ago, when the Exchange team started testing Exchange 2007 on Windows 2008, we found that the built-in backup application had changed dramatically. Decisions that drove that change by the Windows team are not the subject of this post, but it is fair to say that the Windows team did not make the decision lightly.
When we evaluated the features of Windows Server Backup, it was clear that the backup and restore experience on Windows 2008 would not be the experience that existing Exchange customers have been used to for so long. Because we had feedback from several customers who told us they would rather get a more full-featured backup solution for their Exchange servers, a decision was made not to provide an Exchange-aware backup solution for Windows 2008 in Exchange 2007 Service Pack 1.
This week they announced the following:
Although we can’t share all of the details now, we thought that this issue was important enough to announce a decision we recently made. We have decided to develop and release a VSS-based plug-in for Windows Server Backup that will enable you to properly backup and restore Exchange 2007 with a built-in Windows 2008 backup application.
This is good news for Exchange customers looking for inexpensive backup solutions. I’m a bit curious though about this statement:
While you will be able to backup and restore Exchange 2007 on Windows 2008, you should not expect feature parity with the Windows 2003 NTBackup experience. There will not be the same level granularity and control that NTBackup provides and backups will be limited to the local server only.
NT Backup was about as featureless as you could get when it comes to Exchange backups, so I don’t quite understand how you can take a step backward from that. It will be interesting to see the result when it ships thats for sure.
Exchange Server 2007 has some very useful replication features such as Local Continuous Replication (in RTM and SP1) and Standby Continuous Replication (in SP1 only). These features can provide nice and simple disaster recovery options by replicating your storage group logs and databases to another location, be it another disk/LUN with LCR or another mailbox server with SCR.
However, if you choose to implement LCR or SCR you should be aware of the implications for your backups. A normal Exchange backup will truncate the transaction logs for your storage group, however when LCR or SCR are deployed this truncation may not work as you first expect.
One example of this is when using SCR to replicate your storage group to another mailbox server. The source mailbox server ships each transaction log to the SCR target where it is replayed into a replica of the database. In this scenario there are two queues created - the copy queue and the replay queue.
[PS] C:>Get-StorageGroupCopyStatus -StandbyMachine SERVER2
Name SummaryCopySt CopyQueueLeng ReplayQueueL LastInspecte
atus th ength dLogTime
—- ————- ————- ———— ————
First Storage Group Healthy 2 3232 25/04/200…Â
The copy queue length is the number of transaction log files yet to be shipped to the standby server. The replay queue length is the number of transaction log files yet to be replayed into the replica database (in this case the default 24 hour replay delay has been used).
Now that the source server knows it is shipping logs to a standby server it will be sure not to remove any transaction logs that are yet to be shipped. This would mean that if replication is suspended or fails for any particular reason, and the copy queue length begins to grow quite long, that the source server will not truncate the logs during a normal backup.
However, even when SCR appears healthy and has a zero length copy queue there may be problems with the RPC calls between the servers to notify of log truncation events. If the source and target cannot verify with each other that the logs have shipped and replayed then the source server will not truncate the logs during a normal backup.
To monitor for these types of scenarios it is wise to check for MSExchangeRepl warnings and errors on the target server. For example:
Event Type:Â Â Â Warning
Event Source:Â Â Â MSExchangeRepl
Event Category:Â Â Â Service
Event ID:Â Â Â 2137
Date:Â Â Â Â Â Â Â 19/02/2008
Time:Â Â Â Â Â Â Â 6:31:25 AM
User:Â Â Â Â Â Â Â N/A
Computer:Â Â Â SERVER2
Description:
Log truncation request to the Information Store using RPC has failed for storage group ‘SERVER1\First Storage Group’. Error code: 4294966264.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
When such SCR issues are interfering with backup operations one of the simplest ways to resolve the issue is to reseed the SCR target.
[PS] C:\>Suspend-StorageGroupCopy “SERVER1\First Storage Group” -StandbyMachine
SERVER2
[PS] C:\>Update-StorageGroupCopy “SERVER1\First Storage Group” -StandbyMachine
SERVER2 -DeleteExistingFiles
[PS] C:\>Resume-StorageGroupCopy “SERVER1\First Storage Group” -StandbyMachine
SERVER2
In the near future I’d like to nail down some more specific scenarios, causes and remedies, but for now I’ll just summarise by saying if you are having backup problems in an environment where LCR or SCR are deployed, look to your event logs for MSExchangeRepl errors and consider reseeding your replicas to get your backups behaving normally again.
After upgrading your Exchange Server 2007 system to Service Pack 1 you may experience Backup Exec job failures for your Exchange backups. The following error may appear in your Backup Exec job logs.
Unable to complete the operation for the selected resource using the specified options. The following error was returned when opening the Exchange Database file: ‘-514 The version of the log file is not compatible with the ESE version. ‘
Symantec has detailed the cause of the issue here.
The above error is reported if the version of the ESE.DLL on the Backup Exec server is different from the one on the Exchange 2007 server. This occurs in the event that the Exchange 2007 server has been patched to recent updates like Service Packs/ Rollup Patches for Exchange but the same Service Packs/Rollup Patches have not been applied to the Exchange 2007 Management Tools installed on the Backup Exec server.
To resolve the issue simply update the Exchange Server 2007 management tools on your Backup Exec server by running the Exchange Server 2007 SP1 setup on the server. Note: if your Backup Exec server runs on 32-bit Windows you will need to download the 32-bit version of Exchange Server 2007 to run the management tools install.
I’ve performed this update on a production system and found the backup job begins working again without requiring a restart of any services on either of the Backup Exec or the Exchange Server 2007 servers.
On a Symantec Backup Exec 11d server that is backing up Microsoft SQL Server databases you may encounter failed backups with an error:
The path for this database is invalid because it contains extra backslash characters. You must remove the extra backslash characters before the database can be backed up.
The solution provided by Symantec is here, and references instructions from Microsoft here on detaching and reattaching the database with the correct path.
In some cases the database in question will actually be the Symantec Backup Exec database created by the installation. The database is usually named “BEDB”. In these cases you may follow the instructions above, and then find that the problem returns after the next backup is run. In the case I worked on no matter how many times I detached and reattached the database to remove the extra backslashes in the paths, the problem would return.
I found the solution to be a registry change on the Symantec Backup Exec server. In the registry key HKLM\SOFTWARE\Symantec\Backup Exec For Windows\BEDatabase look for the values “Server Database Path” and “Server Database Log Path“. If these values have trailing backslashes like so:
“Server Database Path”=”E:\Microsoft SQL Server\MSSQL\Data\”
“Server Database Log Path”=”D:\Microsoft SQL Server\MSSQL\Data\”
then remove them so that they appear like this instead:
“Server Database Path”=”E:\Microsoft SQL Server\MSSQL\Data”
“Server Database Log Path”=”D:\Microsoft SQL Server\MSSQL\Data”
You should now find that the documented solution from Symantec works properly.
