Skip to main content

[VAW] Issues with VAW - SQL Server Transaction Log backup - Veeam Support - Case # 07977668

  • March 10, 2026
  • 8 comments
  • 41 views

SQL Transaction Log Backup fails due to temp staging disk full (Veeam Agent for Windows)

 

Environment

Product: Veeam Agent for Microsoft Windows
Workload: SQL Server databases
Backup Type: SQL Transaction Log Backup (Application-aware processing)

Error Received

The following error appears during the SQL transaction log backup job:

 

Log backup job: Backup Job for SQL Server Transaction Log Backup

Collected SQL Server transaction logs do not match any existing database backup.

Failed to perform internal backup:
Code = 0x80040e14
Source = Microsoft OLE DB Driver 19 for SQL Server
Description = Write on "C:\ProgramData\Veeam\Endpoint\SqlLogBackup\{GUID}.bak"
failed: 112 (There is not enough space on the disk.)

Database hide_name_db        Status    Unprotected

Failed to perform internal backup (hide_name_db): Code = 0x80040e14 Code meaning = IDispatch error #3092 Source = Microsoft OLE DB Driver 19 for SQL Server Description = Write on "C:\ProgramData\Veeam\Endpoint\SqlLogBackup\{18aa4e5f-9ef9-45f8-ad9a-409f952f8963}.bak" failed: 112(There is not enough space on the disk.) COM error: Code: 0x80040e14
 


SQL Server event log also reports:

Event ID: 18210
BackupIoRequest::ReportIoError
write failure on backup device
Operating system error 112 (There is not enough space on the disk)
 

Initial Observation

The issue occurs during the staging phase where Veeam temporarily stores SQL transaction log backups in:

C:\ProgramData\Veeam\Endpoint\SqlLogBackup
 

When the staging disk (C:) becomes full, Veeam cannot complete the log backup process and the job fails.

 

Additional Finding

The problem was primarily associated with the SQL database:

hide_name_db

 

The transaction log file had grown abnormally.

SQL Log File Status

Physical log file size: 402 GB

Actual log usage: 447 MB (0.11%)

 

The growth occurred because the log had previously reached ~99% utilization, triggering repeated Autogrowth events configured with small increments (64 MB). Over time, this caused the physical log file to expand significantly.

 

Root Cause

The large transaction log caused large temporary backup files to be generated in the staging directory:

C:\ProgramData\Veeam\Endpoint\SqlLogBackup
 

Since the staging disk was limited in capacity, the backup process failed with OS error 112 (disk full).
 

Corrective Actions Implemented

SQL Server side

  1. Executed a manual transaction log backup.

  2. Performed a controlled SHRINK operation on the log file:

hide_name_db_log.ldf

BACKUP LOG hide_name_db
TO DISK = 'NUL';
GO

 

USE hide_name_db;
GO

DBCC SHRINKFILE (hide_name_db_log, 8192);
GO

 

New size: ~8 GB

 

  1. Modified SQL Autogrowth configuration:

Old: 64 MB

New: 512 MB

This reduces excessive small growth events.


 

ALTER DATABASE hide_name_db
MODIFY FILE
(
    NAME = hide_name_db_log,
    FILEGROWTH = 512MB
);
GO


 

Veeam configuration

The SQL log handling mode was updated to:

 

Backup logs periodically – every 30 minutes

instead of:

 

Truncate logs

This ensures logs are backed up and truncated regularly.

 

Veeam Agent staging path workaround

Following Veeam Support guidance (KB2642), we temporarily moved the SQL log staging location to a dedicated volume:

Registry key created: HKLM\SOFTWARE\Veeam\Veeam EndPoint Backup
Value Name: SqlTempLogPath
Type: REG_SZ
Value Data: E:\VeeamSQLTemp

Services were restarted and the new path was validated.

Later, after correcting the SQL log size and configuration, this workaround was reverted.

 

Recommendations from Veeam Support

Support also suggested:

  1. Re-enable the Agent job with Guest Processing enabled.

  2. Implement Antivirus exclusions according to:

KB2034
https://www.veeam.com/kb2034

  1. Verify permissions for:

