Daily SQL Server Alert: BackupVirtualDeviceFile::SendFileInfoBegin: failure on backup device

Question

I'm running a ~100Gb database on Microsoft SQL Server 2016 (SP2-GDR) Standard Edition (64-bit) on Windows Server 2016 Standard 10.0 (Build 14393: ) (Hypervisor)

Every weekday night just after 7pm I get a SQL Server Alert email like this:-

SQL Server Alert System: 'Severity 016: Miscellaneous User Error' occurred
BackupVirtualDeviceFile::SendFileInfoBegin:  failure on backup device 

My regular daily and weekly database backups all happen at 2am (so it's not those), so I can only assume it's my hourly transaction log backups. But the only SQL agent job that fails is a C# program doing a database read (it times-out), and I can find no other errors in my SQL Agent Logs at that time. And my daily CheckDB Maintenance "Check Database Integrity Task" says the databases are fine. Any thoughts or suggestions? Thanks.

Answer 1

BackupVirtualDeviceFile usually indicates a VDI or VSS backup from a third-party tool. These are usually snapshot-based VM backups that use VSS writers to take application-consistent snapshots of machines, tools like Veeam or CommVault for example.

They can also be third-party backup tools that backup to a Virtual Device and stream the data to an agent or application for further processing, such as compression or encryption.

Check your Windows System and Application event logs for errors, warnings or info messages relating to VSS providers, requestors or writers. In the case of SQL Server, it is installed by default with the SQL VSS Writer which handles VSS requests from these sort of tools. If you see warnings in your SQL Server Error Log about I/O freezes at the same time, this is another indicator of VSS-based backups occurring.

For VDI-based backups not using VSS, it can be a little harder to identify. Try capturing the output of sp_whoisactive frequently during the window this occurs and identify the source of the BACKUP command.

Once you identify the tool in question, check the relevant logs, or with the system administrators responsible to get further error details as this is potentially an issue outside of SQL Server causing this problem.