SQL Server backup fails with error 3013, BACKUP DATABASE is terminating abnormally, usually alongside another error number just above it.
What does 3013 mean and how do I find the real cause?
SQL Server backup fails with error 3013, BACKUP DATABASE is terminating abnormally, usually alongside another error number just above it.
What does 3013 mean and how do I find the real cause?
Error 3013 is a symptom rather than a cause, the generic backup terminating abnormally message and the fix depends entirely on reading the error that accompanies it, so:
Understand 3013's nature first: it is SQL Server saying the backup failed, without saying why and it almost always appears paired with a more specific error immediately above it in the message or the log, that companion error being the real diagnosis. So the whole technique is finding and reading the accompanying error rather than treating 3013 itself, which tells you only that something went wrong.
The common companions and their causes: a 3201 with 3013 means the backup device or path failed, a bad or inaccessible destination path, permissions on the backup folder the SQL Server service account lacks or the destination disk full, all about where the backup is trying to go. An operating system error like 112 means the disk is full, 5 means access denied on the path, 3 means the path does not exist. A 3271 indicates an IO error on the device during the write. Each points at a specific fixable thing, and the number is the map.
The diagnosis and fixes by companion: for path and permission errors, verify the backup destination exists, the SQL Server service account has write permission on it, network paths are reachable and use UNC not mapped drives which the service does not see and the disk has space. For device IO errors, the destination storage or network is failing during the write, checked at the storage level. The pattern is that 3013 sends you to its companion, and the companion sends you to a concrete cause.
The reliable technique: capture the full error message or the SQL Server error log around the failed backup, read the number paired with 3013 and address that specific error, since 3013 alone is unactionable and its companion is always actionable. Most 3013 backup failures resolve at the destination, a full disk, a permission the service account lacks, an unreachable path, the mundane causes the specific error names once you look past the generic 3013.
The companion was an OS error 5, access denied and sure enough the SQL Server service account had no write permission on the new backup folder. Granted it and the backup ran. The 3013 is just the symptom, read its companion technique is the real lesson, I had been searching 3013 itself and finding nothing actionable.