SQL Server Error 4305

Error number

4305

Severity

16 (user-correctable error)

State

1

Product

Microsoft SQL Server Database Engine

Versions

All supported SQL Server versions (2016 to 2025), Azure SQL Managed Instance

Category

Backup & Restore

Last reviewed

24 October 2026

What it means

Error 4305 means the log backup you are restoring starts later than the point the database has reached, so at least one log backup in between is missing from the restore sequence.

Log backups form a chain: each one starts at the log sequence number (LSN) where the previous one ended. While a database is in the RESTORING state, SQL Server knows exactly which LSN it needs next. If the log backup you give it begins after that LSN, applying it would leave a hole in the history, so the restore stops with 4305 and Msg 3013 ... RESTORE LOG is terminating abnormally. The database stays in RESTORING, and nothing restored so far is lost.

The message gives you both numbers. "Begins at LSN X" is the first LSN of the file you tried; "an earlier log backup that includes LSN Y" is the LSN the database needs next. Look for the log backup whose range includes Y (its first LSN is at or before Y and its last LSN after it): that is the missing file. You can then carry on from where you are, because the failed RESTORE LOG changed nothing.

Common causes

• A log backup was skipped, or the files were restored out of order (for example sorted by name, where 10 comes before 9).
• Another job or tool took a log backup to a different location (a second maintenance plan, a third-party backup agent, someone backing up the log manually), and that file is not in your restore set.
• A log backup file was deleted by a retention cleanup before the restore, or was never copied to the restore server.
• The full or differential backup you restored is older than you thought, so the restore needs log backups from before the first file you have.

Diagnose it

Read-only These queries only read metadata and dynamic management views. They do not change data, permissions or configuration, so they are safe to run first.

SELECT d.name, d.state_desc, mf.name AS logical_file, mf.redo_start_lsn
FROM sys.databases AS d
JOIN sys.master_files AS mf ON mf.database_id = d.database_id
WHERE d.name = N'AppDb';

SELECT bs.backup_start_date, bs.first_lsn, bs.last_lsn,
       CASE WHEN bs.first_lsn <> LAG(bs.last_lsn) OVER (ORDER BY bs.first_lsn) THEN 'GAP before this backup' ELSE '' END AS chain_check,
       mf.physical_device_name
FROM msdb.dbo.backupset AS bs
JOIN msdb.dbo.backupmediafamily AS mf ON mf.media_set_id = bs.media_set_id
WHERE bs.database_name = N'AppDb'
  AND bs.type = 'L'
ORDER BY bs.first_lsn;

SELECT TOP (20) bs.backup_start_date, bs.user_name, bs.is_copy_only,
       mf.device_type, mf.physical_device_name
FROM msdb.dbo.backupset AS bs
JOIN msdb.dbo.backupmediafamily AS mf ON mf.media_set_id = bs.media_set_id
WHERE bs.database_name = N'AppDb'
  AND bs.type = 'L'
ORDER BY bs.backup_start_date DESC;

How to fix it

Each fix is labelled with what it changes. Try read-only checks and the least invasive fix first, and test changes outside production.

RESTORE LOG AppDb
FROM DISK = N'D:\Backups\AppDb_log_0900.trn'   -- the missing file
WITH NORECOVERY;

RESTORE LOG AppDb
FROM DISK = N'D:\Backups\AppDb_log_1000.trn'   -- the file that failed
WITH NORECOVERY;

RESTORE LOG AppDb
FROM DISK = N'D:\Backups\AppDb_log_1100.trn'
WITH RECOVERY;

RESTORE DATABASE AppDb
FROM DISK = N'D:\Backups\AppDb_diff_1030.bak'
WITH NORECOVERY;

RESTORE LOG AppDb
FROM DISK = N'D:\Backups\AppDb_log_1100.trn'
WITH RECOVERY;

RESTORE DATABASE AppDb WITH RECOVERY;

BACKUP DATABASE AppDb
TO DISK = N'D:\Backups\AppDb_full_after_restore.bak'
WITH CHECKSUM;

Examples

Skipping a log backup in the restore sequence

Throwaway database; the backups go to the instance default backup folder. The LSN values differ on every run.

-- Throwaway database in FULL recovery: a full backup and two log backups
ALTER DATABASE AppDb SET RECOVERY FULL;
DECLARE @p nvarchar(200) = CAST(SERVERPROPERTY('InstanceDefaultBackupPath') AS nvarchar(200));
DECLARE @full nvarchar(260) = @p + N'\cws_errlab_4305.bak',
        @log1 nvarchar(260) = @p + N'\cws_errlab_4305_1.trn',
        @log2 nvarchar(260) = @p + N'\cws_errlab_4305_2.trn';
BACKUP DATABASE AppDb TO DISK = @full WITH INIT;
CREATE TABLE dbo.Orders (id int PRIMARY KEY);
INSERT dbo.Orders VALUES (1);
BACKUP LOG AppDb TO DISK = @log1 WITH INIT;
INSERT dbo.Orders VALUES (2);
BACKUP LOG AppDb TO DISK = @log2 WITH INIT;

USE master;
RESTORE DATABASE AppDb FROM DISK = @full WITH REPLACE, NORECOVERY;
RESTORE LOG AppDb FROM DISK = @log2 WITH RECOVERY;   -- log backup 1 was skipped

Msg 4305, Level 16, State 1, Line 16
The log in this backup set begins at LSN 50000000035200001, which is too recent to apply to the database. An earlier log backup that includes LSN 50000000028800001 can be restored.
Msg 3013, Level 16, State 1, Line 16
RESTORE LOG is terminating abnormally.

How to prevent it

Have exactly one process take log backups of each database, and if another tool must back up the database, make it use COPY_ONLY so it does not take part in the chain. Name log files with a sortable timestamp (for example AppDb_log_20261024_0915.trn) and build restore scripts from msdb history ordered by first_lsn, not from a folder listing.

Keep log backups at least as long as the full backup they depend on, and test restores regularly on another server. A restore test is the only check that finds a broken chain before you need it.

Common questions

Learn more on CodeWithSQL

• SQL transactions and ACID explained

Official documentation

• Apply transaction log backups (SQL Server)
• Restore a transaction log backup (SQL Server)
• RESTORE statements: HEADERONLY (Transact-SQL)

Last technically reviewed 24 October 2026; examples and diagnostics run on SQL Server 2025 (17.0.1145.4). Message text checked against the engine's sys.messages catalogue.