SQL SERVER – Running Log Backup While Taking Full Backup

A full backup and log backup can overlap on one SQL Server database. A customer noticed both during a slowdown.

Supported overlap does not inherently break the backup chain or consistency. Concurrent CPU and I/O demands can affect latency and backup duration. I separate correctness from performance when investigating.

A full backup includes the log needed for consistent recovery. It does not replace regular log backups in FULL or BULK_LOGGED recovery. Log truncation makes inactive portions reusable. It does not delete or physically shrink the log file.

SELECT name, recovery_model_desc, log_reuse_wait_desc FROM sys.databases ORDER BY name;

Backups, transactions, replicas and other conditions can delay reuse. SIMPLE recovery uses checkpoints to make eligible inactive log reusable. My earlier claim about only log backups cleaning a log was too broad. A log backup can’t bypass another reuse blocker.

Keep recovery objectives and the complete restore sequence intact when changing schedules. Test restores and compare representative workload measurements. Assess resource impact separately from recoverability.

Reference: Transaction log truncation and reuse.

Related reading

• Comprehensive Database Performance Health Check
• timeline
• my recent 25 SQL in Sixty Seconds Video

Backup overlap is not automatic corruption, it is supported work whose resource cost still needs measurement.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.