3

We have DatabaseA that has filestream files in it. We then have an archive process which first deletes files in DatabaseB (different server) and then inserts new files from DatabaseA into DatabaseB via SSIS.

Each night we try to backup the database and we get the following error:

The operating system returned the error '1392 (The file or directory is corrupted and unreadable.)' while attempting 'FindNextFile' on \foldername guid. [SQLSTATE 42000] (Error 3634) BACKUP DATABASE is terminating abnormally. [SQLSTATE 42000] (Error 3013). The step failed.

When I look at the file path and folder name, the name is not the same as the folder name guid reported in the error. When we reorganize the index on the filestream guid column, we are able to backup the database. How do we recover from this corruption? DBCC checkdb? Is there something else we should be doing with filestream enabled database backups or the way that we are deleting the rows with the filestream column?

We are using native SQL Server

Backup command:

BACKUP DATABASE to disk = '\share\backupshare\databasename\databasename.bak' with noformat, init, name='databasename-full database backup', skip, norewind, nounload, compression, stats 10, checksum

Improve this question
1
  • How do you reorganize index?
    – Saeed Neamati
    Sep 16, 2015 at 5:29

1 Answer 1

Reset to default
1

FindNextFile is a Windows API call, so what's happening is the backup process is enumerating all the files in the FILESTREAM folder and backing them up. The error message indicates that the operating system cannot read the file system; this indicates, at least to me, that the file/folder structure on disk is corrupt. There would be a different error returned if the file/folder was simply not found. This may mean the I/O subsystem has problems. I would run chkdsk in Windows on that volume.

From the DBCC CHECKDB documentation, it doesn't look like FILESTREAM checks go beyond ensuring there is linkage between the database and the file system. Running chkdsk has the ability to do a low-level check of the disk contents itself, which is probably what's needed in this scenario. It certainly wouldn't hurt to run CHECKDB on the database anyway (read: regularly) either.

Improve this answer
5
  • I'm getting errors on the checkdb: Msg 3634, Level 16, State 1, Line 1 The operating system returned the error '1392(The file or directory is corrupted and unreadable.)' while attempting 'FindNextFile' on 'directory:\folder\FileStream\guid\guid. DBCC results for 'databasename'. Warning: Could not complete filestream consistency checks due to an operating system error. Any consistency errors found in the filestream subsystem will be silenced. Please refer to other errors for more information. This condition is likely transient; try rerunning the command.
    – user1984236
    Jan 17, 2013 at 21:34
  • @user1984236: Run CHECKDB again; if you still get the same error, run chkdsk on the volume.
    – Jon Seigel
    Jan 17, 2013 at 23:37
  • We ran chkdsk and we did indeed have corruption. Windows admins are fixing. Thanks Jon!
    – user1984236
    Jan 18, 2013 at 4:12
  • @user1984236: You're welcome. You'll want to have your team examine every volume on that same physical device in case it's a hardware issue.
    – Jon Seigel
    Jan 18, 2013 at 14:30
  • Is there a way to ignore files like this? I'm working on a news database. I won't mind if even 10% of data is lost. I need to backup the database and I can't make it work, because of these errors.
    – Saeed Neamati
    Sep 16, 2015 at 5:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.