Does a full SQL Server backup truncate the transaction log?

A normal full database backup does not truncate the transaction log under an established full recovery model. Regular transaction log backups make inactive log space eligible for reuse, provided other conditions are satisfied. A differential database backup is not a substitute for a log backup either.

Separate truncation from file size

SQL Server divides the transaction log into virtual log files (VLFs). Truncation marks inactive portions reusable; it does not reduce the physical .ldf file on disk.

A full database backup includes enough log information to restore a consistent database, but does not replace the subsequent log backups needed for point-in-time recovery. Without them, an established full-recovery database can fill its available log space and eventually report error 9002.

A successful log backup does not guarantee that all backed-up VLFs become reusable. Active transactions, availability replicas, replication, and other conditions may hold the log. Copy-only log backups do not trigger normal truncation. Before the first full backup establishes the backup chain, a newly created full-recovery database can reuse log space differently.

Schedule a restorable backup chain

-- Example destinations; the SQL Server service needs write access.
BACKUP DATABASE MyDB
TO DISK = 'D:\backup\MyDB_full.bak';

BACKUP LOG MyDB
TO DISK = 'D:\backup\MyDB_log.trn';

Choose the log-backup interval from the acceptable recovery-point loss, not a universal hourly rule. Schedule the full backups and log backups, retain every required link, and test restoration. Repeated backups to a file may append backup sets; plan filenames, retention, and media handling explicitly.

Diagnose a growing or full log

SELECT name, recovery_model_desc, log_reuse_wait_desc
FROM sys.databases;

LOG_BACKUP indicates a log backup is needed. ACTIVE_TRANSACTION or another wait requires a different response. Ensure a backup destination has space before trying to resolve a full-log incident.

After the underlying retention condition is fixed, leave reusable space in the log if the workload will need it again. A one-time shrink can be appropriate after exceptional growth:

USE MyDB;
SELECT name, type_desc FROM sys.database_files;

-- Example only: use the actual logical log filename.
DBCC SHRINKFILE (N'MyDB_log', 10240);

The target is in MB and is not a guarantee: only suitable inactive space can be removed. Routine shrinking followed by regrowth creates avoidable overhead.

What if point-in-time recovery is unnecessary?

The simple recovery model normally permits truncation after checkpoints, subject to active-log requirements. Switching to it breaks the existing log-backup chain. Do so only as an intentional recovery-policy change, not an emergency shortcut.

ALTER DATABASE MyDB SET RECOVERY SIMPLE;

If you later return to full recovery, establish a new valid backup chain before relying on log backups. Under simple recovery, you cannot restore to an arbitrary point between data backups.

See Microsoft's transaction log guidance.