Exchange Full Backup Problem !

[martimartin]

Hey Guys,

I'm in trouble with exchange backup ! i have faced with this problem third time !

i start full backup with veeam and after a while time Exchange Machine became invalid on Vcenter.

i cant access this machine ! i have a lot of job in veeam but just problem with Exchange job.

i cant access this machine ! Previous time i forced to close VM session on ESX with CLI then restart to host and it works.

but now i cant access this machine ! why it happens ? whats wrong ? whats the reason ?

[veremin]

Quick question - Is it the described situation happening during snapshot commit operation (closer to job end)? Thanks.

[martimartin]

when i notice it ..it was close to job end...about % 90.

[foggy]

Do you see the snapshot commit operation in vSphere Client at the same time?

[martimartin]

no job is done with error...no any commint operation.

Removing VM snapshot
Unable to truncate Exchange transaction logs. Details: RPC function call failed. Function name: [BlobCall]. Target machine: [192.168.15.71]. RPC error:The RPC server is unavailable. Code: 1722
Unable to truncate SQL server transaction logs. Details: RPC function call failed. Function name: [BlobCall]. Target machine: [192.168.15.71]. RPC error:The RPC server is unavailable. Code: 1722

[foggy]

Please contact technical support for investigation.

[jb1095]

no job is done with error...no any commint operation.

Removing VM snapshot
Unable to truncate Exchange transaction logs. Details: RPC function call failed. Function name: [BlobCall]. Target machine: [192.168.15.71]. RPC error:The RPC server is unavailable. Code: 1722
Unable to truncate SQL server transaction logs. Details: RPC function call failed. Function name: [BlobCall]. Target machine: [192.168.15.71]. RPC error:The RPC server is unavailable. Code: 1722

This is a known issue when snapping Exchange. This is the reason why you should be backing up a passive or tertiary copy of Exchange. While the backup itself goes ok, the snapshot removal from VMWare causes the Exchange server to go offline. This is most likely caused by slow storage. What type of disks is your exchange server running on? My guess is it is on a SATA aggregate and not a SAS aggregate. We resolved our issue by SVmotioning all our Exchange drives to the SAS aggregate on our SAN.

[martimartin]

This is a known issue when snapping Exchange. This is the reason why you should be backing up a passive or tertiary copy of Exchange. While the backup itself goes ok, the snapshot removal from VMWare causes the Exchange server to go offline. This is most likely caused by slow storage. What type of disks is your exchange server running on? My guess is it is on a SATA aggregate and not a SAS aggregate. We resolved our issue by SVmotioning all our Exchange drives to the SAS aggregate on our SAN.

The Exchange runs on SATA FC disk on 3PAR...Actually your words give me some ideas...i will do some analysis on 3PAR maybe there is something wrong which i havent noticed...Thank you..i will inform you after check it.

[Andreas Neufert]

Maybe these tips are helpful.
http://andyandthevms.com/exchange-dag-v ... plication/

Anyway you should avoid backing up any big VM with active full as it will let the VM snapshot open for a long time and snapshot coomit is more challenging.
This is no Veeam Problem. You can create a manual snapshot and let it open for the same time. Then delete the Snapshot and it will happen the exact same thing.

So create Incremental Forever backups and do Active Full once a quarter in a maintenance windows if you really want to perform one. You can use SureBackup for restore point testing.
In my blog above you can find a lot of tuning tips.

[albertwt]

Hi Andy,

I have multiple Exchange 2013 DAG mailbox servers each is running mixed of both Active & Passive database (no dedicated passive mailbox DB).

After the successful Veeam backup, the mailbox DB is activated in the Preference 2 so not on each dedicated/preferred server.
I have increased the cluster properties in this KB article: https://www.veeam.com/kb1744

So my question is:

1. Can I just exclude the Active mailbox DB VMDK in the Veeam backup ?
2. Does the Veeam backup snapshot will also "stun" the whole VMDK during the snapshot release thus causing the mailbox DB failover ?

[foggy]

Snapshot is created for the entire VM regardless of the exclusions.

[Andreas Neufert]

The only way to avoid this, is by setting the disks to independant, this way they will be not added to any kind of VMware based backup or manual created snapshot.

[Andreas Neufert]

regarding the best practices. Please double check as well with my blog post:
http://andyandthevms.com/exchange-dag-v ... plication/

[albertwt]

The only way to avoid this, is by setting the disks to independant, this way they will be not added to any kind of VMware based backup or manual created snapshot.

That sounds dangerous since the content of the data will be gone after the server reboot ?

[albertwt]

Snapshot is created for the entire VM regardless of the exclusions.

Thanks, Alex,
I guess there is no other way to prevent the failover other than set the backup to use the slow network stack.

Or maybe use the Storage Array Snapshot technology which means I will need to convert my existing Thick LUN-Thick VMDK into Thin-Thin, to get the full benefits of the snapshot for faster and quicker Veeam backup.

[Andreas Neufert]

Independant disks do not lose data. => See differences described here: https://communities.vmware.com/thread/511108

I guess there is no other way to prevent the failover other than set the backup to use the slow network stack.

So I guess you speak about that you do HotAdd processing? Do you use NFS storage?

Or maybe use the Storage Array Snapshot technology which means I will need to convert my existing Thick LUN-Thick VMDK into Thin-Thin, to get the full benefits of the snapshot for faster and quicker Veeam backup.

There is no need to change this if you have space for the snapshots on the storage. Change Block Tracking backup will create alway incremental backups with our Backup from Storage Snapshot technology.