I have a virtualized Windows Server 2019 instance configured as failover cluster node with SQL Server 2016 Availability Group node running on it. I have already set up "traditional" SQL server backups with a regular full / diff / log backup schedule.
Now I am wondering if it would be possible to use Azure Backup to backup the entire Windows Server instance in order to be protected even better from a possible ransomware attack (as documented here.
I do not want to replace my regular backup strategy, but add an additional backup method without breaking the existing setup. Would this work with Azure Backup for Windows Server, or would it interfere with my current backup strategy?
Edit: To clarify why I asked this question in the first place: I want to know if setting up Azure Backup would break my existing full / diff / log backup chain since both backup methods might use VSS.
Best Answer
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. . .
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.
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.
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.
Supporting Resources
Back up system state and restore to bare metal with Azure Backup Server