Troubleshooting 'Backup Media Verification Failed SQL Server' & Veeam Log Truncation Errors
Comprehensive guide to fixing SQL Server backup media verification failures and Veeam transaction log truncation errors by resolving VSS conflicts and permissio
- VSS (Volume Shadow Copy Service) Provider conflicts or failed SQL Server VSS Writers are the leading cause of guest processing failures.
- Inadequate permissions for the Veeam service account (missing sysadmin role) prevent successful execution of log truncation commands.
- Databases stuck in the Simple Recovery model, or possessing full/corrupted transaction logs, will reject truncation requests from backup software.
- Corrupt backup files, inaccessible storage, or torn pages trigger 'backup media verification failed sql server' errors during the verification phase.
| Method | When to Use | Time | Risk |
|---|---|---|---|
| Restart VSS & SQL Writer Services | VSS writers show as 'Failed' or 'Timeout' in vssadmin list writers | 5 mins | Low |
| Reconfigure SQL Server Permissions | Veeam account lacks sysadmin rights or NT AUTHORITY\SYSTEM lacks access | 15 mins | Low |
| Adjust Database Recovery Models | Databases are in Simple recovery but Application-Aware processing expects Full | 10 mins | Medium |
| Run DBCC CHECKDB & Native Verify | Suspected database corruption or backup media corruption | 1-4 hours | High |
Understanding the Error Landscape
When managing Microsoft SQL Server backups, encountering a situation where backup media verification failed sql server throws an alert is a high-priority incident. This error natively indicates that SQL Server cannot read the backup file it just created, or the backup media is structurally corrupted. This often goes hand-in-hand with virtualization-level application-aware backup failures. For instance, if you are using Veeam Backup & Replication, you might see the dreaded failed to prepare guest for sql server transaction log backup error right before the job fails entirely.
Modern backup solutions rely heavily on Microsoft's Volume Shadow Copy Service (VSS) and the SQL Server Virtual Device Interface (VDI) to freeze I/O, take a snapshot, and subsequently issue commands to truncate the transaction logs. When this chain breaks down, administrators frequently search for solutions because they are unable to truncate microsoft sql server transaction logs veeam.
The Architecture of a VSS-Aware SQL Backup
To understand why a veeam backup unable to truncate sql server transaction logs, you must understand the sequence of events:
- Request: Veeam requests a VSS snapshot from the guest OS.
- Freeze: The SQL Server VSS Writer freezes I/O operations to guarantee application consistency.
- Snapshot: The hypervisor takes a VM-level snapshot.
- Thaw: The SQL Server VSS Writer thaws I/O, resuming normal database operations.
- Truncate: Post-backup, Veeam injects a guest runtime process to connect to SQL Server and issue a
BACKUP LOGcommand (withTRUNCATE_ONLYequivalent logic) to clear the committed transactions.
When veeam failed to truncate microsoft sql server transaction logs, it means steps 1-4 likely succeeded, but step 5 failed. This can be due to permissions, recovery model mismatches, or SQL VDI timeouts.
Deep Dive Diagnosis
Diagnosing Media Verification Failures
If you see Msg 3241, Level 16, State 0: The media family on device '...' is incorrectly formed, this is a classic backup media verification failed sql server scenario. It means the RESTORE VERIFYONLY command executed by your native SQL job or maintenance plan has failed.
Common Causes:
- Storage Drops: The underlying SAN/NAS dropped packets during the write operation.
- Torn Pages: The database itself contains corruption that was written into the backup file.
- Encryption/Compression Mismatches: Third-party transparent data encryption (TDE) or overly aggressive compression utilities corrupted the backup header.
Diagnosing Veeam Truncation Failures
You might encounter a few variations of this error in the Veeam console:
Error: unable to truncate sql server transaction logs veeamveeam failed to truncate sql server transaction logs. Details: Failed to call RPC function 'Vss.TruncateSqlLogs'veeam unable to truncate microsoft sql server transaction logs: Access Denied
These errors almost always point to one of three things:
1. The Database Recovery Model If a database is set to the Simple recovery model, SQL Server automatically reclaims log space. However, if Veeam is configured to process transaction logs for point-in-time restores, it expects the database to be in the Full or Bulk-Logged recovery model. Trying to truncate logs on a Simple recovery database will result in an error.
2. Permissions Issues
The Veeam Guest Processing account (or NT AUTHORITY\SYSTEM if using VIX/VMware Tools for injection) requires the sysadmin server role within SQL Server. If the account only has db_owner or less, it cannot issue instance-wide VDI commands to truncate logs.
3. Stale or Failed VSS Writers
If the SQL Server VSS Writer is in a failed state (e.g., [8] Failed or [9] Timeout), the guest preparation phase will fail entirely, resulting in the failed to prepare guest for sql server transaction log backup error.
Step-by-Step Resolution
Step 1: Verify and Reset VSS Writers
First, log into the SQL Server guest OS and open an elevated command prompt. Run:
vssadmin list writers
Look for SqlServerWriter. If the state is anything other than [1] Stable and No error, you have found your culprit.
Restart the service:
Restart-Service SQLWriter -Force
Note: In heavily loaded environments, the SQL Writer may frequently time out. You may need to adjust the VSS timeout registry keys or increase hardware resources (IOPS).
Step 2: Fix SQL Server Service Account Permissions
If veeam failed to truncate microsoft sql server transaction logs due to access issues, open SQL Server Management Studio (SSMS):
- Go to Security > Logins.
- Verify the account specified in the Veeam Backup Job (under Guest Processing -> Credentials) exists here.
- Right-click the login, go to Properties > Server Roles.
- Ensure sysadmin is checked.
- Additionally, ensure
NT AUTHORITY\SYSTEMis present and hassysadminrights, as Veeam often falls back to the system context when VSS components interact with SQL Server.
Step 3: Validate Recovery Models and Log Reuse Wait
Run a query to determine why logs aren't truncating. Often, a log is waiting on LOG_BACKUP or ACTIVE_TRANSACTION.
If a database has a massive open transaction, even a successful backup won't truncate the log, causing Veeam to report that it is unable to truncate microsoft sql server transaction logs veeam.
Check sys.databases for log_reuse_wait_desc. If it says ACTIVE_TRANSACTION, you must use DBCC OPENTRAN to find the hanging query and kill it.
Step 4: Resolving Native Media Verification Errors
If you are dealing specifically with the backup media verification failed sql server error, you must ensure your database is healthy before blaming the backup storage.
Run DBCC CHECKDB ('YourDatabaseName') WITH NO_INFOMSGS, ALL_ERRORMSGS;
If DBCC CHECKDB returns errors, your database is corrupt, and it is backing up that corruption. If it returns clean, your storage network or backup repository disk is corrupting the file post-write. Test writing a backup to a completely different physical disk (e.g., local C:\ instead of a network share) and run RESTORE VERIFYONLY against it.
By systematically verifying VSS stability, SQL permissions, recovery models, and physical media integrity, you can eliminate these backup failures and ensure your databases are protected.
Frequently Asked Questions
# Diagnostic Script for SQL Server VSS and Log Truncation Issues
# 1. Check the status of the SQL Server VSS Writer
Write-Host "Checking VSS Writers..."
vssadmin list writers | Select-String -Context 0,4 "SqlServerWriter"
# 2. Check Database Recovery Models and Log Reuse Wait states via SQLCMD
Write-Host "Checking SQL Server Database States..."
$sqlQuery = @"
SELECT
name AS [DatabaseName],
recovery_model_desc AS [RecoveryModel],
log_reuse_wait_desc AS [LogReuseWait],
state_desc AS [State]
FROM sys.databases
WHERE state_desc = 'ONLINE';
"@
Invoke-Sqlcmd -Query $sqlQuery -ServerInstance "." -TrustServerCertificate
# 3. Perform a Native Media Verification test
# Replace the path with your actual backup file path if testing native SQL errors
$verifyQuery = @"
-- Run this to test native 'backup media verification failed sql server' issues
-- RESTORE VERIFYONLY FROM DISK = 'C:\SQLBackups\TestDB.bak';
"@
# 4. Restart VSS Services if necessary (Uncomment to execute)
# Restart-Service SQLWriter -Force
# Restart-Service VSS -ForceError Medic Editorial
Error Medic Editorial is composed of senior DevOps and SRE professionals specializing in database administration, backup architectures, and enterprise disaster recovery workflows.