Forum Discussion

baskervi1's avatar
baskervi1
Level 3
12 years ago

Problem backing up SQL databases

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 are online, and then try again.  If the server or resource no longer exists, remove it from the selection list. Edit the selection list properties, click the View Selection Details tab, and then remove the resource.

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.

12.x and Earlier
Backing Up
Backup and Recovery
Backup Exec
Windows Server (2003-2008)
  • CraigV's avatar
    CraigV
    12 years ago

    ...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's avatar
    pkh
    12 years ago
    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
  • CraigV's avatar
    CraigV
    Moderator
    12 years ago

    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's avatar
    baskervi1
    Level 3
    12 years ago

    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's avatar
    CraigV
    Moderator
    12 years ago

    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's avatar
    baskervi1
    Level 3
    12 years ago

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

  • pkh's avatar
    pkh
    Moderator
    12 years ago

    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's avatar
    baskervi1
    Level 3
    12 years ago

    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's avatar
    baskervi1
    Level 3
    12 years ago

    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's avatar
    baskervi1
    Level 3
    12 years ago

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

  • pkh's avatar
    pkh
    Moderator
    12 years ago

    Try running a backup using SQL Studio with the BESA.

  • baskervi1's avatar
    baskervi1
    Level 3
    12 years ago

    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.