Skip to main content

How can we help you?

Druva Documentation

SQL Log backup fails with error “last backup LSN from the primary database is greater than the current local redo LSN”

 

Problem description


SQL Log backup fails with error “last backup LSN from the primary database is greater than the current local redo LSN”

Cause

In SQL Server Management Studio, the backup preference is set to "Prefer Secondary",

When Phoenix performs a backup it records the LSN number of the last log file that was backed up.

When the next backup is triggered Phoenix detected that the LSN of the log file available on the secondary replica is less than the LSN number which is recorded in the previous backup. Hence, there were no files available for backup and the backup failed

The reason for failure is that the log files were not synchronized [replicated] in time to the secondary replica

Traceback

1.Follow the instructions provided in the link below to obtain job logs.

https://docs.druva.com/Knowledge_Base/Phoenix/How_to/How_to_collect_the_detailed_job_logs

2.Extract the logs and go to Phoenix<YYYYMMDD>_<timestamp>.log file to see the below traceback in the logs.

[ERROR] <_MainThread(MainThread)> Error <class 'vdilib.SqlException'>:Log backup for database "Test_DB" on a secondary replica failed because the last backup LSN (0x000a59db:00052506:0001) from the primary database is greater than the current local redo LSN (0x000a59db:0005247c:0002). No log records need

Resolution

Need to resolve the latency between the primary replica and secondary replica so that the logs are replicated in time to secondary replica

Reference : Troubleshooting data movement latency between synchronous-commit AlwaysOn Availability Groups

Workaround 

1. In SQL Server Management Studio, change the AAG backup preference to Primary replica

OR

2. Increase the log backup frequency. This will allow enough time for logs to be replicated to the secondary replica.