SQL database backups fail error 4818, using sql agent

[Anne_Farrell]

We have just upgraded to 10.1 and are now using the SQL Agent to backup the databases. (Windows 2003 media server with BE10.1, Windows 2003 database server with SQL 2000 sp3)

When I create a new backup job, I can see the SQL databases on the remote server under the "Microsoft SQL Server" node of the selection list, and have selected (for now) just the master/model/msdb/distribution databases.

When I run the backup, it "completes with exceptions". The backup service account I use is a domain admin and a backup operator, and has a SQL login marking it as system administrator too. In the event log of the remote server is:

Event Type:Error
Event Source:Backup Exec
Event Category:None
Event ID:57860
Date:24/06/2006
Time:11:33:48
User:N/A
Computer:SERVERNAME
Description:
An error occurred while attempting to log in to the following server: "SERVERNAME".
SQL error number: "4818".
SQL error message: "Login failed for user 'MYDOMAIN\BackupAccount'.
".

For more information, click the following link:
http://eventlookup.veritas.com/eventlookup/EventLookup.jhtml
Data:
0000: 18 48 00 00 00 00 00 00 .H......
0008: 00 00 00 00 00 00 00 00 ........


In the job log "errors" section I get
Backup- SERVERNAME Database msdb was not found, or could not be accessed.

And in the "exceptions" sections I get
Backup- COPPER The item SERVERNAME\msdb in use - skipped.


I have also tried changing the login credentials to the SQL "sa" account, but this didn't help, although I don't get the eventlog entry on the remote server.

Thanks in advance

[Shilpa_pawar_2]

Hi,

Please refer these technotes:
http://support.veritas.com/docs/279955
http://support.veritas.com/docs/251942

NOTE : If we do not receive your reply within two business days, this post would be marked "assumed answered" and would be moved to "answered questions" pool.

[Anne_Farrell]

I have spoken to tech-support on the phone, and after two hours of him browsing the web while I was on hold was given the same document to try.

Re-registering the SQLVDI.DLL file has made no difference at all, and I do not believe it is a credentials problem because the same thing happens if I specify an SA account to connect to SQL. Also, the testing always works. Incidentally, logging on to the SQL server as the backup account works, and that account can manipulate the databases too.

Getting very frustrated now, because the ability to backup SQL was a primary reason to upgrade to BE with the SQL Agent.

As a side-note, backing up another SQL server works fine.

Thanks

[Ashutosh_Tamhan]

This error occurs due to insufficient rights of the logon account. You may
refer following technote:

http://support.veritas.com/docs/251942

Regards, Ashutosh NOTE : If we do not receive your reply within two business days, this post would be marked assumed answered and would be moved to answered questions pool.

[Anne_Farrell]

I'm not sure if you read my entire response to the last suggestion, but...

> I do not believe it is a credentials problem because the same thing happens if I
> specify an SA account to connect to SQL. Also, the testing always works.
> Incidentally, logging on to the SQL server as the backup account works, and
> that account can manipulate the databases too.

[Shilpa_pawar_2]

Hi,

Please refer the following:
If using SQL integrated security to perform an SQL backup or restore, the logon account assigned to the Windows server needs to have rights to back up or restore the SQL Server. No logon account should be assigned to the SQL Server selection in this case.

If using SQL security, a logon account with administrator privileges needs to be assigned to the Windows server selection, and a logon account with SQL credentials needs to be assigned the SQL selection.

Also refer: http://support.veritas.com/docs/234733

NOTE : If we do not receive your reply within two business days, this post would be marked "assumed answered" and would be moved to "answered questions" pool.

[Anne_Farrell]

Um, not sure how to put this, but as I said, this is not a security issue.

Anyway, I've found the resolution now, and a hotfix is available from MS. It appears to be something quirky to do with shared-memory on SQL and 64-bit editions of Windows.

http://support.microsoft.com/?kbid=913100

Didn't even require a reboot in my situation, nor did it interrupt services at all.