1

RESTORE VERIFYONLY and RESTORE DATABASE always fail immediately with this error:

Msg 3241, Level 16, State 201, Line 1
The media family on device '' is incorrectly formed. SQL Server cannot process this media family.
Msg 3013, Level 16, State 1, Line 1
VERIFY DATABASE is terminating abnormally.

The database is running with Simple recovery model and all our backup attempts are FULL backups.

DBCC CHECKDB (TheCure_CDR) is completely clean.

The BACKUP DATABASE succeeds every time. We’ve backed it up locally, remotely, single file, multi-file, with INIT, with NOINIT, and many other permutations.

RESTORE HEADERONLY succeeds every time and generates information consistent with the BACKUP DATABASE command

We’ve tried RESTORE VERIFYONLY and RESTORE DATABASE on the same computer where the backup was taken and on a different computer running the exact same version of SQL Server. This is the version:

Microsoft SQL Server 2014 (SP2-CU4) (KB4010394) - 12.0.5540.0 (X64)
Jan 27 2017 03:40:25
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.2 (Build 9200: ) >(Hypervisor)

A couple notable properties of our database and the circumstances:

  1. The database has a defunct file group that we cannot remove. It’s been that way for years and we’ve backed up and restored many times.

  2. The database has memory file groups and one memory optimized table. Again we’ve backed up and restored many times since this became the case.

  3. The problem started at about the same time we upgraded the database from SP2 to SP2-CU4

  4. We’ve scoured KBs and forums and have not found a single article directly on point where:

    • The database is uncorrupted
    • The backup is repeatable and always succeeds
    • The restore is on the same server where the backup was taken
    • RESTORE HEADERONLY always succeeds
    • RESTORE VERIFYONLY always fails

Has anyone seen this before?

  • Does RESTORE FILELISTONLY work? – Max Vernon Apr 7 '17 at 20:43
  • What do you mean about it having a defunct filegroup? And why can't you remove it? Is it a real filegroup? Or just a ghost one that shows up in the list, but doesn't correspond to any actual files or data? Just wondering if your upgraded version simply has more checks for invalid stuff like this. – BradC Apr 7 '17 at 20:47
  • I think this is covered when you mentioned backing up with INIT and NOINIT, but have you tried running a backup to a new media set? (Check the second tab in the backup database GUI) – RDFozz Apr 7 '17 at 22:16
  • @rdfozz - "We’ve backed it up locally, remotely, single file, multi-file, with INIT, with NOINIT, and many other permutations." – Max Vernon Apr 7 '17 at 23:00
  • @MaxVernon - Yeah, I saw that - however, a new media set hadn't been specifically mentioned, and sounded like it could be relevant. I'd always rather ask an obvious question than assume I know the answer and turn out to be wrong. – RDFozz Apr 8 '17 at 0:22

Your Answer

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

Browse other questions tagged or ask your own question.