Process VMs sequentially for a single job

[JoshuaPostSAMC]

I see where I can enable or disable parallel processing for the entire Veeam backup server from this article: https://helpcenter.veeam.com/backup/vsp ... ssing.html

Is there a way to force a single job to process VMs sequentially to the same repository as all other jobs, without disabling it globally for the backup server or setting up a separate repository?

We have one job backing up 3 SQL servers in an Always On configuration, but they all run at the same time and cause things to freak out during that time window. The thought is that processing them sequentially would cause less disruption as all members wouldn't be backing up at the same time.

[Gostev]

The easiest way to achieve this is by pointing this job to the dedicated backup repository with a single task slot allocated. You can create this repository on the same volume as you "normal" repository, by pointing it to the dedicated subfolder. Thanks!

[ferrus]

Sorry to dig up an old thread - but this is the one I referred to when setting up our new Veeam deployment.

Using this method works great for the main body of the backup job, and does process each server sequentially. It also keeps the job list tidier, than having to have separate jobs, chained to each other.

One thing I've noticed however, is that there appears to be an initial VM snapshot taken at the same time - for each VM in the backup job. This is prior to the data being backed up.
It's most noticeable when the VMs in the job are queued waiting for the repository to become available, and yet have all had a VM snapshot created and removed.

This could cause issues with Always On SQL servers, and Exchange DAG member servers.
We're currently looking into if this is the cause of our problems, and without a proper setting for backing up VMs in a job sequentially - we might have to return to multiple chained jobs.

[PTide]

Hi,

Would you elaborate on this one, please?

It's most noticeable when the VMs in the job are queued waiting for the repository to become available, and yet have all had a VM snapshot created and removed.

So, do you see the snapshots being created and then instantly removed, or do they stay until the job finishes? If the former, then do you utilize storage snapshots in the job?

Thanks

[ferrus]

Here are the steps:

Code: Select all

Creating VM snapshot
Getting list of guest filesystem local users
Collecting disk files location data
Removing VM Snapshot

We're using Storage Integration for these particular jobs, as the snapshots can grow huge, while backing up >20TB. Then the snapshot removal can take several hours.
Besides this, I don't think the length of time a snapshot resides on a VM is the issue with SQL AAG and Exchange DAGs - it's the fact the snapshots occur at the same time.

[foggy]

This is due to the fact that storage snapshot needs to be taken for all VMs. You can limit the number of VMs in the snapshot by 1 to process them sequentially.

[ferrus]

Thanks foggy - this occurred to me too, earlier today.
I'll try it out tonight, as up to now I've been taking quick backups of the servers sequentially, after the job completion - to get the transaction logs deleted.

Hopefully this will prevent any failovers.

[ferrus]

No, the same snapshots at the same time.

I think they happen prior to the SAN snapshot?
Two are marked as pending, but all three have had a VM snapshot created and removed at the same time.

Are chained jobs still the only solution?

[foggy]

This doesn't look expected, please contact technical support for verification.