Drop DB on a restored test server from SQL Always On Availability Group in production

Not sure if this pertains to the issue as I don’t do many SQL restores with Veeam but was this step available when you were doing the restore - Step 7. Specify Recovery State - Veeam Backup Explorers Guide

It says if you chose an Always On group in a previous step these are not available and might be a possible cause to the issue for dropping the DB.

I would say to do the usual check the logs and if needed open a support case at which time you can also post on the Forums - https://forums.veeam.com 

I’m doing Instant Recovery so those options are not available. I’m retrying right now but if it fails again, I will go use the other option of Restore Database. Thanks.

If you are using Instant Recovery, then check here - How It Works - Veeam Backup Explorers Guide

It was not pointed out in the OP, so I just assumed restore option.

The Instant DB Restore does not seem to be working. It is not updating the statistics for a couple of hours now. Also, it did not create any restore log folder. So pretty sure it is restoring, not doing anything. I opened a ticket to Veeam but a couple of their Engineers advised against stopping the process.

Thinking of just doing a Instant VM recovery ( approx 50TB server). The backup is a Storage Snapshot so this should be a lot faster using a native Veeam backup. Also, at least the DBA can sign it and check, reconfigure while restore is being done in the background. 

Assuming VMware virtualization, can you create a sandbox network similar to production but with no uplinks to production, and then restore your DC(s) and SQL servers in that sandbox so that it can’t connect to and interfere with production?  Once that is up, I’d copy the SQL database over to a different virtual disk and then disconnect that disk and connect it to the test server.  There may be a more elegant way to do things, but I haven’t much experience with restoring to an always-on SQL cluster, so that’s about the best I can do.

We encountered some issues with the Instant DB Restore. Connection to several disks were gone, sample error: C:\VeeamFLR\SERVER_c45cfdab\Volume4\UserDB\DBName.mdf.  The system cannot find the file specified.  

Had to restart the mount service to be able to continue the Instant DB Restore. Then when it’s time to do switchover, we got the error unable to switchover due to illegal character in the path. Veeam unable to determine where the issue was and we got to do a manual switchover on the SQL side. So the Instant Database Restore was left in a hung / unknown / still running state. We decided not to clear this unsuccessful restore job since Veeam was not 100% sure what would happen if we force stop the job. So at this point the priority was to make sure that the DB that was brought up was stable and it was stable till the VBR server was rebooted (due to maintenance patching) and the the hung restore job went back several days prior to the switchover causing several days of data lost. Good thing we already started backing up but it was still several painful hours of doing an Instant VM restore this time and trying to recover several hours of lost data that was in the the DB that got reverted back.

Lesson learned, that let your DB grow into unmanageable size. Instant VM Restore is a lot more reliable than doing Instant Database Restore (which is new in V12 and I think still has a lot of issues).