C:\Windows\Temp

 

Ensure SYSTEM has full access.

Current Status

After correcting the SQL transaction log size and adjusting the Autogrowth configuration, the environment is currently being monitored to verify that transaction log backups complete successfully without filling the staging disk.

8 comments

Chris.Childerhose
Forum|alt.badge.img+21

Continue on with support for this issue.  The community site is not support but if you want help with your case since you have one you can post this in the forums - https://forums.veeam.com

You will get better assistance there and via support.


coolsport00
Forum|alt.badge.img+21
  • Veeam Legend
  • March 10, 2026

Hi ​@juan aguilera - was this a question or just sharing a VAW problem and what was done to resolve it? Looks like the latter of the 2 since it appears, as you share under the “Current Status” section, Support got you sorted? If so, thanks for sharing what worked for you.


eblack
Forum|alt.badge.img
  • Experienced User
  • March 11, 2026

If the log grows rapidly again, the 30-minute Veeam interval will attempt to copy the entire changed portion of the log to the staging folder. If that data exceeds the free space on C: the job will fail again with Error 112.

Make sure C:\ProgramData\Veeam is excluded from AV. 

 

 


  • Author
  • Not a newbie anymore
  • March 11, 2026

Hi everyone,

Thanks ​@Chris.Childerhose  and ​@coolsport00 . This is not an official support article but rather a blog recommendation describing a potential workaround when VAW attempts to process SQL Server transaction log backups.

Following the Veeam Support preemptive suggestion in KB2642, the temporary SQL transaction log backup path was redirected from the default location C:\ProgramData\Veeam\Endpoint\SqlLogBackup to a dedicated volume using the SqlTempLogPath registry key to avoid space-related failures during log backup processing.

The issue occurs when the transaction log backup cannot be completed successfully, preventing log truncation. This may happen due to incomplete backups, connection interruptions, or repeated attempts to resume the backup process.

Yes, that is correct ​@eblack . An antivirus exclusion should be configured beforehand to prevent interference with the backup processes.

Additionally, the issue could occur again if the Veeam Transaction Log Backup job fails. In that scenario, Veeam would stop truncating the logs while SQL Server would continue generating them normally.

This happens because when a database is configured with Recovery Model = FULL, transaction logs are only released after a log backup is performed. If the log backup does not run successfully, the .ldf file will continue to grow and will not be truncated.

In this case, the transaction log likely started with a small initial size and gradually expanded over time through multiple autogrowth events configured at 64 MB, eventually reaching its current size of approximately 402 GB.

As a preventive measure, the FILEGROWTH setting of the transaction log file was configured to 512 MB to better control its expansion and prevent frequent small growth events that could lead to fragmentation or performance impact.

With this configuration, the expected behavior is that the .ldf file remains stable:
SQL Server generates the logs, Veeam backs up the transaction logs, and then truncates them, preventing indefinite growth of the log file.


Chris.Childerhose
Forum|alt.badge.img+21

Thanks for the clarity ​@juan aguilera as usually, when people post case numbers they want support.  Maybe next time, just change the subject of the post slightly so that it is known to be a fix/workaround for that particular case issue.


  • Author
  • Not a newbie anymore
  • March 11, 2026

Thanks for the clarification, ​@Chris.Childerhose . That makes sense.

I appreciate the suggestion, and you’re right — including the case number in the title may give the impression that the post is requesting support rather than sharing a workaround. I’ll keep that in mind and adjust the subject line next time so it’s clearer that the post is documenting a solution or workaround.

Thanks again for the feedback!


coolsport00
Forum|alt.badge.img+21
  • Veeam Legend
  • March 11, 2026

No problem ​@juan aguilera . Thanks for clarifying.


Chris.Childerhose
Forum|alt.badge.img+21

Thanks for the clarification, ​@Chris.Childerhose . That makes sense.

I appreciate the suggestion, and you’re right — including the case number in the title may give the impression that the post is requesting support rather than sharing a workaround. I’ll keep that in mind and adjust the subject line next time so it’s clearer that the post is documenting a solution or workaround.

Thanks again for the feedback!

Not a problem at all, happy to help.