This backup set cannot be applied because it is on a recovery path that is inconsistent with the database

Question

I am trying to insert hourly log files after a database has been changed from:

1. "Standby / Read-Only" mode to

2. regular (online) mode to

3. "Read-Only" mode to

4. "Restoring" mode to

5. "Standby / Read-Only" mode.

I was trying to move bak, mdf and ldf files from one drive to other drive due to the disk size.

I was trying to change the mode to "Standby / Read-Only" mode because, currently, our hourly log files can be inserted into database only if it is in "Standby / Read-Only" mode.

This log files are from a third party vendor.

I am getting following error message when I try to insert next hourly log file:

Msg 4330, Level 16, State 1, Line 3
This backup set cannot be applied because it is on a recovery path that 
is inconsistent with the database. 
The recovery path is the sequence of data and log backups that have 
brought the database to a particular recovery point. 
Find a compatible backup to restore, or restore the rest of the database 
to match a recovery point within this backup set, which will restore the 
database to a different point in time.  
For more information about recovery paths, see SQL Server Books Online.
Msg 3013, Level 16, State 1, Line 3
RESTORE LOG is terminating abnormally.
Msg 4305, Level 16, State 1, Line 3
The log in this backup set begins at LSN 385165000000462400001, which is 
too recent to apply to the database. An earlier log backup that includes 
LSN 385162000002744000001 can be restored.

When I looked at the back up file details , last LSN shows 385162000002744000001 (in orange box) , so logically, it should insert the next hourly log file.

My question is, if I change the mode like that (like it changed like 4 times), does it interrupt the process of LSN?

What does it mean by "inconsistent"?

Answer 1

When the recovery part of a database restore is performed, SQL Server processes the pending transactions: roll forward transactions committed in the transaction log but not written in the data files, and roll back uncommitted transactions.

When the database is recovered in standby mode, SQL Server keeps an undo file of these actions, so they can be undone to bring back the database in restoring mode and make it possible to restore more log backups.

However, once the database is fully recovered (no standby mode), there is no such file. The database is now basically a fork of LSN chain. It's not possible to bring back the database in restoring mode and restore additional log backups.

At this point, unfortunately, you must go back to a full database backup.