Zero Byte Backup File After SQL Backup Job

You set up a SQL Server backup job. The job runs every night. You check the backup file the next morning and it's sitting there at 0 bytes. The job history says it completed successfully. No error codes. No failure alerts. Just an empty file that takes up space but holds no data.

This usually happens in one of two ways. Either you're using a SQL Server maintenance plan, or you wrote a custom T-SQL backup script in a job step. The most common trigger is when the job runs but the backup command doesn't actually write to the file you're checking. I've seen this a dozen times with people using Ola Hallengren's scripts or simple BACKUP DATABASE commands in a job.

What Actually Causes a Zero Byte Backup File

The root cause is almost always that the backup command is either pointing to the wrong file path, or the backup is being overwritten by a second command that fails. Here's the specific scenario I see the most:

• Your job has multiple steps. Step 1 backs up the database to C:\Backups\MyDB.bak.
• Step 2 tries to compress that file, or move it, or rename it.
• Step 2 fails. But the job keeps going because it's not set to fail on step failure.
• The file from Step 1 gets deleted or truncated by Step 2's failure.

Or the simpler version: you're backing up to a network share and the path is wrong. The job creates an empty file with the right name but never writes data to it because it can't reach the share.

The Fix: Step by Step

1. Open SQL Server Management Studio. Connect to your server. Expand the SQL Server Agent node. Find your backup job. Right-click it and choose Properties.
2. Look at the Steps list. Under Select a page, click Steps. You'll see every step the job runs. If you have more than one step, that's your first red flag.
3. Check the backup step first. Click the step that does the actual backup. Click Edit. On the General page, look at the Command box. You should see a BACKUP DATABASE command. Copy the path from the TO DISK = '...' part. Paste it into Windows Explorer. Does the folder exist? Can you write to it? If not, that's your problem.
4. Test the backup command manually. Open a new query window. Run the exact BACKUP DATABASE command from the job step. Replace the path with your own test folder if you need to. If it runs fine, the issue is not the backup itself.
5. Now check the next step. Go back to the job steps. If there's a second step that does anything to the backup file—compress, rename, copy—that's where the trouble starts. The job might be running that step even though it failed. Go to the Advanced tab of that step. Look at the "On failure action" dropdown. If it's set to "Go to next step", change it to "Quit the job reporting failure". This stops the job from running subsequent steps if one fails.
6. Look at the filename in the script. If you're using a dynamic filename like MyDB_2025-01-01.bak, the job might be creating a new file each day but another step is deleting old files. Check if the file you're checking is the right one. Open the job history and look at the output message. It should say something like "Processed 123 pages...". If it doesn't mention pages, the backup didn't run.
7. Check the SQL Server error log. Right-click SQL Server Agent in the Object Explorer. Choose View History. Look for any message that says "Backup failed" or "I/O error". The error log is your best friend here.
8. Simplify the job. If you're still stuck, create a new job with a single step. Use this command: BACKUP DATABASE [YourDB] TO DISK = 'C:\Backups\Test.bak' WITH INIT, FORMAT. Run that job manually. If the file is not zero bytes, the problem is somewhere else in your original job.

What to Check If It Still Fails

If you've done all that and the backup file is still zero bytes, check these three things:

• Disk space. Drive C or wherever you're backing up to might be full. SQL Server won't throw an error if it can't write the whole file—it just truncates it. Check free space on the drive.
• Permissions. The SQL Server service account needs write permissions to the backup folder. Right-click the folder in Windows Explorer, go to Properties > Security, and make sure the account listed in SQL Server Configuration Manager has Full Control.
• Antivirus or backup software. I've seen antivirus lock backup files while they're being written. Try backing up to a folder excluded from antivirus scanning. Also check if any other backup software—like Veeam or CommVault—is touching that folder at the same time.

If none of that works, open a query window and run SELECT * FROM msdb.dbo.backupset WHERE database_name = 'YourDB'. This shows every backup made in the last few days. Look at the backup_finish_date and backup_size columns. If the backup size is zero, the job truly ran but didn't write data. That's rare, and usually means the backup command was syntactically correct but targeted the wrong database or file.