Exchange 2019 Dag backup in vmware

[ousturali]

Hi to all
ı read a lot about exchange DAG backup, some says install agent, some says insert all Dag members in one job,some says seperate the DAg member in each seperate veeam job.So things got complicated somehow.

In the end,i decided to go with all DAG memmbers in one job, without the agent (since its a virtual machine) ,and with storage integrated snapshots.

and yesterday i got this error

(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: [{76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}]. Instance ID: [{20486fdc-83bf-493d-a740-829b11758067}]. Writer's state: [VSS_WS_FAILED_AT_BACKUP_COMPLETE]. Error code: [0x800423f3].)

THere are some solutions for that, like , reboot IS service, reboot vm, get details into the VSS writers.
Some says, create a seperate backup,

Does anyone can lead the me the correct way.
Thanks a lot

[Andreas Neufert]

The root cause of this error is that VSS can not commit the transaction logs, which can be caused by many things.
There are many root causes for this, but regularly there are these two:
- You have dismounted databases. Please check within the Exchange Management
- Cluster failover happening while VMware Snapshots are committed. This is usually caused by default Failover Cluster heartbeat settings that are set too aggressive to be able to cover VMware DRS, Storage vMotion, vMotion and VMware Snapshot processing.

Please check my blog with all kind of tips and tricks and configuration best practices: https://andyandthevms.com/exchange-dag- ... plication/

[Regnor]

I often see those errors because two or more DAG members get backed up at the same time. So my recommendation is to make sure that you only backup one member server at a time.

[Andreas Neufert]

What Regnor said is a result of multiple cluster failovers happening at same time when the failover cluster heartbeat setting was not set correctly for VMware processing.

[Regnor]

In my cases a failover didn't occur. So my theory was, that both Exchange tried to truncate the logs at the same time. For the first one it succeeded, while the second one could no longer find the corresponding logs.

[Andreas Neufert]

You can commit logs at same time on both sides without issues. It was not the root cause.

[Klarmann]

I had my Exchange DAG (two nodes, DBs1-24 with uneven numbers on node1 and DBs with even numbers on node2) also in one job first and got errors. Then I did one job for each DAG member and chained them. Since them .. no problems.

Ah yes ... no Agent installed, because of VMs. Snapshots are Storage Snapshots

[kylecpcs]

You only need to backup one dag member when it comes to exchange. It will notify all the other members that it has been backed up and will trunc all log files across the cluster. After that, any reporting will say all 3 nodes have been fully backed up. Active Directory stores all the needed info for a full restore of any node that might fail (powershell reinstall). You can't restore a full cluster member from a Veeam image anyway, because the cluster will reject it. So the data is all you really need.

I've been doing exchange and veeam for multiple clients for over a decade and this is always how we set it up or recover from a failure. We usually only backup the node in DR and not the ones in production. Works every time.

[Andreas Neufert]

I agree that the below is a valid setup, but I would always backup all cluster members so that you can use SureBackup, labs and DR of the whole environment. If you use labs or DR of the whole environment the Exchange services will come up only automatically when you restore multiple DAG members. Of cause you can force things manually but you need to know what you do then.

When you use our Guest Processing, the restore of a server (with boot and network enabled to kick start VSS recovery automatically) as replacement of the faulty one, should automatically add the server to the DAG again and DAG will heal the situation and replicate the missing data. Kyle please share your situation on where this was not the case so that we can look at this.

[kylecpcs]

While true, I would not use Veeam for Exchange DR. You already have a DAG, so stretch the DAG to DR and failover the built in way. Much faster and simpler with up to the second of failure data. MUCH easier failback as well.

[Regnor]

If you have the possibility to build a DAG over multiple locations, it certainly increases availability during a disaster.
But still I would backup all members or at least a majority to be able to recover during a disaster where the whole environment is down.
You could also get it back running with just one member, but you'll already have enough other tasks, so why mess with this?

On the other hand I rarely see cases where you really need to restore an Exchange server from backup.
Most problems or issues can be solved, and even after a failed update you'll most likely be able to repair it.

[Andreas Neufert]

Not backing up Exchange is a no go.

Just think about Ransomware or human errors (happens all the time to the best of us).

Logfile Truncations are as well something you need to handle.

[Regnor]

Absolutely, backing up Exchange (like any other application) is a must, no matter how high available it is.

I still remember Microsoft recommending a DAG+lagged Copy over "traditional backups"
Replication is not a backup, regardless if it's synchronous or asynchronous.

Depending on the requirements of your organization, it's quite likely that a pure Exchange 2016 or Exchange 2019 environment with at least three mailbox database copies will provide lower total cost of ownership than one with backups.

With all of these technologies in play, traditional backups are unnecessary; as a result, the PA leverages Exchange Native Data Protection.

https://learn.microsoft.com/en-us/excha ... erver-2019
https://techcommunity.microsoft.com/t5/ ... a-p/604024

But I think we're getting more and more off-topic now