NEW FEATURE REQUEST: in a backup job a new option to process VMs sequentially instead of in parallel

[ditedisi]

We know this is a long-standing problem affecting thousands of users, but I hope you've found a permanent solution.

We have a daily backup job that contains all the Exchange infrastructure VMs. They are all Microsoft Windows Server 2025-based VMs.
One of these VMs is the Exchange Administration Console server.
The other two are the only members of the only infrastructure DAG,
The infrastructure has four mailbox databases, divided equally between the two mailbox servers. SERVER-1 has DB-1 and DB-2 as active databases, and DB-3 and DB-4 as passive databases. Obviously, the other server has the reverse.
Every DBs is in a different HD.

Not always, but almost every day, the job terminates with a WARNING: "VSS: Backup job failed. Cannot notify writers about the 'BACKUP FINISH' event. A VSS critical writer has failed. Writer name: [Microsoft Exchange Writer]. Class ID: [{XXXXXXXXX}]. Instance ID: [{XXXXXXXXX}]. Writer's state: [VSS_WS_FAILED_AT_BACKUP_COMPLETE]. Error code: [0x800423f3]."

This occurs because the job processes all disks on all servers in parallel. Therefore, it processes the active and passive databases simultaneously.

Veeam's solutions for this long-standing problem are:
1) Split DAG VMs into different jobs
2) Create a proxy server to be used only for this job, with the task count set to 1
3) Use "copy only" on one of the two DAG members

These aren't solutions for us, but rather workarounds that we don't accept for various reasons.

All it would take is a flag in the job settings that says "Backup JOB VMs sequentially instead of parallel!" Something so that only when it've finished processing the first VM can it start processing the next one!

Why has this solution never been considered? It would solve all the problems!

Thank you so much


I hope you have a solution.

[PetrM]

Hello and Welcome to Veeam R&D Forums!

Actually, I don't think we should address this specific DAG problem by introducing new algorithms at the level of our internal task scheduler. Furthermore, I'm not sure I can think of any other cases besides the one you described above.

But what if we stay focused on this specific problem? For example, we could analyze the DAG topology and suspend the task for one node while another node is being processed. What do you think?

Thanks!

[ditedisi]

Hello and thanks for your reply.
Since your experience is certainly longer and more extensive than mine, I can only believe you when you say ((referring to the DAG problem, I assume): "I'm not sure I can think of any other cases besides the one you described above."

But, put like that, it might seem like mine is an isolated case. But that's not the case. My problem is the problem of thousands of other customers. Just do a search online...

So I disagree with you when you say that you "don't think we should address this specific DAG problem by introducing new algorithms at the level of our internal task scheduler."

That said, since you want to help me to find a solution through other means, I'm available to discuss it.

In your example, "suspend the task for one node while another node is being processed," how do we suspend the task on one node without knowing and being able to control when the other is processing?

See you soon. Thanks!

MAC

[PetrM]

Hello,

Many thanks for your reply.

how do we suspend the task on one node without knowing and being able to control when the other is processing?

My idea is to analyze it in the background and automatically suspend one node for a certain period of time, so you won’t need to perform any additional manual steps.

Thanks!