1

We have a problem with one of our databases that has FileStream enabled. When we try to backup, we get the error

Backup failed because there is a mismatch in file metadata for file 65537

When we do a DBCC, no errors get reported, DBCC CHECKDB ('MyDB', repair_allow_data_loss) also does not return any issues. Users are not experiencing any issues when accessing the database, it is only the back-up that is a problem.

We have tried copying data to other tables, etc. but nothing has helped yet. We have even tried 3rd party repair tools but nothing has delivered results.

This is a very big database and creating a new DB and migrating the data is not really an option (will probably take many days).

Does anybody have any ideas on how to fix this issue or suggestions on what we can try?

I am now investigating undoing the FileStream...

Thanks!

0

When we do a DBCC, no errors get reported, DBCC CHECKDB ('MyDB', repair_allow_data_loss) also does not return any issues

This is really interesting as DBCC should report errors if metadata is corrupted. Have you tried to run a DBCC CHECKCATALOG; ?

Backup failed because there is a mismatch in file metadata for file 65537

I know it sounds basic but have you checked what database does file 65537 belongs to? Make sure the DBCC CHECKDB and DBCC CHECKCATALOG are run against the good database. But judging from the fact that you have problems with your backups, I guess you are looking at the right database. Unless it would be msdb? Since backup sets are in msdb so when you do a backup it inserts rows in msdb also.

You should check Paul Randall's blog, he has a post on fixing metadata corruption without a backup : https://www.sqlskills.com/blogs/paul/disaster-recovery-101-fixing-metadata-corruption-without-a-backup/

Did you try to restore your backups to see if they are corrupted?

Do you have filestream enabled? From what I'm reading, file 65537 would be related to filestream.

https://www.sqlshack.com/sql-server-filestream-database-corruption-and-remediation/

There's also a great blog by Paul Randal on filestream you should check it out. https://www.sqlskills.com/blogs/paul/filestream-directory-structure/

-------------- EDITED for FileStream corruption -------------------------

You should check the answer on this question that explains what happens when Filestream is corrupted.

https://stackoverflow.com/questions/15302673/handle-sql-filestream-data-corruption-and-backup

And in the link on sqlshack, there are steps to recover a database from filestream corruption.

| improve this answer | |
  • Thanks for the response Danielle. Yes, I have tried DBCC CHECKCATALOG but it also did not report any errors. How do I find out what database file 65537 belongs too? Since I am try to backup a specific database I assumed it belonged to that DB. Is there perhaps system DBs I should also look at? – Johan Nov 20 at 6:52
  • You should definetely do a checkdb on msdb. This database is related to backups. Checking master couldn't hurt too and should be small and quick. See if you get any errors on those. – Danielle Paquette-Harvey Nov 20 at 15:31
  • I've been trying to figure out how to check the file 65537 but I'm having a hard time. What seems wierd to me is that I've found another post with the same question as you and the file number is exactly the same... stackoverflow.com/questions/23239549/sql-server-2012-msg-3286 – Danielle Paquette-Harvey Nov 20 at 15:37
  • @Johan Do you have Filestream enabled? 65537 seems to be related to filestream. I've added a link in my solution about filestream corruption. – Danielle Paquette-Harvey Nov 20 at 15:46
  • 1
    yes we do have FS enabled. The only way we could get rid of this error was to revert back to a non-FileStream database. I suspect something got corrupted when our client implemented FileStream in the first place. – Johan Nov 24 at 13:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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