Error 1412: The Remote Copy Has Not Been Rolled Forward Far Enough

Fix it now

The copy you are joining is behind. Error 1412 is published as the remote copy of the database not having had enough log backups applied to roll forward all of its files to a common point in time. It is not corruption and not a permissions problem, and the gap is filled by restoring the log backups you have not applied yet.

BACKUP LOG [YourDb] TO DISK = 'D:\Backup\YourDb_tail.trn';

RESTORE LOG [YourDb] FROM DISK = 'D:\Backup\YourDb_log_01.trn' WITH NORECOVERY;
RESTORE LOG [YourDb] FROM DISK = 'D:\Backup\YourDb_tail.trn' WITH NORECOVERY;

1. Take a fresh log backup on the principal first, so the chain is complete up to this moment.
2. Find out what the secondary copy has already had applied, from msdb.dbo.restorehistory joined to msdb.dbo.backupset for that database, ordered by restore date.
3. Gather every log backup taken since that point, from wherever they are written, including any taken by a second backup tool that you did not know about.
4. Restore them in order, each one WITH NORECOVERY, so the copy stays ready for more. Skipping one produces the same error you started with.
5. Start the session again: set the partner on the secondary side first and then on the principal, or join the database to the availability group.

Do not restore the last one WITH RECOVERY out of habit. A copy that has been recovered is no longer a continuation of the principal and has to be seeded again from a full backup.

If the session reaches a synchronised state, stop here. If the chain itself has been broken, the next section explains how and what to do about it.

Why it happens

Mirroring and availability groups both work by streaming log records from a known point. The secondary copy has to contain everything up to that point already, because the stream carries what comes next and nothing else. A restore sequence that stops short leaves a gap the stream cannot fill, and the engine refuses to start rather than producing a copy that is quietly missing transactions.

Error 1412’s published text is precise about that: the remote copy has not had enough log backups applied to roll forward all of its files to a common point in time. Note “all of its files”. A database with several files can be short on one of them, which is why the error sometimes appears after a restore sequence that looked complete.

Error 1478 is the same shortage seen from the other side of the session. It is published as the mirror database having insufficient transaction log data to preserve the log backup chain of the principal database, and it names the two ways that happens: a log backup from the principal has not been taken, or it has not been restored on the mirror. If you see 1478, take a log backup on the principal and restore it before doing anything more elaborate.

The other two are about the session rather than the chain. Error 1416 is published as the database not being configured for database mirroring, which is what a command assuming a session that is not there returns. Error 1438 is published as the server instance rejecting the configure request, with a reason and state for Microsoft’s use, and it says something useful about itself: this is a transient error, retrying is likely to succeed, and you should read the other instance’s error log for more information.

Full reference

Working out what is missing

Restoring a chain without breaking it

1. Take the fresh log backup first, so you are not chasing a moving target.
2. Restore in log sequence order, not filename order. Filenames are a convention; log sequence numbers are the truth.
3. Use WITH NORECOVERY on every restore, including the last one.
4. Start the session immediately afterwards, because the principal keeps producing log while you work.
5. If the sequence is long, script it rather than clicking through it; a missed file costs you the whole run.

Turning the partner off leaves the secondary copy in a restoring state that cannot be used without recovering it, and recovering it makes it useless as a mirror. Decide before you run it whether that copy is being rebuilt or being kept, because you rarely get both.

Things that break the chain quietly

• A switch to the simple recovery model, even briefly, ends the chain outright.
• A second backup tool taking log backups on its own schedule.
• Someone restoring the secondary WITH RECOVERY to check something.
• Retention that deletes log backups faster than you can apply them.
• A full backup used for seeding that was taken after a log backup you then restored.

The same rule in an availability group

Joining a database to an availability group carries the same requirement as setting a mirroring partner, so the same restore sequence applies to a secondary replica: full backup with no recovery, then every log backup since, then join. Where the version supports it, automatic seeding removes the manual sequence entirely by streaming the database to the secondary, which is worth considering if you are rebuilding these copies regularly rather than once.

Every code this article covers

Confirm the fix worked

1. The session reports synchronised on both sides, or the availability database shows as joined and synchronising.
2. The secondary database no longer accepts manual restores, which shows the session owns it.
3. The log send and redo queues are draining rather than growing.
4. A log backup on the principal leaves the session unaffected.
5. Only one tool is taking log backups of this database.

Questions people ask about this