AlwaysOn ERROR: Log backup for database "MyDB" on secondary replica created backup files successfully but could not ensure that a backup point has been committed on the primary.

This error surprised me when it showed up in the error log so I decided to dig into it a bit more.

“Log backup for database "MyDB" on secondary replica created backup files successfully but could not ensure that a backup point has been committed on the primary. This is an informational message only.

Preserve this log backup along with the other log backups of this database.”

The message appears on the secondary replica, where the backup was taken, and indicates one of two possible conditions. To understand the conditions it helps to understand the state of the backup operation.

The error occurs after the point where the backup was successfully streamed to the backup media. The first concern I had was “is my backup valid” and the answer is YES! The backup has been written to the backup media properly.

Now the secondary sends a message to the primary to update the backup position in the database. If this message fails the error is logged.

1. The secondary sends the completed message to the primary. The primary records the backup position but for some reason fails to respond the secondary (I.E. lost network connection.) In this case the next backup will pick up were the current backup completed.

2. The secondary sends the completed message to the primary. The primary never receives the message or fails in some way before it can record the current backup position. (I.E. network, primary shut down, etc…). In this case the next backup will acquire the same information as the last log backup and any additional log records generated.

As you can see the message may be a bit alarming but it is harmless to your backup strategy other than the fact that you might get extra log records in a backup but that can be properly handled during restore. NO DATA LOSS!

Bob Dorr - Principal SQL Server Escalation Engineer

Comments

• Anonymous
  April 21, 2015
  I'm seeing a third condition, trying to perform native log backups, where for some reason, although the backup has been written properly to the backup media, all further attempts to backup fail with Msg 35250, Level 16, State 11, "The connection to the primary replica is not active.  The command cannot be processed.".  This is then followed by Msg 3013, Level 16, State 1, "BACKUP LOG is terminating abnormally." So far, even in dealing with MS support, there is no resolution to this.  What happens is that at that point, the background process is blocked.  When I use DMV view sys.dm_exec_requests, it shows as HADR BACKUP LOCK HOLDER.  The wait type on the blocked process is LCK_M_U and the wait resource is DATABASE: <id> [BULKOP_BACKUP_LOG].  On the blocking process, the wait type is HADR_BACKUP_QUEUE.  Until I either restart SQL Server Agent on the secondary, or run DBCC STACKDUMP, it continues to block. Any ideas?