I have a powershell script that is restoring from production into a test availability group database. It

  • copies the full and t-log backups from production to test,
  • takes the target db out of the availability group and kills all connections,
  • sets the target database to single user,
  • does the restore on test (not point in time, just up to however many t-log backups are present in production) with replace,
  • sets the database to multi-user, makes sure it's in FULL recovery, sets the owner then shrinks the database (truncateonly),
  • takes a full backup,
  • takes a log backup,
  • moves the backups to the secondary, restores, adds the databases to the AG etc...

    My issue is that there's a fork point being created when I take the log backup which gives me an error when restoring on the secondary. It makes no sense because the log backup doesn't start until after the full has been taken.

    Here is the error:

    The log in this backup set terminates at LSN 67867000000017200001, which is too early to apply to the database. A more recent log backup that includes LSN 67869000007776500001 can be restored.

    Here is the output from the backupset:


    and here is the info about the last restore:


    My eyes are crossing looking at this, and it's probably something simple. Ideas?

    • 2
      maybe sharing the script would be helpful. – Max Vernon Jan 20 '16 at 19:20
    • 1
      From does the restore on test (not point in time, just up to however many t-log backups are present in production) with replace I believe that you are encountering the issue since you are creating multiple recovery paths (forks) as you are not restoring the database from the latest diff or chain of log backups. – Kin Shah Jan 20 '16 at 19:43
    • Kin, thanks for the comment! I'm restoring to Test the last full that was taken in Production (with replace), and then all of the logs taken after the full. The Test database recovers fully. This issue occurs when, after restoring Test, I then take a NEW full backup and tran log backup from Test, then try to restore these to the secondary database. – Webgoddess Jan 20 '16 at 22:31
    • @Webgoddess can you exclude truncateonly from your script and run it again. I agree with Max that the script would be helpful. Also, did you check if some process might be breaking the log chain ? – Kin Shah Jan 21 '16 at 0:54

    Your Answer

    By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

    Browse other questions tagged or ask your own question.