Change Request: Unmounting procedure Tmp-DB Staging Server

[u19208]

Hi Veeamions,

I was asked to start a new Topic by the Veeam Support Team regarding my Case # 03070769 to report a feature or change request, which is:
I'd suggest to change the procedure of unmounting and deleting the temporary Veeam-Database on a SQL-staging server in order to prevent "orphaned" databases missing its .mdf-files.

Reason is we had some trouble to remove a VeeamTmp%timestamp%-Database from one of our SQL-Servers, because Veeam failed to remove it completely after a restore attempt of Sharepoint-Items.
So, what happened is that after closing the Veeam-Sharepoint-Explorer the temporary Veeam-Database was not completely removed, as it claimed in the logs that there happened to be some network-errors (which we didn't realize during that time anyway...) and this obviously led to the strange situation, that the mdf File in the C:\VeeamFLR\....-Folder was deleted - but not the database (configuration) itself, which still showed up in the SQL-Servermanagement-Studio.
It was not possible anymore to detach, take offline, remove or delete that (no longer existing) database from the sql-instance of that server. This led to various errors on integrity checks, attempts to remove showed up severity24-Alerts or Error 823.
So the only change to get rid of that was to restore (any) db into the invalid veeamtmp...-DB and creating the .mdf file in the veeamflr\-Folder to have a consistent db again, before we've finally been able to delete it. The problem was obviously, that managing this db was no longer possible since its db-files got lost/deleted by veeam in a way to early.

Therefore I'd like to ask: Why not unmounting/deleting the veeamtmp-db from ssms first, and only after the complete success of that action the files on the filesystems can be purged as well?
Veeams seems to do this the other way round, at least in our case, so you'll run into trouble when the process is interrupted.

In other cases we didn't encounter a problem like this, but connection problems can never be ruled out, so changing the behaviour would avoid some trouble here.

Thanks.

J.

[Gostev]

Hi, I checked with the responsible developers and it appears that exception handling has already been improved in U4 to prevent "orphaned" databases. Previously, they were basically ignored, with VESP application continuing to shut down. This should no longer be the case - any database detaching issues will immediately cancel application shutdown. Thanks!