3013, you do not have the error yet, you have its companion. The real one is the line above it. And if a restore is sitting there, read percent_complete before you kill anything, because a restore at 100 percent is normally still working.Which Message Do You Have?
Find the line you are holding, then take the jump on its band. Backup messages and restore messages sit in the same numeric range and look alike at a glance, which is why so many of these tickets start in the wrong place.
| Message | What it means |
|---|---|
| All you have is 3013 Step 1: the line above 3013 | |
3013, is terminating abnormally | A companion line, no cause in it |
| The backup failed Step 2: backup messages | |
3201, operating system error 5 | Denied to the service account, not to you |
3201, operating system error 2 or 3 | The path does not exist to the server |
3202, operating system error 112 | The target filled up mid-write |
18204 and 3041, error log only | The job kept the summary, not the cause |
| The restore failed Step 3: restore messages | |
3154, holds a backup of a database other than | The wrong database is being overwritten |
3169, backed up on a server running database version | The backup is from a newer build |
4305, 4326, 3159 | The chain, not the file |
5133 and 3156, use WITH MOVE | Those paths do not exist here |
| No error, it is still running Step 4: stuck or slow | |
| The restore is just sitting there | One column says whether it is moving |
| It finished, the database is not usable Step 5: after it finished | |
927, in the middle of a restore | Waiting for you, not broken |
| In Recovery, Recovery Pending, Restoring | Four states, three different answers |
This page routes. Each step is one check and one hand-off to the post that owns the answer, so you are never reading background while a restore is running. Every error number on this site is decoded in SQL Server Errors: The Complete Guide.
Step 1: The Real Error Is the Line Above 3013
Error 3013 is the most reported and least useful message in the whole backup and restore stack. Its text is literally a template, %hs is terminating abnormally, filled in with BACKUP DATABASE or RESTORE DATABASE. It tells you the statement stopped. It never tells you why, because that is always the message immediately before it.
Here is a backup failing on this instance. Two messages, and only one of them is worth reading.
3201 names the device and the operating system error. 3013 adds nothing. If 3013 is all anyone has sent you, go and find the line above it, and the three places it will be are the Messages pane of whoever ran it, the output of the Agent job step, or the SQL Server error log. The full entry, including the 3241 variant that means the backup file itself is not what RESTORE expected, is RESTORE Is Terminating Abnormally (Errors 3013 and 3241).
Once you have the real message, go to Step 2 if it was a backup, Step 3 if it was a restore, and Step 4 if there is no error because nothing has finished yet.
Step 2: Backup Failures, by Message
3201 with operating system error 5, access is denied. This is the one that wastes the most time, because the person testing it can reach the path perfectly well from Explorer. The backup is written by the SQL Server service account, not by you, so the only account whose permissions matter is the one the engine is running as. Cannot Open Backup Device: Operating System Error 5 is the full entry and covers the UNC share case, where the share permissions and the NTFS permissions both have to allow the service account.
3201 with operating system error 2 or 3. Not a permission problem. The path does not exist from where the engine is standing, which usually means a mapped drive letter that only exists in somebody’s desktop session, or a folder that was renamed. The capture in Step 1 is this case.
3202, write failed, operating system error 112. The target filled up during the backup. That is a space incident rather than a backup incident, and SQL Server Disk Is Full or the Log Will Not Truncate is the page for it.
Nothing useful in the job history. An Agent job step often reports only the summary, and the summary is 3041, which is as empty as 3013. The error log has both halves. Here is the same failure as Step 1, read back out of the error log.
Read it bottom up. 3041 is the summary the job reported. 18204 directly above it is the cause, and it names the device and the operating system error exactly as 3201 did in the session. That is the pattern for every backup failure logged by the engine, including the ones raised by third party tools through VDI and VSS, where the engine records that the device failed and the vendor log records why.
Once it is fixed, prove it rather than assume it. Get Database Backup History reads what actually completed from msdb, Get Last Database Backup Times gives one row per database with how old each backup is, and Get Backup Coverage is the version that answers the question a manager asks, which is whether anything is uncovered.
Step 3: Restore Failures, by Message
A restore fails for one of four reasons, and the message separates them cleanly. None of them are fixed by running the restore again.
3154, the backup set holds a backup of a database other than the existing one. The engine is refusing to overwrite a database with a backup that did not come from it, which is a guard rather than a fault. Either you have the wrong file, or you meant to restore into a copy and typed the production name, or you genuinely do want to overwrite and have to say so. The Backup Set Holds a Backup of a Database Other Than the Existing Database covers all three and why WITH REPLACE is the one you should be slowest to reach for.
3169, the database was backed up on a server running database version. Backups move forward only. A 2022 backup restores on 2025, and nothing restores downward, no matter how the compatibility level is set. The number in the message is an internal database version, not a build number, so the first job is working out which release wrote the file, and Restore From a Newer SQL Server Version (Error 3169) decodes that from the two numbers in the message. Every way out of this is some form of moving the data rather than the file.
4305, 4326 or 3159. The files are fine, the chain is not. 4305 means this log backup starts after the point the database has reached, 4326 means it ends before it, and 3159 means the database you are overwriting has a tail that has not been backed up. The LSNs quoted in the message tell you which end of the gap you are on, and The Log in This Backup Set Is Too Recent or Too Early to Apply (Errors 4305, 4326 and 3159) finds the break for you, because a backup job that is green every night still only proves the files were written, not that the log backups between them form an unbroken chain.
5133 and 3156. The restore is trying to put the files back exactly where they were on the source server, and that path does not exist here.
The same 5133 and 3156 pair repeats once for every file in the backup set, so a database with eight files produces sixteen messages and one 3119 at the end. Nothing has been written at this point, which is what “planning for the RESTORE statement” means. Generate Restore With Move Script reads the file list out of the backup and writes the WITH MOVE clauses for you, which is the part people get wrong by hand on a database with more than two files. Generate Backup and Restore Scripts is the wider version for moving a set of databases, and How to Restore a Database in SQL Server is the walkthrough if this is the first one you have done. The options are documented on MS Docs under RESTORE statements.
Step 4: Is It Stuck, or Just Slow?
If there is no error and the session is still running, you are not debugging anything yet. You are deciding whether to wait. One query answers it, and it answers it for backups as well as restores.
percent_complete moving at all means the restore is working. estimated_completion_time is milliseconds remaining and it is a rough extrapolation, so treat it as an order of magnitude rather than a promise. The number that matters most is whether the percentage changed since you last looked.
SELECT r.session_id,
r.command,
CAST(r.percent_complete AS DECIMAL(5,1)) AS pct_done,
r.total_elapsed_time / 1000 AS elapsed_s,
r.estimated_completion_time / 1000 AS est_remaining_s,
r.wait_type,
LEFT(t.text, 46) AS statement_text
FROM sys.dm_exec_requests AS r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) AS t
WHERE r.command IN ('BACKUP DATABASE','RESTORE DATABASE','BACKUP LOG','RESTORE LOG');Here is that query sampled once a second through a real restore of a 1.4 GB database on this instance, with a few rows dropped to keep it readable.
Read the last four rows, because they are the whole reason people kill restores that were about to finish. The statement reported RESTORE DATABASE successfully processed 176354 pages in 28.802 seconds, and it sat at 100.0 percent for the last 9 of those 28.8 seconds, nearly a third of the total. The percentage tracks the data copy. Everything after the copy, which is the undo and redo work that makes the database consistent, has no percentage at all and reports 100 the whole way through. On a database with a long open transaction at backup time that phase can run for considerably longer than the copy did.
estimated_completion_time behaves the way estimates behave. It went up before it came down, because at 10 percent the engine had one second of history to extrapolate from. It is useful in the middle of a long restore and misleading at both ends.
For the versions of this you want on a regular basis rather than at three in the morning, Get Backup Restore Progress is this check with the statement text and the elapsed and remaining times formatted, and Get Backup Restore Duration Estimate answers the question before you start, by reading how long the same database has taken historically. The column itself is documented on MS Docs under sys.dm_exec_requests.
If the percentage has genuinely not moved for several minutes, look at wait_type in the same row before killing anything. BACKUPTHREAD is the restore working normally. A lock wait means something else is holding the database, which Step 5 covers, and killing a restore part way through leaves you with the state Step 5 opens on.
Step 5: It Finished and the Database Still Is Not Usable
A restore that completed and a database that is online are two different events, and the gap between them is where most of the panic in this incident lives. One column settles it, and it is worth running before you conclude anything at all.
SELECT name, state_desc, recovery_model_desc, is_in_standby
FROM sys.databases
WHERE name = N'YourDatabase';That is the whole sequence. The restore succeeded, the database sat in RESTORING, every query against it raised 927, and a single RESTORE DATABASE Lab1001_rst WITH RECOVERY processing zero pages in 0.354 seconds brought it online. Nothing was wrong at any point.
| state_desc | What it means | What to do |
|---|---|---|
RESTORING | The last restore ran WITH NORECOVERY and the database is waiting for more files, or for you to say there are no more | Apply the remaining log backups, then WITH RECOVERY on the last one. Full entry: in the middle of a restore (927) |
RECOVERING | The engine is working on it right now, usually rolling transactions forward or back after a restart or a restore | Wait, and find out how long it has left. Why Is the Database in In Recovery Mode reads the progress out of the error log |
RECOVERY_PENDING | Recovery could not start, almost always because a file is missing or unreadable. Documented, not reproduced here | Database in Recovery Pending (Error 945) has the error log lines that name the file |
OFFLINE | Somebody took it offline deliberately, which is not a restore state at all | Queries raise 942 rather than 927, which is how you tell these apart. ALTER DATABASE ... SET ONLINE |
ONLINE | Done | Check the row counts, not the message |
Two things worth knowing before you reach for the state table. A database in RESTORING is not damaged and cannot be fixed by restarting the instance, and restarting is the single most common wrong move at this point. And the difference between RECOVERING and RECOVERY_PENDING is the difference between waiting and acting, so read it rather than guessing. MS Docs on restore and recovery covers the phases behind these states.
When it is online, Get Last Restore History records what was restored, from which file and by whom, which is what the incident write-up needs and what nobody can remember a week later.
Step 6: Prove the Chain Before the Next One
The incident ends when the database is online. The job ends when you can show this will not happen the same way again, and there are four checks that do it.
Get Backup Chain Integrity walks the backup history and finds the breaks, which is the only way to learn about a broken chain before you need it rather than during a restore. Get Backup Coverage answers the blunter question of which databases have no recent backup at all, and Get Recovery Model Audit finds the databases sitting in FULL recovery with nobody taking log backups, which is both a log that will fill and a restore that cannot roll forward.
A backup that has never been restored is a file, not a backup. A job finishing green says the file was written, not that it restores, not that the process works end to end, and not that anyone on the team can run it under pressure, and Get Last Restore History is the proof either way, because it shows whether anything has actually been restored on this instance and when. Rehearse it on a quiet afternoon and time it, which is also where the Step 4 estimate comes from instead of a guess made during an outage. If the plan itself is the thing in doubt, Differential vs Log Backup covers what each one actually restores and how the chain breaks, and Recovery Models Explained is the decision underneath all of it.
Frequently Asked Questions
The restore is stuck at 100 percent. Is it hung?
percent_complete tracks the copy of data out of the backup file, and the recovery phase that follows it has no percentage, so the column reports 100 for the whole of it. In the capture in Step 4 the restore sat at exactly 100.0 for 9 seconds of a 28.8 second run, and the database was fine. Check wait_type in the same row instead: BACKUPTHREAD is work in progress. Killing a restore at this point is how a quick incident becomes a long one.The backup failed with 3013. What is the real error?
%hs is terminating abnormally, with BACKUP DATABASE or RESTORE DATABASE substituted in, and it contains no cause by design. If the job history only shows 3013 or its summary cousin 3041, read the SQL Server error log for the same timestamp, where the cause is logged immediately above as 3201, 18204 or similar. Step 1 and Step 2 show both halves of the same failure.Cannot restore, the database is in use. How do I get everyone off it?
How long will the restore take?
estimated_completion_time in Step 4 gives you an order of magnitude, and it is at its least reliable in the first few seconds and once the copy finishes. Add time for the recovery phase, which no estimate covers.The restore said it succeeded but the database still says Restoring.
WITH NORECOVERY doing exactly what it was told. The database is holding the door open for more log backups, and until you run RESTORE DATABASE <name> WITH RECOVERY it will refuse every query with error 927. Nothing is damaged and restarting the instance will not change it. Step 5 has the sequence, and the full entry for 927 covers the case where the files you were expecting do not exist.Can I restore a backup from a newer version of SQL Server?
I can reach the backup folder in Explorer, so why is it access denied?
Related
- SQL Server Errors: The Complete Guide, every error number on this site, searchable
- DBA Scripts: Backups and Recovery, the hub for every backup, restore and chain check here
- How to Restore a Database in SQL Server, the walkthrough when nothing has gone wrong yet
- DBA Scripts: Get Backup Chain Integrity, the check that finds a broken chain before a restore does
- SQL Server Disk Is Full or the Log Will Not Truncate, the same kind of page for the space incident underneath half of these
- Cannot Connect to SQL Server, the same kind of page for the other incident that stops everything
Leave a Reply