AlwaysOn, "copy only" on secondary node

[DanielJ]

I read this in the docs:

> Image-level Backup of Microsoft SQL Server VMs
> During image-level backup of a Microsoft SQL Server VM, Veeam Backup & Replication requests and analyzes information about databases that are included in the AlwaysOn Availability Groups. Depending on the retrieved information, Veeam Backup & Replication creates a VSS snapshot with or without COPY_ONLY flag. The VSS_BS_COPY flag for VSS snapshot is triggered if the VM represents a secondary node for at least one AlwaysOn Availability Group.
>
> Veeam Backup & Replication also detects to what cluster the database belongs. If the backup job does not include all VMs from the cluster, an information message will be issued.

When backing up an AlwaysOn group, and selecting to truncate logs, I have to manually select "Copy only" on the secondary node, or I get warnings that logs could not be truncated on that node. Am I missing some setting?

[DanielJ]

In another setup I have inherited, there are two AlwaysOn nodes each in their own job, both set to backup logs. One of the log backup jobs do not back up anything but instead warns that the other job owns the log backups. It sounds about right, but what would happen if this cluster is failed over? Would then the log backups start going to the other job? If a log restore is needed, would Veeam be able to combine the log backups of the different jobs? I did read that it's recommended to have both nodes in the same job, but if it will work anyway then I won't have to change anything.

[foggy]

Hi Daniel, placing AG nodes in different jobs is not recommended and can cause issues. You may backup a single node or put all the nodes in a single job for proper transaction logs handling. Thanks!

[ferrus]

In another setup I have inherited, there are two AlwaysOn nodes each in their own job, both set to backup logs.
One of the log backup jobs do not back up anything but instead warns that the other job owns the log backups.

Was about to place a support call/start a thread - on the same issue.

We have recently created three separate Veeam Backups Jobs, placing a node from each of our three-node AlwaysOn Groups into each job.
The jobs were then chained to start in succession (but never at the same time).

The reason for us doing this, was to avoid VMware snapshots occuring on two or more VMs in an AlwaysOn Group, at the same time.
Although quite rare, this can happen.

On a previous forum post regarding an Exchange DAG - we investigated several workarounds to prevent concurrent VMware snapshots (only allowing one concurrent repository session, one proxy session etc), and while they would stagger most of the tasks in the job - the VM snapshots could still overlap between DAG members.
Chained jobs were found to be the only guaranteed way to prevent overlapping snapshots.

Is there no way to resolve this, but to place the VMs in the same job?

[foggy]

Limiting the max number of concurrent tasks is a more proper approach. Since VMs are processed by the job in the order they are listed in the job settings, to make sure there are no concurrent VMware snapshots for the AG nodes, you can 'dilute' them in the list with some other VMs.

[ferrus]

Only is some cases however. We used to do this - before Storage Integration.
Once that was enabled - the timing of the VM snapshots isn't respected, and there's little that can be done to prevent it.

There's the option to limit processed VM count per storage snapshot, but even that has an exclusion for VMs in the same datastore.
There's the option to limit only one job per repository, but that means creating a new repository, and which breaks our exiting SOBR.
And all the workarounds, end up negatively affect performance by a considerable amount.

It seems a shame that there isn't an option anywhere - a manual registry key, or some guest-aware logic - to prevent overlapping snapshots in a cluster.
For a system designed around Exchange/SQL backups, it's annoying to have to resort to workarounds, and creating artificial bottlenecks - just for them to break another design limitation.

[backupquestions]

Please see the opening post from this other person's thread. veeam-backup-replication-f2/alwayson-co ... 64011.html

It seems that Veeam can handle sql always on cluster without needing agents at all which is great. So I have a 2 node setup both vms and not using agents.

What I am seeing is the behavior of the person in that post. Veeam truncated the primary cluster member as it should, but then it tries to truncate the logs on the secondary member which it should not be doing, since it should be doing only a copy of those logs.

It does not appear to behave as it says it should in documentation. This is veeam 9.5 4b and yes both cluster members are in the same backup job. It correctly sees them as availability group databases when I go to restore so it seems to be detecting properly.

[foggy]

Hi Alabaster, any chance it is Basic Availability Group? And if yes, are we talking about VMware or Hyper-V environment?