Hi @kkenny, I see your point but there’s a difference between pushing effectively VSS commands to a VM then reading the blocks from the hypervisor level, to trying to pull the SQL data out of those blocks and write it back to the application, so these are different workflows hence the different operating requirements.
And, assuming you have support, you can go straight to Veeam’s enterprise-grade support
Just re-read and saw you said support sent you here. Do you have a support contract? If so then I’m assuming that they’ve suggested you go to the R&D forums to raise a feature request.
Hey, there is no straight forward answer to this issue. I have dealt with this error in the past. But the environment was not as complicated like you just described: https://techdirectarchive.com/2021/06/19/the-server-was-not-found-or-was-not-accessible-a-network-related-or-instance-specific-error-occurred-while-establishing-a-connection-to-sql-server/
Therefore, please follow these steps to troubleshoot. Having issues restoring backup in reverse! You may be having some connectivity issues.
- Since you have Named Pipe enabled, and can backup, I think you also do not have issues with SQL services. Do you have TCP/IP protocol enabled as well? From your description, you do not have issues with the SQL Server instance. But you can double check all these as this is a generic error message.
- Check to see if allow remote connections to this server is enabled. In SSMS, right click on the instance name and select Properties. Go to the Connections tab and make sure Allow remote connections to this server is checked
Not sure if you have taken a look at the logs already. Also you could use the Windows Event Logs. All Veeam activities are logged to the Windows Event viewer. You will find them under Applications and Log services. They should help pinpoint this issue more clearly.
In conclusion, I strongly think you are having some firewall (connectivity) issue.
Thanks for the replies guys.
@Iams3le I’ve double-checked those suggestions, everything is as expected. I considered a potential firewall issue as I spotted a port issue when running a similar SQL backup using PSDirect when the VMs were running in a 3rd DC, but in this case there is no firewall between the VBR servers and the Hyper-V cluster by design, despite being in different DCs (we’ve a private 100G fibre circuit between them and chose to use it to avoid firewall bottlenecks). Regarding event logs, unfortunately I can only seen entries for the backup when it runs, none for the restore attempt. Maybe the Veeam log files are better but again they don’t seem to change when I attempt a SQL restore. Maybe I’m looking at the wrong files.
@MicoolPaul You make a good point and I appreciate the difference having considered it more. It’s interesting to note that file-level restores are working when restored directly to the VM, which kind of supports your point re SQL data specifically.
I suspect that I was sent here by Veeam Support because they may have misinterpreted my query as a custom PowerShell issue, based on the language. I’m waiting for another response to clarify.
But I still strongly feel that if I can backup SQL data this way, the restore process should be similar, surely... because what’s the alternative? If I have to restore the entire VM or perform a file level restore, then I’d be better off with VBR Standard and skip all this hassle. I’m still hoping it’s something simple but I’m just not seeing it.
Also, I’m not sure why one of the responses above was voted as the ‘answer’ before I even read it.
Veeam Support have replied to my query. As it turns out, SQL restores via PSDirect are not supported. Disappointing.
See Considerations and Limitations > Restore section here:
https://helpcenter.veeam.com/docs/backup/explorers/vesql_considerations.html?ver=110
Veeam Support have replied to my query. As it turns out, SQL restores via PSDirect are not supported. Disappointing.
See Considerations and Limitations > Restore section here:
https://helpcenter.veeam.com/docs/backup/explorers/vesql_considerations.html?ver=110
Thank you very much for the information!