SQL db Backup error

[cricketer1]

I have been getting problems when I try to backup my SQL Server database. Backup goes halfway and then stops with this error. Does anyone have any idea on how to tackle/resolve this, or where to start looking for clues.

---->
BackupMedium::ReportIoError: write failure on backup device 'E:\MSSQL\BACKUP\xxxx\xxxx_db_20031129.BAK'. Operating system error 33(The process cannot access the file because another process has locked a portion of the file.)
<----

Thanks

 

[johnv20]

Is there anything e.g virus scans running on the box when you're trying to do the backup ?

 

[cricketer1]

I don't think a virus scan may be the issue, because other db's on the same server backup just fine. It's just this one database which is giving me problems...any remedies?

 

[SQLBill]

How are you doing the backup? Are you using the SQL Server BACKUP commands or a third party tool?

-SQLBill

 

[cricketer1]

I used both, the regular SQL Server Backup from the Enterprise Manager and then the SQL Backup command. Both are not working crashing with the same error mid way....

I even tried it with SQL Agent off, but no success.

 

[caddywonkus]

I was looking for this exact thread.. having the same issue. Let's see if any of our conditions match:

Backing up a very large database (130 Gb... backup file is about 67 Gb) to a Windows-striped (R0) 2-disk volume, ntfs--compressed. Yes, I expect performance to [be really bad ;-)] doing that... but it has worked. Not reliably though. It's not antivirus, that's disabled (and it's setup to not scan .bak files in the first place anyway). It's not any other sql processes, the agent was disabled and I paused the server after beginning the backup process.

The only other variable in this is, the first time I created the backup with no problem. The next time, I tried creating a new one in a different location on the same disk. Compressed the backup file consumes 22 Gb. I have 44 Gb free after the first backup. The second one is when I get the error, and I can't get past it (and it takes nearly the full five hours before I find out it didn't get past it). If I delete the first one, it's ok.

I'm suspecting it's something to do with the underlying filesystem not being able to keep up with compressing the data as it's being spit out by SQL. Haven't had that happen before, but haven't had to deal with a 130 Gb database before, either.

Any experts with an under-the-hood view of the filesystem that might be able to confirm this?