SQL Server Error 3183

Error number

3183

Severity

16 (user-correctable error)

State

1

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 3183 means a page read from the backup failed its checksum validation during RESTORE, so the backup (or the database it was taken from) contains a damaged page and the restore stopped.

A backup taken WITH CHECKSUM carries the page checksums of the database. While restoring it, SQL Server validates each page again; if a page does not match, it raises 3183 with the page address (file:page) and the database name, and the restore ends with Msg 3013 ... RESTORE DATABASE is terminating abnormally. The target database is not usable from this attempt, but nothing else is affected.

The damage was either already in the database when it was backed up, or happened to the backup afterwards: on the disk or tape that stores it, or while it was copied between servers. Microsoft points to hardware and operating system issues as the usual root cause. Treat it as a storage incident, not as a restore syntax problem: find a good backup, and find out where the damage came from so other backups are not affected too.

Common causes

• The backup file was damaged after it was written: faulty disk, controller or tape, or a storage system that returned bad data.
• The file was damaged while it was copied or transferred (network share, cloud upload, removable media) and the copy differs from the original.
• The source database already had a damaged page, and the backup was taken WITH CHECKSUM, CONTINUE_AFTER_ERROR, which writes the backup despite the error.
• Memory or I/O path problems on the server that wrote or read the backup.

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 (10) bs.backup_finish_date, bs.type, bs.has_backup_checksums, bs.is_damaged,
       bs.server_name, 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
WHERE bs.database_name = N'AppDb'
ORDER BY bs.backup_finish_date DESC;

SELECT DB_NAME(database_id) AS database_name, file_id, page_id,
       event_type, error_count, last_update_date
FROM msdb.dbo.suspect_pages
ORDER BY last_update_date DESC;

DBCC CHECKDB (N'AppDb') WITH NO_INFOMSGS, ALL_ERRORMSGS;

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.

RESTORE DATABASE AppDb
FROM DISK = N'\\backupserver\sql\AppDb_full_20261020.bak'
WITH CHECKSUM, NORECOVERY, REPLACE;

RESTORE LOG AppDb
FROM DISK = N'\\backupserver\sql\AppDb_log_20261021_0000.trn'
WITH CHECKSUM, RECOVERY;

RESTORE DATABASE AppDb_Salvage
FROM DISK = N'D:\Backups\AppDb_full_20261023.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';

DBCC CHECKDB (N'AppDb_Salvage') WITH NO_INFOMSGS, ALL_ERRORMSGS;

Examples

Restoring a backup with a damaged page (as documented by Microsoft)

Shown as documented by Microsoft and not reproduced here: producing it requires deliberately damaging a database or backup file. The database name and page address are Microsoft's example values.

RESTORE DATABASE corruption_errors_test
FROM DISK = N'D:\Backups\corruption_errors_test.bak'
WITH CHECKSUM;

Msg 3183, Level 16, State 1, Line 1
RESTORE detected an error on page (1:243) in database "corruption_errors_test" as read from the backup set.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.

How to prevent it

Take every backup WITH CHECKSUM (or enable the backup checksum default server setting after review), keep at least two copies on different storage, and verify copies with RESTORE VERIFYONLY ... WITH CHECKSUM after every transfer. Run DBCC CHECKDB on a schedule so damage in the database is found before it reaches your backups.

Test restores regularly on another server. A restore test is the only way to be sure a backup can be restored, and it catches damaged backup media while older good backups still exist.

Common questions

Learn more on CodeWithSQL

• Working with large databases

Official documentation

• MSSQLSERVER_3183 (Microsoft Learn)
• Specify whether a backup or restore continues or stops after an error
• Possible media errors during backup and restore

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.