Exchange 2010 DAG Update Database Copy – Hresult: 0x50d. Error: A database backup is already in progress.
I came back from Hol’s today to an odd issue with one of my production database copies (2010 x 3 node DAG). Whilst I was away there has been a slight incident in one of our data centres which resulted in a failover between DAG nodes. Whereas service was restored quickly – one specific database's copy failed.
My team had tried to resume the database copy and also tried to update the database copy with the delete existing files option – but each time they did, the following error message would be presented to them:
The attempt to seed database '<DB NAME>' from the active copy on server '<DBX-1>' to the copy on server '<DBX-2>' failed: Microsoft.Exchange.Cluster.Replay.FailedToOpenBackupFileHandleException: Couldn't open backup file handle for database '<DB NAME>' to server '<DBX-1>'. Hresult: 0x50d. Error: A database backup is already in progress. Please verify that no other seeding or incremental reseeding operations are started for this database, and then try the operation again by rerunning the Update-MailboxDatabaseCopy cmdlet. At Microsoft.Exchange.Cluster.Replay.SafeBackupContextHandle.GetAndSetIntPtrInCER(String serverName, String dbName, String transferAddress, SafeBackupContextHandle& backupHandle) at Microsoft.Exchange.Cluster.Replay.EseDatabaseBackupReader.GetESEDatabaseBackupReader(String serverName, String dbName, Guid dbGuid, String transferAddress, String sourceFileToBackupFullPath, UInt32 readHintSizeBytes) at Microsoft.Exchange.Cluster.Replay.SeedDatabaseFileRequest.OpenSeedStreamer(Guid dbGuid, UInt32 readHintSize, Int64& initialFileSizeBytes) at Microsoft.Exchange.Cluster.Replay.SeedDatabaseFileRequest.Execute()
My suspicions were immediately drawn to the segment of the error ‘Couldn't open backup file handle for database’ whereas there was no specific backup software on the server, there was a Backup Exec agent. I stopped the agent on the server and then attempted the Update Mailbox command again – and this time around it the update processed correctly.
So if you should come across this scenario in your own environments, have a look at any running backups – or backup related services which might be interfering with the operation.