SQL Server Error 3203

Error number

3203

Severity

16 (user-correctable error)

State

Not documented by Microsoft (not reproduced here)

Product

Microsoft SQL Server Database Engine

Versions

All supported SQL Server versions (2016 to 2025), Azure SQL Managed Instance

Category

Backup & Restore

Last reviewed

24 October 2026

What it means

Error 3203 means SQL Server opened the backup file but could not read all of it, usually because the file is incomplete, damaged in transit or stored on failing media.

The message has two parts. The quoted text is the backup device (file path, share or URL) that SQL Server was reading, and after failed: comes the Windows error number and its text. That second part tells you which problem you have: 38 (Reached the end of the file) means the file is shorter than the backup it describes, typically an unfinished copy or download; 13 (The data is invalid) means the bytes are not what the backup format expects; 23 or 1117 are read errors from the disk, controller or network path.

Unlike error 3201, the file was found and opened, so the path and permissions are fine. Unlike error 3241, which is about a file that is not a valid backup at all, 3203 happens while reading the data. The statement then ends with error 3013. The catalogue severity is 16; the state is not documented by Microsoft.

Common causes

• The backup file was copied, uploaded or downloaded only partly (an interrupted copy, a full disk at the destination, a size limit on the transfer), so it ends early (error 38).
• The file was altered in transit, for example by an FTP transfer in text (ASCII) mode or by a tool that rewrites line endings (error 13).
• The disk, storage array, USB drive or network share holding the backup returns read errors (errors 23 or 1117).
• The backup was written to failing media in the first place; without WITH CHECKSUM on the backup this goes unnoticed until the restore.
• Restoring from a file that another process is still writing, such as a backup or copy that has not finished yet.

Diagnose it

Read-only These queries only read metadata and dynamic management views. They do not change data, permissions or configuration, so they are safe to run first.

SELECT TOP (20) bs.database_name, bs.backup_finish_date, bs.type,
       bs.backup_size, bs.compressed_backup_size,
       bs.has_backup_checksums, bs.is_damaged, mf.physical_device_name
FROM msdb.dbo.backupset AS bs
JOIN msdb.dbo.backupmediafamily AS mf ON mf.media_set_id = bs.media_set_id
ORDER BY bs.backup_finish_date DESC;

DECLARE @folder nvarchar(4000) = CAST(SERVERPROPERTY('InstanceDefaultBackupPath') AS nvarchar(4000));
SELECT full_filesystem_path, size_in_bytes, last_write_time
FROM sys.dm_os_enumerate_filesystem(@folder, N'*.bak');

EXEC sp_readerrorlog 0, 1, N'BackupIoRequest';
EXEC sp_readerrorlog 0, 1, N'3203';

How to fix it

Each fix is labelled with what it changes. Try read-only checks and the least invasive fix first, and test changes outside production.

BACKUP DATABASE AppDb
TO DISK = N'D:\Backups\AppDb_copy.bak'
WITH COPY_ONLY, CHECKSUM, COMPRESSION;

RESTORE VERIFYONLY FROM DISK = N'D:\Backups\AppDb_copy.bak' WITH CHECKSUM;

RESTORE DATABASE AppDb_Salvage
FROM DISK = N'D:\Backups\AppDb.bak'
WITH CONTINUE_AFTER_ERROR,
     MOVE N'AppDb'     TO N'D:\SQLData\AppDb_Salvage.mdf',
     MOVE N'AppDb_log' TO N'D:\SQLLogs\AppDb_Salvage_log.ldf';

Examples

Restoring from a backup copy that ended early

Shown as documented, not reproduced here: it needs a truncated or damaged backup file. The text after failed: depends on the operating system error; the state is not documented by Microsoft, so no header is shown.

RESTORE DATABASE AppDb
FROM DISK = N'D:\Backups\AppDb.bak'   -- copied from another server, copy was interrupted
WITH REPLACE;

Read on "D:\Backups\AppDb.bak" failed: 38(Reached the end of the file.)
RESTORE DATABASE is terminating abnormally.

How to prevent it

Back up WITH CHECKSUM, and verify every copy you rely on with RESTORE VERIFYONLY ... WITH CHECKSUM after it reaches its final location, not only where it was written. When moving backups between servers, compare file sizes or hashes before deleting the source.

Test restores regularly on another server. A restore that has worked recently is the only real proof that a backup file is readable end to end.

Common questions

Learn more on CodeWithSQL

• Working with large databases

Official documentation

• Possible media errors during backup and restore (SQL Server)
• RESTORE VERIFYONLY (Transact-SQL)
• Database Engine events and errors 3000 to 3999

Last technically reviewed 24 October 2026; examples and diagnostics run on SQL Server 2025 (17.0.1145.4). Message text checked against the engine's sys.messages catalogue.