SQL Server Error 1408

Error number

1408

Severity

16 (user-correctable error)

State

Not documented by Microsoft (not reproduced here)

Product

Microsoft SQL Server Database Engine

Versions

SQL Server 2016 to 2025 with Always On availability groups or database mirroring

Category

High Availability

Last reviewed

24 October 2026

What it means

Error 1408 means the copy of the database you restored on the secondary replica (or mirror) is missing log records that the primary has already backed up, so it cannot be joined until the missing log backups are restored.

When you seed a secondary by hand, you restore a full backup (and optionally a differential) WITH NORECOVERY, then every log backup taken since, and only then join the database. The primary starts sending log from the point where the secondary copy ends. If log backups were taken on the primary after your full backup and not restored on the secondary, the log in between is no longer in the primary's active log, and the join fails with 1408. The quoted name is the database on the secondary.

The wording mentions both mirroring and availability groups because the same check protects both features. The most common real cause is a scheduled log backup job on the primary that ran while the full backup was being copied and restored. Microsoft recommends suspending scheduled log backups until secondary initialisation is complete.

Common causes

• A scheduled log backup ran on the primary between the full backup and the join, and that log backup was not restored on the secondary.
• Only the full backup was restored; the log backups taken after it were skipped or restored out of order.
• A log backup taken by another tool or job (or to NUL) broke the chain, so the secondary cannot get the missing log from any file.
• The secondary copy was restored from an older backup than intended, for example the wrong file from a shared folder.

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 name, state_desc, recovery_model_desc, create_date
FROM sys.databases
WHERE state_desc = N'RESTORING';

SELECT DB_NAME(database_id) AS database_name, MIN(redo_start_lsn) AS needs_log_from_lsn
FROM sys.master_files
WHERE redo_start_lsn IS NOT NULL
GROUP BY database_id;

SELECT TOP (20) bs.database_name, bs.type, bs.backup_finish_date,
       bs.first_lsn, bs.last_lsn, 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'SalesDb'
ORDER BY bs.backup_finish_date DESC;

SELECT TOP (20) rh.destination_database_name, rh.restore_date, rh.restore_type,
       bs.first_lsn, bs.last_lsn
FROM msdb.dbo.restorehistory AS rh
JOIN msdb.dbo.backupset AS bs ON bs.backup_set_id = rh.backup_set_id
WHERE rh.destination_database_name = N'SalesDb'
ORDER BY rh.restore_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.

-- On the secondary replica (SQL02)
RESTORE LOG SalesDb FROM DISK = N'\\backupshare\SalesDb\SalesDb_log_0915.trn' WITH NORECOVERY;
RESTORE LOG SalesDb FROM DISK = N'\\backupshare\SalesDb\SalesDb_log_0930.trn' WITH NORECOVERY;

ALTER DATABASE SalesDb SET HADR AVAILABILITY GROUP = SalesAg;

-- On the primary (SQL01)
BACKUP LOG SalesDb TO DISK = N'\\backupshare\SalesDb\SalesDb_log_join.trn';

-- On the secondary (SQL02)
RESTORE LOG SalesDb FROM DISK = N'\\backupshare\SalesDb\SalesDb_log_join.trn' WITH NORECOVERY;
ALTER DATABASE SalesDb SET HADR AVAILABILITY GROUP = SalesAg;

-- On the primary
ALTER AVAILABILITY GROUP SalesAg
MODIFY REPLICA ON N'SQL02' WITH (SEEDING_MODE = AUTOMATIC);

-- On the secondary
ALTER AVAILABILITY GROUP SalesAg GRANT CREATE ANY DATABASE;

Examples

Joining a secondary restored from the full backup only

Shown as documented in the message catalogue; not reproduced here because it needs an availability group. It occurs when log backups were taken on the primary after the full backup and not restored on the secondary. The state is not documented, so no message header is shown.

-- On SQL02, after RESTORE DATABASE SalesDb ... WITH NORECOVERY (no log restores),
-- while the primary's log backup job kept running
ALTER DATABASE SalesDb SET HADR AVAILABILITY GROUP = SalesAg;

The remote copy of database "SalesDb" is not recovered far enough to enable database mirroring or to join it to the availability group. You need to apply missing log records to the remote database by restoring the current log backups from the principal/primary database.

How to prevent it

Script manual seeding as one sequence: pause the log backup job, take the full backup, restore it WITH NORECOVERY, take and restore a log backup, join, then resume the job. Keep all backups for the database in one known location so the secondary can always find every file in the chain, and never back up the log to NUL.

Where the network allows it, prefer automatic seeding for new replicas and databases.

Common questions

Learn more on CodeWithSQL

• RDS backups and restores

Official documentation

• Prepare a secondary database for an availability group
• Join a secondary database to an availability group
• Automatic seeding for secondary replicas
• Database Engine events and errors 1000 to 1999

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.