Problem backing up SQL databases

[baskervi1]

About 3 weeks ago, my customer began a migration of their core application to another vendor. During the migration, Symantec Backup Exec has been failing on the database backups with the following error:

Backup
 Unable to attach to server2.SORD.LOCAL\MSSQLSERVER.

V-79-57344-33932 - Unable to attach to a resource.  Make sure that all selected resources exist and ...

I’ve verified I can create a local SQL backup with the same account that Backup Exec is using (and even tried the sa credentials), and I’ve verified TCP/IP (Port 1433) and Named Pipes are enabled in the configuration manager. Actually, the order is 1) Shared Memory , 2) TCP/IP, and 3) Named Pipes. The firewall service is enabled, but the firewall configuration is set to permit all traffic. IPv6 is enabled on both systems, and I’ve verified IPv6 connectivity.

Can you think of anything else? I’ve tried to get the vendors involved, but they have been directed internally not to help for liability reasons.

Thank you.

[CraigV]

Hi,

That error can occur if the resource is no longer available. If that SQL database was moved elsewhere, but BE hasn't been reconfigured, then it can happen.

If this is the case, do 1 of 2 things:

1. Deselect the SQL server instance on the server in question, and then reselect it. This will essentially refresh the selection list;

2. Put in an exclusion to ignore the database. Do this ONLY if the SQL database has been moved elsewhere, or even deleted. No sense excluding a database that you actually do need backed up.

Thanks!

[baskervi1]

Thanks for the input, CraigV. I've not only attempted to deselect the SQL server and reselect it, but I've also completely recreated the backup job from scratch, including readding the server to backup exec from scratch.

This database is for the core application, so we can't deselect it.

I create a backup account called 'sa' with the sa's password. Should this be sufficient to run a backup? It fails, but I don't know if someone I need to put in the sql instance for this account.

[CraigV]

Just make sure you have rights to SQL as per the TN below:

http://www.symantec.com/business/support/index?page=content&id=TECH23689

[baskervi1]

I did confirm within group policy that this user (the domain admin) has all correct settings.

[pkh]

IPv6 is enabled on both systems

Does the remote machine has both IPv5 and IPv6?  If so, disable IPv6.

If both machines are using IPv6 only, then go Network and Security in the job properties and select IPv6.  You tagged your post as BE 12.x.  I am not sure these older releases of BE support IPv6.

For your SQL databases, make sure that Windows authentication is enabled and just use the BESA to access the database.  You don't have to 'sa'.  Make sure that the BESA is a domain admin and it is added to the database as an admin.

[baskervi1]

I'll try to disable IPv6 tonight, but I did confirm that the servers can communicate with both IPv4 and IPv6. We have authentication set to mixed mode, and I've tried the Windows accounts as well as the sa. Neither work. 

I'm thinking we may have a problem with the sql installation. I tried to open the logs via management studio, and I received the error "Failed to retrieve data for this request.. An exception occurred while executing a Transact-SQL statement or batch.... A severe error occured on the current command. The results, if any, should be discarded." I don't have problem navigating around elsewhere in management studio.

[baskervi1]

I disabled IPv6 on both servers, and the test credentials still fail. BESA is a domain admin account, and it's been added to the database as an admin account previously. I double-checked this again.

[baskervi1]

I manually opened the errorlog files, and I don't see any problems in them.

[pkh]

Try running a backup using SQL Studio with the BESA.

[baskervi1]

The problem appears to be that connectivity fails when connecting to server2\instance. There is no problem just connecting to server2. When I try to connect to the server2 using management studio, I see server2 only, but for server1 I see server1\instance1 and server1\instance2. 

[CraigV · Accepted solution]

...try creating a new selection list and job (select the SQL server) and then run the job again. if this works, consider using this along with a new job as it would indicate possible corruption in the job/selection list.

Thanks!

[pkh · Accepted solution]

This is correct. Server 2 has only one instance so it is the default. You don't have to specify the instance, unlike Server 1 which has 2 instances

[baskervi1]

Pkh, I understant what you are saying, but I did a reinstallation of backup exec, and even after the reinstallation, backup exec somehow discovered server2\instance. Maybe there was some residual information on the server that the reinstallation picked up. I had come to the conclusion a couple days ago this was probably the problem (not needing the instance name), so I de-selected the instance but was concerned I was missing some data. Thanks

[baskervi1]

CraigV, I was trying to mark you as part of the solution as well, but the website only allowed me to select one - didn't realize this until after the fact. I appreciate your input, as it was very helpful.

[CraigV]

No worries...there would be the option to split the solution. You can ask an admin (Amy Johnson) to do this as they'd have the power.

Either way, glad you came right.

Thanks!

[pkh]

You can still split the solution to multiple answers.  Just clear the solution and use the procedure in my article below

https://www-secure.symantec.com/connect/articles/how-split-your-solution