I wanted to clarify as per that post you linked to in the question and you are asking about "to be protected even better from a possible ransomware attack" specifically as per the. . .
Essentially Azure Backup gives you three levels of backup technology that you want to use. . .
- Files and Folders
- System State
- Full volume point-in-time and image backups
- Bare Metal (on-premises)
- VM level backups (OS and other volumes)
There are other types of Azure Backup agents you can add-on to take care of the SQL Server backups for you, but since you want to not affect your existing SQL Server backup strategy nor affect the backup log chain of your existing SQL Server backups, don't use that agent.
- Simply don't use any SQL Server specific Azure Backup agents or functionality
In terms of a full system recovery and the correlated restore operations in the event any are needed—which is the entire purpose of backups to begin with, adding the Azure Backup level backups to your backup and recovery strategy will help you be better protected and be able to get your system back up and running quicker in the event such an action is needed.
Well if getting your system back up and fully functional in a timely manner is of any importance, then adding the Azure Backup strategy will better protect your system operations/availability/resiliency.
With just the SQL Server backups as you have today, in the event of a full system crash and recovery is needed, you need to get your Windows Server installed, and then get SQL Server installed and configured, and then get your SQL backup files and transactions logs copied over from backup media, and then start restoring the SQL Server database level stuff.
Think about your backup strategy from a perspective of a full system recovery. Think about what data you need to get your system back up and running and go from there as a starting point.
Azure Backup Recovery Understanding
Testing and documenting the restore\recovery process for future reference with the Azure Backup data and technology once you get something in place—that you confirm works without breaking the existing SQL backup jobs, is important so don't overlook this critical step.
Does Azure Backup for Windows Server affect regular SQL Server backups
on the same server?
Obviously it can affect the SQL database regular backup jobs if both the Azure Backup job and the SQL Server backup jobs are running at the same time—they will likely need to share CPU, memory, and disk resources from the same Windows Operating System and thus potentially affect each other at this level.
Concurrently using shared resources from the same OS could equate to the SQL Server database backup jobs taking longer to complete. You won't know the specifics for certain until you just do it. It is important that your current restore strategy have an easy way to get the backup jobs back in sync in the event that it does break and you know the motions to take.
In terms of breaking your SQL Server database backup chain, unless you are running SQL Server database specific job types where you could lose a transaction log or changing SQL Server database recovery models with the Azure backup technology, then it should not have any impact whatsoever on the SQL Server database log backup chain.
I don't have much experience with SQL Server High Availability but I know when you have databases in standby applying transactions from a primary DB such as with Log Shipping, that the chain is of high importance and if it's broken, the Log Shipping process breaks too since it's not able to commit the transaction from the latest log backup from the primary database.
Safe Options (per your concern and requirements)
If you can ensure Azure Backup will not perform any SQL Server database backup operations, and you do NOT use it for any SQL Server specific operations or select it, then you will be fine.
I think you'll be safe to use Azure Backup for backing up files and folders, entire VMs, system state, or for bare metal recovery and won't have any issues with anything breaking the log chain with your SQL Server database backups.