Troubleshooting Guide: SQL Server Error 3203 — “Read on “%ls” failed: %ls”
Why This Error Happens
Error 3203 occurs when SQL Server 2025 encounters an I/O failure while reading a backup device during a RESTORE or BACKUP verification operation. This is typically caused by a corrupted or truncated backup file, a backup device that is inaccessible due to permissions issues (especially with the SQL Server service account), or an interrupted connection to a network share/UNC path hosting the backup file. It can also occur when the backup media was written by an incompatible version of SQL Server or was prematurely terminated during the original backup job.
Step-by-Step Resolution Guide
Step 1: Verify File Accessibility and Permissions
- Confirm the backup file path exists and is reachable from the SQL Server host (e.g.,
D:\Backups\MyDatabase.bakor\\FileServer\Backups\MyDatabase.bak). - Check that the SQL Server service account (visible in SQL Server Configuration Manager) has at least Read and Read & Execute NTFS permissions on the folder and file.
- For UNC paths, ensure the service account has network share permissions, not just local NTFS permissions — test using
Test-Path \\FileServer\Backups\MyDatabase.bakin PowerShell. - Temporarily disable antivirus/EDR scanning on the backup folder to rule out file locking conflicts.
Step 2: Validate Backup File Integrity
- Run the following T-SQL command to check if the backup header is readable:
RESTORE VERIFYONLY FROM DISK = 'D:\Backups\MyDatabase.bak';
- If this fails with the same 3203 error, the file is likely truncated or corrupted — attempt to re-copy the file from its original source using robust copy tools like
robocopy /Z(restartable mode) to rule out transfer corruption. - Check Windows Event Viewer (
Windows Logs > SystemandApplication) for underlying disk, storage controller, or network-related I/O errors (Event ID 7, 9, or 11) that coincide with the timestamp of the failure.
Step 3: Check Disk and Storage Subsystem Health
- Run
chkdsk D: /f /ron the volume hosting the backup file to rule out file system corruption on Windows Server 2025 or Windows 11. - If using network-attached storage (NAS/SAN), verify there were no network interruptions, SMB timeout issues, or storage array failures during the backup/restore window.
- Review SMB client/server event logs if using a network share, looking for session disconnects under
Applications and Services Logs > Microsoft > Windows > SMBClient.
Step 4: Recreate the Backup (If Source File Is Corrupt)
- If the existing backup file cannot be repaired or verified, generate a fresh backup from the source database:
BACKUP DATABASE [MyDatabase] TO DISK = 'D:\Backups\MyDatabase_New.bak' WITH CHECKSUM, INIT;
- Using the
WITH CHECKSUMoption on future backups helps catch I/O corruption early and prevents this error from recurring undetected.
Alternative or Verification Steps
- After applying fixes, re-run
RESTORE VERIFYONLY FROM DISK = 'YourBackupPath'— a successful completion with no errors confirms the backup file is now readable and valid. - If the error persists only on network paths, try copying the backup file locally to the SQL Server machine and restoring from local disk as a workaround to isolate whether the issue is network-related or file-related.