SQL Server Error 3241

Error number

3241

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

23 October 2026

What it means

Error 3241 means the file you asked SQL Server to restore from does not contain backup media it can read: it is not a backup, it is damaged or incomplete, or it was written in a format this server cannot process.

Every backup file starts with a media header that describes the media family (the set of files written together by one BACKUP). RESTORE reads that header first, before it looks at the database inside. When the bytes at the start of the file do not form a header SQL Server recognises, it raises 3241 for the device named in the message and stops with Msg 3013 ... is terminating abnormally. Because it fails at the header, even RESTORE HEADERONLY and RESTORE VERIFYONLY fail the same way.

So the message is about the file, not your database or your RESTORE options. The path in quotes is the one SQL Server opened, on the server. Ask three questions: is this really a backup (not an .mdf, a zip or a renamed export)? Did it arrive complete (same size and hash as the original)? And was it written by a SQL Server version this server can read? A newer backup on an older server is normally reported as error 3169, but a file whose header cannot be read at all fails here first.

Common causes

• The file is not a SQL Server backup: a copied data file (.mdf or .ldf), a .bacpac or .zip, a third-party tool backup, or a script output renamed to .bak.
• The copy is incomplete or altered: a transfer that stopped early, an FTP transfer in ASCII (text) mode, or a download that saved an error page instead of the file.
• The file was damaged on disk or on the share after the backup completed.
• The backup was written by a newer SQL Server version, or by a tool that wraps or encrypts the file in its own format, and this server cannot interpret the media.

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.database_name, bs.type, bs.backup_finish_date,
       bs.backup_size, bs.compressed_backup_size, 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 mf.physical_device_name LIKE N'%AppDb%'
ORDER BY bs.backup_finish_date DESC;

SELECT SERVERPROPERTY('ProductVersion') AS this_server,
       DATABASEPROPERTYEX(N'master', 'Version') AS internal_db_version;

SELECT TOP (5) server_name, software_major_version, software_minor_version,
       software_build_version, database_version, backup_finish_date
FROM msdb.dbo.backupset
ORDER BY backup_finish_date DESC;

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_20261023.bak'
WITH CHECKSUM;

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

Examples

Restoring a copied data file instead of a backup

Lab setup: the throwaway database is taken offline only so that its own files can be opened and read; it is brought back online at the end. Any file that is not a backup gives the same result.

-- Someone copied AppDb.mdf and tries to read it as a backup
USE master;
ALTER DATABASE AppDb SET OFFLINE;   -- lab only: closes the files so they can be read
DECLARE @mdf nvarchar(260) = (SELECT physical_name FROM sys.master_files
                              WHERE database_id = DB_ID(N'AppDb') AND type_desc = 'ROWS');
RESTORE HEADERONLY FROM DISK = @mdf;
GO
ALTER DATABASE AppDb SET ONLINE;

Msg 3241, Level 16, State 1, Line 6
The media family on device 'D:\Program Files\Microsoft SQL Server\MSSQL17.MSSQLSERVER\MSSQL\DATA\AppDb.mdf' is incorrectly formed. SQL Server cannot process this media family.
Msg 3013, Level 16, State 1, Line 6
RESTORE HEADERONLY is terminating abnormally.

RESTORE VERIFYONLY fails the same way

The log file (.ldf) of the throwaway database, read while it is offline. VERIFYONLY reports the same header problem, so it cannot vouch for a file that is not a backup.

USE master;
ALTER DATABASE AppDb SET OFFLINE;   -- lab only
DECLARE @ldf nvarchar(260) = (SELECT physical_name FROM sys.master_files
                              WHERE database_id = DB_ID(N'AppDb') AND type_desc = 'LOG');
RESTORE VERIFYONLY FROM DISK = @ldf;
GO
ALTER DATABASE AppDb SET ONLINE;

Msg 3241, Level 16, State 1, Line 5
The media family on device 'D:\Program Files\Microsoft SQL Server\MSSQL17.MSSQLSERVER\MSSQL\DATA\AppDb_log.ldf' is incorrectly formed. SQL Server cannot process this media family.
Msg 3013, Level 16, State 1, Line 5
VERIFY DATABASE is terminating abnormally.

How to prevent it

Treat a backup as untrusted until it has been verified where it will be restored: record its size and hash when you take it, check them after every copy, and run RESTORE VERIFYONLY ... WITH CHECKSUM on the target server before the restore window.

Agree the format with whoever sends you a database: a native .bak from the same or an older SQL Server version, not a data file or an export from another tool. Regular test restores prove the whole path, from backup to copy to restore, before you depend on it.

Common questions

Learn more on CodeWithSQL

• Working with large databases

Official documentation

• RESTORE statements: HEADERONLY (Transact-SQL)
• RESTORE statements: VERIFYONLY (Transact-SQL)
• Media sets, media families, and backup sets

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