Overlap in LSN's backed up My current backup strategy for our AlwaysOn clusters is a daily full backup and hourly transaction log backups via a third party backup program. We had a request to minimize the amount of log backups and I noticed that we had a cluster of large log backups at the same time during the day and we began a process to run a log backup to nul right before a full backup.

It seemed to have worked until I tried to do a point in time restore and then it wouldn't restore past the full backup. I investigated and noticed that there is an overlap in the LSN's being backed up. Here is an example for one of the databases.

Last real log backup (secondary) - 20165000011169700001 / 20168000018974100001

backup to nul (primary)          20168000018974100001 / 20168000019060800001

full backup   (primary         20168000019060800001 / 20168000019245900001

first log backup (secondary)      20168000019060800001 / 20174000018926600001


It looks like like the log records backed up to the nul device isn't being registered on the secondary node of the cluster. I assumed that running backup log on any node will transfer to the other one since we normally run log backups on the secondary.

Is this how it is supposed to work?
it looks like like the log records backed up to the nul device isn't being registered on the secondary node of the cluster.


Not to me.  The First Log Backup on the secondary (after the full) starts with the last LSN covered by the backup to 'nul' taken on the primary.

But stepping back to "We had a request to minimize the amount of log backups": why?  And why are you breaking the log chain with the backup to 'nul'?  


  Is this how it is supposed to work?


You are supposed to maintain an unbroken chain of log backups in addition to occasional Full backups.  The log records included in a Full backup will also be present in the next Log backup, as Full backups never break the log chain.  This allows you to loose a Full backup, and restore from a previous Full plus all the log backups.