SQL log fail to backup from SQL 2017 AAG with CU15 applied with readable secondaries

[DaveWatkins]

Hi All

I thought I'd put this here in case anyone else is running into it (Case #03611929)

Applying CU15 to a SQL 2017 AAG cluster appears to result in transaction log backups failing if you have readable secondary copies enabled. The default backup method of an Enterprise AAG cluster is to backup from secondary copies if available. They only become available if you mark them as readable when setting up the AAG, but if you have done that then Veeam will fail to backup from them and error out with VSS errors saying cluster registry keys are missing.

This exact setup worked before the CU15 upgrade and the workaround I've discovered is to force the AAG backup method to happen on the primary node.

To be fair this cluster was on CU5 so it could have been any of the CU's in between that started this.

Not a lot of progress on the case in the week since I logged it sadly so here's hoping a resolution comes along eventually. Until then, I figured I'd post this as a warning.

[Dima P.]

Hello Dave,

Thank you for your post. I'll ask our QA folks to check the described issue and get back to you with the results. Stay tuned.

[Dima P.]

Dave,

Unfortunately the Microsoft known issue affects our sql log backup functionality:

Availability Group preferred replica backups
IMPORTANT

Consider the following scenario:

You are running an Availability Group on a Windows Server failover cluster.
You are using the sys.fn_hadr_backup_is_preferred_replica function within your backup jobs to determine whether to run a backup on the current replica.
In this scenario, the function call fails and generates the following error message:

Code: Select all

Msg 41070, Level 16, State 1, Line 1
Configuration data for the availability group with Windows Server Failover Clustering (WSFC) resource ID '<resource ID>' is not found in the WSFC data store.  The availability group may have been dropped, or a previous CREATE AVAILABILITY GROUP or DROP AVAILABILITY GROUP operation has failed.  Please use DROP AVAILABILITY GROUP command to clean up previously failed operations before retrying the current operation.

This issue does not affect the backup itself. Therefore, you can work around this issue by removing the call to sys.fn_hadr_backup_is_preferred_replica.

If you have to back up only on the preferred replica, we recommended that you do not apply Cumulative Update 15. This issue will be fixed in a future release.

We keep investigating the problem. I'll update this thread with more details one we have them. Cheers!

[DaveWatkins]

Hi Dima

Any idea why I've had the ticket open for more than a week and this hasn't ever come back via support? All that's been requested is for me to do things that that obviously aren't the cause, or get more logs, when the original log package obviously had enough detail for this to be identified.

Thanks
Dave

[Gostev]

Because no one at Veeam knew this until yesterday.

[DaveWatkins]

Fair enough. I'd assumed that the speed with which Dima answered implied it was known . Sometime you guys are too good

[Gostev]

We have an unfair advantage of being the part of R&D. So Dima can just walk to those Q&A folks and don't leave until he gets an answer according to the timestamps on his posts above, this time it took only 7 hours of him breathing in the back of their necks

[Dima P.]

Hi folks,

Here goes the KB article > Veeam KB2967.

The most important part: it also contains the link to new and shiny hotfix for the above-mentioned issue > Microsoft KB4506633.

Thanks!