SQL Backup job says sucessful but really isn't running...

by swjohnson 10/7/2007 5:19:00 PM

My full and transaction log backups were running and reporting success but were actually failing.  We recently changed the SQL Server Service Account and rebooted the server. The original setup had the local system account and our standard is to use a domain account with the proper credentials so that we can automate the moving of files in our database domain.  We are running Windows 2003 Server with the latest security patches and SQL Server 2000 SP4.   

The SQL Server job runs under the SQL Server Agent account (which is a domain account that has proper permission as other jobs run successfully) was executing and saying that the job was running correctly but no files were appearing in their respective directories.  The backup job normally takes 30-40 minutes but was now finishing in record time--1 second!  However, I was getting an email from the Red Gate software that there were errors!

The SQL Server log file did not contain any errors and the the SQL Agent log file did not contain any errors either.  Even the Microsoft Event viewer was no help. 

So now I start down the poor man's debugger methodology...knowing that the job calls a stored procedure as it's first step, I decided to grab the code and see if I could execute the stored procedure directly and when I did, I got this error from the RedGate SQL Backup software:

ERRSQB: 5150 (Error opening mutex.) (Global\SQBMutex_): 5 (Access is denied.)

This would explain why I was getting the email saying that there were errors.  Inside the stored procedure I loop through each database and run the backup.  One of the Red Gate command is the OnError MailTo command and I had that setup to notify myself. 

After doing some digging, I stopped and restarted the SQLBackup service from Red Gate and it started working correctly.  Not sure why but my hunch is that even though we change the startup account, rebooted the server and the SQL Server service started with the new domain account, the SQLBackup service needed to do something permission wise with the new startup account in order for it to work correctly.


Calendar

<<  December 2008  >>
MoTuWeThFrSaSu
24252627282930
1234567
891011121314
15161718192021
22232425262728
2930311234

View posts in large calendar