SQL Server Error 3013

Error number

3013

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 3013 is the closing line of every failed BACKUP or RESTORE: it says the operation stopped, and the real reason is always in the error printed just before it.

When a backup or restore fails, SQL Server first raises an error that describes the problem (a file it cannot open, a database in use, a broken log chain) and then ends the statement with 3013, naming the operation: BACKUP DATABASE, BACKUP LOG, RESTORE DATABASE, RESTORE LOG, RESTORE HEADERONLY, RESTORE FILELIST or VERIFY DATABASE (that last one comes from RESTORE VERIFYONLY). 3013 itself carries no detail, so searching for it alone leads nowhere. Scroll up.

Read the output from the top. The first error after your statement is the cause; 3013 is always last. Some restores print several errors: a message per file, then Msg 3119 ... Previous messages provide details, then 3013. In that case 3119 is a pointer too, and the messages above it are the ones to fix. Applications and job history often keep only the last line; if all you have is 3013, get the full output by running the statement in a query window, or look at the job step output and the SQL Server error log (where a failed backup is logged as error 3041).

Common causes

• Error 3201 before 3013: the backup file or folder cannot be opened (wrong path, missing drive, no permission for the service account).
• Error 3241 before 3013: the file is not a usable backup (damaged, cut short in transit, or written by a newer version or another tool).
• 3154, 3159 or 3101 before 3013: a RESTORE safety check (another database, an un-backed-up log tail, or sessions still connected).
• 4214, 4208, 4305 or 3117 before 3013: the log chain or the recovery model does not allow this log backup or restore step.
• Errors about files (1834, 5133, 3234, then 3156 and 3119) before 3013: the restore cannot create the database files at the paths given or stored in the backup.
• Errors about space or I/O, such as 3202 or 3203, before 3013: the backup volume is full, or reading or writing the media failed.

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.

EXEC sp_readerrorlog 0, 1, N'BACKUP failed';
EXEC sp_readerrorlog 0, 1, N'BackupDiskFile';

SELECT TOP (10) bs.type, bs.backup_start_date, bs.backup_finish_date,
       bs.is_damaged, bs.has_backup_checksums,
       CAST(bs.backup_size / 1048576.0 AS decimal(18, 1)) AS size_mb,
       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;

EXEC master.sys.xp_fixeddrives;

SELECT r.session_id, r.command, r.status, r.percent_complete, r.wait_type,
       DB_NAME(r.database_id) AS database_name, r.start_time
FROM sys.dm_exec_requests AS r
WHERE r.command LIKE N'BACKUP%' OR r.command LIKE N'RESTORE%';

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

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

Examples

3201 then 3013: backing up to a drive that does not exist

Throwaway database. Drive Z: does not exist on the test server. The first message is the cause; 3013 only closes the statement.

-- Throwaway database; drive Z: does not exist
BACKUP DATABASE AppDb TO DISK = N'Z:\Backups\AppDb.bak';

Msg 3201, Level 16, State 1, Line 2
Cannot open backup device 'Z:\Backups\AppDb.bak'. Operating system error 3(The system cannot find the path specified.).
Msg 3013, Level 16, State 1, Line 2
BACKUP DATABASE is terminating abnormally.

3187 then 3013: verifying with CHECKSUM a backup written without checksums

Throwaway database; the backup goes to the instance default backup folder. The test server has the backup checksum default setting off, so the backup has no checksums. The operation is called VERIFY DATABASE in the 3013 line.

DECLARE @bak nvarchar(260) = CAST(SERVERPROPERTY('InstanceDefaultBackupPath') AS nvarchar(200)) + N'\cws_errlab_3013.bak';
BACKUP DATABASE AppDb TO DISK = @bak WITH INIT;   -- no CHECKSUM option
RESTORE VERIFYONLY FROM DISK = @bak WITH CHECKSUM;

Msg 3187, Level 16, State 1, Line 3
RESTORE WITH CHECKSUM cannot be specified because the backup set does not contain checksum information.
Msg 3013, Level 16, State 1, Line 3
VERIFY DATABASE is terminating abnormally.

3234 then 3013: a MOVE clause with the wrong logical file name

Throwaway database; the backup goes to the instance default backup folder. The data file is really called AppDb, not AppDb_Data; RESTORE FILELISTONLY shows the right name. The copy (cws_errlab_copy) is never created because the restore stops while planning.

USE master;
DECLARE @bak nvarchar(260) = CAST(SERVERPROPERTY('InstanceDefaultBackupPath') AS nvarchar(200)) + N'\cws_errlab_3013.bak';
BACKUP DATABASE AppDb TO DISK = @bak WITH INIT;

RESTORE DATABASE cws_errlab_copy FROM DISK = @bak
WITH MOVE N'AppDb_Data' TO N'D:\SQLData\AppDb_Copy.mdf';

Msg 3234, Level 16, State 2, Line 5
Logical file 'AppDb_Data' is not part of database 'cws_errlab_copy'. Use RESTORE FILELISTONLY to list the logical file names.
Msg 3013, Level 16, State 1, Line 5
RESTORE DATABASE is terminating abnormally.

How to prevent it

Make backup jobs keep their complete output (job step output files or your backup tool's log), and alert on the first error number rather than on 3013, so the alert already says what is wrong. Monitor free space on backup volumes and the age of the last successful backup per database.

Test restores on a schedule. Most of the errors that precede 3013 on a restore (missing files, wrong paths, broken log chains, damaged media) are found cheaply in a test and expensively during an outage.

Common questions

Learn more on CodeWithSQL

• Working with large databases

Official documentation

• MSSQLSERVER_3013 (Microsoft Learn)
• BACKUP (Transact-SQL)
• RESTORE statements: VERIFYONLY (Transact-SQL)

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.