What’s the issue?
NUL is a virtual device in Windows that discards anything written to it. When SQL Server is told to back up a transaction log to NUL using a command such as BACKUP LOG [DatabaseName] TO DISK = ‘NUL’;, the engine performs all the operations of a real log backup, including marking log records as backed up and allowing the log to be truncated, but the resulting backup file is silently thrown away.
This finding indicates that one or more databases have had a recent transaction log backup directed to the NUL device. Microsoft explicitly documents that NUL should not be used in production environments and is intended only for testing backup performance.
Why is this a problem?
A log backup to NUL breaks the recovery chain. SQL Server records the backup as having occurred and advances its internal log sequence numbers, but the actual data needed for recovery is gone, meaning point in time restore is no longer possible from any prior log backup forward.
This is particularly dangerous because the database appears healthy from a backup history perspective. Reports and monitoring tools see recent log backups in msdb.dbo.backupset and assume the database is protected, when in reality there is nothing to restore. The damage is silent until a recovery is actually attempted, at which point the gap in the log chain becomes a disaster.
NUL backups are also commonly seen as a workaround for log files that grew out of control, used to clear the log without taking the time or storage to capture a real backup. While this fixes the immediate space issue, it leaves the database without a valid recovery path until a new full backup is taken.
What should you do about this?
Identify databases with NUL backups by querying msdb.dbo.backupset and msdb.dbo.backupmediafamily for backup records where the physical device name is ‘nul’ or similar. Determine whether the NUL backups are part of a scheduled job, a manual one time action, or an external tool’s behavior, and stop the practice immediately.
Take a fresh full backup of each affected database to a real location, which reestablishes the recovery baseline. Resume normal scheduled log backups to proper storage, and verify the new chain is intact by reviewing backup history and performing periodic test restores.
If the NUL backups were used because the log file had grown excessively, address the underlying cause rather than the symptom. Investigate why log truncation was not happening (missing log backups, long running transactions, replication or AG issues), correct the root cause, and size the log file appropriately for the workload.