Parallel Processing & Microsoft Exchange DAG

[kmount]

Hi all,

Hope you’re all week on this cold and wet weekend.

I wrote the below up for the Veeam team to consider once V7 was released with parallel processing and it has been suggested to get some community feedback on the request:

Request:

“Can we have per job control of parallel processing instead of a global on/off?”

Scenario for use case:

Veeam customer who has the following backup jobs split across two proxies / repositories:

vCenter (via direct ESXi connection) <- (Yes we could look at transparent VC backup but that’s one for later)
Windows Production VMs
Linux Production VMs
Windows Test & Dev
Linux Test & Dev

All of the above work fine sequentially and we see great dedupe and compression rates together with more than acceptable backup window duration.

We then have the curveball, the customer has an Exchange DAG set up which is comprised of two mailbox servers, and two client access servers.

The mailbox servers are running active/active (Staff active on MBoxSvr1, passive on MBoxSvr2 and then Students active on MBoxSvr2, and passive on MBoxSvr1) split over two SANs (storage snapshots not available) for resiliency. (Each mailbox store is 1TB)

Currently we back up the four servers together in a single job to reap the benefits of dedupe/compression since we have two copies of identical data, this is then truncated quite happy by Veeam as there is at least 30 minutes 'time' in between truncate operations against MBoxSvr1 and then MBoxSvr2 so the cluster stays in sync and everything is happy. (the dedupe rate is fantastic!)

I've read through the knowledge base article and forum discussions around backing up Exchange with Veeam and I think in an active/passive single mailstore instance it would make complete sense to always back up from the slave side (like a sideways slave database backup, it makes sense).

Enabling parallel processing in the normal jobs would be fine as there is nothing in there cluster aware so we'd just enjoy the great benefits but our worry is that if we try and back up the exchange job in parallel mode we run the risk of trying to send truncates to both exchange systems at once and hurting the setup.

So we have a few options:

- Enable Circular Logging on the Exchange setup and forget about truncation, which could hurt us in a recovery scenario
- Leave parallel processing disabled

I’d really like to have parallel processing for everything except our Exchange job so we continue to keep our known safety net here whilst improving performance further across the other jobs.

Any and all thoughts welcomed

Thanks for reading.

Kim

[kmount]

I should add that there is not a case open for this to provide a ref for as this is purely for discussion. (acknowledging the requirement for a case ID to be provided for technical issues)

If folks think that this is a worthwhile avenue to go down nonetheless I will open a low priority case referencing this thread for input.

Thanks all for considerations.

[Vitaliy S.]

Kim, case ID is only required if you're posting errors or experiencing technical issues with the product, so there is no need to open a support case in this situation.

Thanks for such a detailed feedback!

[Gostev]

I've split it back from this discussion into a separate topic.

First, the actual issue with parallel processing of both sides at the same time is unconfirmed - I'd like to hear from users who are doing this already. Second, even if the issue is confirmed, it still would not be a driver for controlling concurrency on per job level. Rather, we could simply enhance our scheduler’s logic to detect DAG VMs and prevent both sides truncating logs concurrently when parallel processing is enabled.