Options

SQL Backup 4.5 job attempting to create file twice

shawnnwfshawnnwf Posts: 16
edited July 26, 2007 11:39AM in SQL Backup Previous Versions
I have a transactional log backup job running every 2 hours on my FULL recovery databases. There are only two on this particular server. On one of the databases I get the error.

7/17/2007 6:15:00 AM: Error 510: Backup file exists. Will not overwrite. File name: (\\share\sqlbackups\server\MyDB_20070717_061500.sqb)

It is creating the backup file before processing the databases, then attempting to create it again. On the times where it succeeds, I see that two files are there for the database. I cannot figure out why it is creating two files. This is the same code used on other servers and it never has functioned like this.

I have tested the cursor that is being used to gather which databases to backup and the DB in question only gets listed once. I am not sure what else to test at this point. Any help would be appreciated.
· Share on Twitter

Comments

  • Options
    shawnnwfshawnnwf Posts: 16
    I upgraded the components from 4.5 to 4.6 in hopes that this would fix the problem, but it did not. The job works fine when I manually run it or if I run the T SQL from the step of the job in a query window.

    This only happens when the agent runs the job. I am out of ideas.
    · Share on Twitter
  • Options
    shawnnwfshawnnwf Posts: 16
    I have now deleted the job and created a new one with a new schedule that mimics the old job. The same issue is still happening with the backups on this server.

    The files seems to be just a few seconds off from each other (when they work) and exactly the same when the backup fails. The funny thing is that this is only happening with one of the databases of the two that are in Full recovery mode.
    · Share on Twitter
  • Options
    shawnnwfshawnnwf Posts: 16
    Just in case this happens to anyone else, the issue has been resolved. The server in question was a clustered server, and after the cluster was rolled, the issue disappeared.

    I believe there was a sort of 'ghost' job running that could not be seen in MSDB or the agent and was causing the issue.
    · Share on Twitter
Sign In or Register to comment.