SQL Server Backup Job Stopped — No Error Fix

You Looked, and It's Just… Stopped

You check the SQL Server Agent, the backup job is disabled. Or the history shows it ran for months, then one day it didn't. No alert, no email failure notification, nothing in the Windows Event Log. The backup job silently stopped running.

What's actually happening here is one of three things, and they stack in complexity. Start with the simplest fix. If that doesn't work, move to the next. You're probably done in under a minute.

Simplest Fix (30 Seconds): Check If the Agent Is Running

I've seen this more times than I want to admit. You restart the SQL Server service, and the SQL Server Agent doesn't automatically start. Or someone stops it to free up memory on a shared box. The backup job won't run if the Agent is dead.

Open SQL Server Management Studio (SSMS).
Right-click SQL Server Agent in Object Explorer.
If it says Start, click it.
Right-click again and pick Properties.
Check Auto start when SQL Server Agent starts. If it's unchecked, the next SQL Server restart will kill your backup again. Check it.

That's it. If the Agent is running, move to the next step.

Moderate Fix (5 Minutes): Job History Tells You the Real Reason

The backup job didn't just stop for fun. Either it failed and the failure wasn't logged as an error (common with certain permission failures), or the job was disabled programmatically. You need to look at the job history, but not the way you normally do.

Step 1: Open the Job History Properly

In SSMS, expand SQL Server Agent > Jobs.
Right-click your backup job, pick View History.
Don't just look at the top entry. Click Show detailed view — it's a checkbox at the bottom.

What you're looking for is a step that shows The job failed in the message column, without a preceding error code. That's a silent failure. The most common cause: the job tried to write to a backup location and the account running the job lost write permissions. Or the backup folder was deleted or renamed.

Step 2: Check the Last Run Outcome Column

In the Job list view (not history), there's a column called Last Run Outcome. If it shows Unknown, that means the job never completed — it was stopped mid-execution. If it shows Succeeded but the job hasn't run since, look at the Last Run Date. If it's days or weeks old, the job schedule is the problem.

Step 3: Verify the Schedule

Right-click the job, pick Properties > Schedules.
Look at the schedule. Is it enabled? Is the recurrence set correctly?
Here's the one that gets people: the schedule can have a start date that's in the past. If you created the job last year and set the schedule to start on that date, it ran once and then disabled itself. Click the schedule, check the Start date field.

-- Quick T-SQL check to see if a job is actually enabled
SELECT name, enabled, date_created, date_modified
FROM msdb.dbo.sysjobs
WHERE name LIKE '%backup%';

Run that query. If enabled is 0, someone or something disabled it. If it's 1 but the job didn't run, the schedule is busted. Enable the job, fix the schedule, and test-run it: right-click the job, pick Start Job at Step.

Advanced Fix (15+ Minutes): The Disk Space or Retention Trap

If the job is enabled, the schedule is correct, and the Agent is running, but the job still won't run? You've hit the silent killer: the backup job's cleanup step is failing, and the job's error handling is set to Quit reporting success instead of Quit reporting failure.

Here's how it works. Your backup job has two steps:

Backup database to disk
Delete old backup files (maintenance cleanup task)

Step 2 fails silently if the disk is full or if a file is locked by an antivirus scan. The job reports success for step 1, then fails on step 2, but because the step's On failure action is set to Quit reporting success, SQL Server Agent logs the job as succeeded and moves on. Next run, same thing. Eventually the backup file fills the disk, step 1 fails, and the job stops completely.

Step 1: Check the Disk Space

Open File Explorer on the SQL Server, check the backup drive. If it's at 99% full, that's your problem. But I've also seen the drive have 100GB free and still fail — because the backup file size is 200GB. Check the free space vs. single backup file size.

Step 2: Check the Retention Period

If you're using a maintenance plan with Cleanup task, open it and look at the retention period. A common mistake: Delete files older than 4 weeks. But if the backup job stopped running for 3 weeks, you now have 7 weeks of backups eating space. The cleanup task deletes only files older than 4 weeks from today, not from the last successful run.

-- Check backup file sizes and dates
SELECT 
    database_name,
    backup_start_date,
    backup_size / 1048576 AS size_mb,
    physical_device_name
FROM msdb.dbo.backupset bs
JOIN msdb.dbo.backupmediafamily bmf ON bs.media_set_id = bmf.media_set_id
ORDER BY backup_start_date DESC;

Run that. If you see hundreds of backup files in the last 3 days and the job hasn't run in a week, the disk is full of old backups. Delete the old ones manually, free up space, then re-enable the job.

Step 3: Fix the Job Step Error Handling

This is the real fix for the silent failure problem. Open the job, go to Steps, click the cleanup step, and change On failure action from Quit reporting success to Quit reporting failure. Now if the cleanup step fails, you'll get an error in the job history and an email notification if you have alerts set up.

On SQL Server 2016 and older, the default for the cleanup step is exactly this — "report success" even on failure. Microsoft changed it in 2017+ to default to "report failure", but they never auto-updated existing jobs. You have to fix it manually.

What If None of These Work?

If you've checked all three and the job still won't run, you've got a corruption in the msdb system database. That's rare but happens after a failed upgrade or a disk write error. Run DBCC CHECKDB('msdb') and look for consistency errors. If you find any, restore msdb from your most recent backup (you do have one, right?).

One more thing: SQL Server Express Edition doesn't have SQL Server Agent. You can't schedule backup jobs natively. If you're on Express, you need a third-party tool or a Windows Scheduled Task running a T-SQL script. That's a different problem entirely.