RESTORE VERIFYONLY Fails: Reached the End of the File (Error 3203)

October 2, 2026

–

RESTORE VERIFYONLY reports Msg 3203, “Reached the end of the file”, on a backup. Check which file SQL Server is reading, then validate an intact copy before trying the restore again.

⚡Confirm the exact file named by the failing command. In this reproduction, RESTORE VERIFYONLY returned Msg 3203 on the truncated copy; RESTORE DATABASE returned Msg 3287 instead. Compare a copied file with a known-good source, and do not overwrite a good backup with the failing copy.

The exact Msg 3203 from RESTORE VERIFYONLY

Msg 3203 · Level 16 · State 1

Read on "D:\SQLLab\Lab1009_3203\Lab1009_3203.bak" failed: 38(Reached the end of the file.)

Why VERIFYONLY reached the end of the file

SQL Server reached the end of the backup file while reading the backup set. In this reproduction, the file had been truncated to half its original size. RESTORE FILELISTONLY still returned both logical files, but that showed only that the header was readable, not that the backup data was complete.

RESTORE VERIFYONLY against the truncated backupexample output

Msg 3203, Level 16, State 1, Server HPAI01, Line 1 Read on "D:\SQLLab\Lab1009_3203\Lab1009_3203.bak" failed: 38(Reached the end of the file.) Msg 3013, Level 16, State 1, Server HPAI01, Line 1 VERIFY DATABASE is terminating abnormally.

A fresh control backup of the same database passed RESTORE VERIFYONLY and reported that the backup set was valid.

Check the exact backup file

Start by confirming the full path in the failing command. A readable file list is not a completeness check. Run VERIFYONLY against the exact copy you intend to restore:

RESTORE VERIFYONLY
FROM DISK = N'D:\Backup\YourDatabase.bak';

If this is a copied backup, compare it with the source and obtain a fresh copy from a known-good source if it is incomplete. If you can create a new backup, verify that file before using it for the restore. Do not replace or overwrite a good backup with the failing copy.

For the command syntax and options, see Microsoft Docs: RESTORE VERIFYONLY (Transact-SQL).

RESTORE DATABASE returned a different error

In the same HPAI01 test, RESTORE DATABASE against the same truncated file returned Msg 3287, then Msg 3013. The captured Msg 3203 above came from VERIFYONLY. Keep that distinction: this test does not show that every damaged backup returns 3203 during a direct restore.

Frequently Asked Questions

Does RESTORE FILELISTONLY prove the backup is complete?

No. In this test it returned the logical file entries even though the backup had been truncated. That output did not prove the backup data was complete.

Will RESTORE DATABASE return Msg 3203 too?

Not in this reproduction. VERIFYONLY returned 3203; RESTORE DATABASE returned 3287 and 3013 on the same SQL Server 2025 CU8 instance.

Does this prove the source database is damaged?

No. The captured failure was while reading the backup file. The lab’s fresh control backup passed VERIFYONLY.

Which message should I troubleshoot first, Msg 3203 or Msg 3013?

Start with the first specific error from the operation that failed. Here Msg 3203 describes the file read failure; Msg 3013 reports that the restore operation is terminating. In the separate direct-restore attempt on the same file, the specific error was Msg 3287, followed by 3013.

Where To Go Next

Follow the message from the operation that failed, not only the final 3013 line.