Surebackup and working through errors

[DaveWatkins]

Hi

I'm working through setting up SureBackup for our major systems and currently am stuck on our SQL servers.

The job bring up come DC's that come up fine and the first SQL server is fine, but the second SQL server fails the SQL script test and reports this in the log

Error Database <database> can't be accessed. Execution of the query 'use [<database>]' failed with the error: -2147217900 Database '<database>' cannot be opened due to inaccessible files or insufficient memory or disk space. See the SQL Server errorlog for details.

Initially I thought this was because I had limited the VM's memory in the Application Group but putting that back to 100% and the error persists. The disks should have plenty of space available as the running server itself right now does.

I tried ticking the box telling SureBackup to leave the Application Group running but that doesn't work, seemingly if SureBackup runs into an error it ignores that box.

How can I determine the cause of this issue without being able to keep the Application Group running?

Thanks
Dave

[Andreas Neufert]

For your tests:
you can untick the SQL tests and allow the VM to boot (keep it running).
Copy manually the vbs script from the Veeam Server an run it there. That way you can maybe see what happening there.

Based on google search there is a chance that something is not OK with the database or the configuration.
https://www.google.de/?gws_rd=ssl#safe= ... disk+space

The first hit http://sqltrends.blogspot.de/2013/03/da ... ue-to.html
looks interessting and I would test this within the Virtual Lab.

[JoshuaPostSAMC]

Also, after the job fails, if you look at the history, you can right click on SQL2 and select Start and it will restart the application group and only that VM and should keep it running even after it fails so you can look.

I've had good luck with stand-along SQL servers testing properly, but my Always On SQL servers can't tell they are in a cluster properly in the SureBackup environment and all of the databases sit in "Recovery Pending" mode, so I just check to make sure the SQL port is available and not do the full script. If we had to restore them, we would have to remove them from Always On and start the databases independently. Some day I'll take a closer look at it.

[DaveWatkins]

Thanks for that Joshua, these are Always On servers but they start up fine and the logs indicate most instances pass fully without issue, it's just a couple of DB's on this server and a different error on the other Always On server that I haven't started chasing yet but dn't expect it to be a problem. I'm not sure powering up just the SQL server will work as it will need DC's running to start it's services but I'll have a play

[JoshuaPostSAMC]

Are your DCs and the SQL server all part of the application group, or do you have the DCs as the application group and the SQL servers are part of a linked job that starts them?

if the SQL are part of a linked job, then clicking to Start one of the SQL VMs will automatically start the Application Group servers and everything keeps running, even if the SQL VM fails so you can troubleshoot.

[DaveWatkins]

They are all the same App group. I haven't looked at linked jobs yet.

I'll have a play

Thanks

[DaveWatkins]

So this looks like it's related to Always On after all. Oddly some of the instances come up and validate fine, others do not. There doesn't seem to be any config difference between the two that I've found so far so am a little lost here. I may just make sure the ports are open and the services are running and be done with it, but it sure would be nice to be able to confirm the DB's are up and running