vSAN with fault tolerance (FTT) = 1

[john.wood]

Wanted to put this out to the forum to see if anyone else is having a similar issue.

Setup
vSphere 6.0 + vSan 6.2
FTT value = 1

I have a VM with 1x70gb disk, usage is 50% (35GB used)
with FTT = 1 the VMDK = 143gb in size.

Veeam shows the VM at 140gb, the backup size is 72gb in size.

Given Veeam's inline dedup and compression I would have thought it would look at the VMDK with a large amount of duplication spread across the vSAN.
Why would it require 72gb when only 35gb is actually used?

Thanks John.

[bhagen]

I'm in a similar position and interested in this as well, so subscribing to this thread!

[john.wood]

I've since raised a case : 02277676

[bhagen]

I'd love to hear the outcome; would you mind posting a summary here when the ticket is resolved?

[john.wood]

The support tech said that he'd only ever seen one other instance like this before.
Veeam don't have a root cause or any documentation as to why its happening.

The thought was there is a "glitch" when reading the VM in the database.

Resolution:
Move the backup (and/or) copy job files to another location.
Remove the backup from configuration in Veeam.
Start a new chain and manually age out old backups.

Conclusion:
Not an ideal outcome to have to re-start the chain. Our customers are charged on the $/gb of vbk's & vib's.
So when a server is twice the size and they pay double they are not very impressed as you can imagine.

[foggy]

Hi John, are you saying that restarting the chain fixed the sizing issue? We're not able to reproduce this in or lab, the FTT VM shows its actual size and the backup size also reflects the size of a single VM, just like for an ordinary VM without FTT. Could be some database glitch, indeed. We're trying to check on vSAN right now.

[john.wood]

Thanks Foggy,
Appreciate the follow up.
I'm in a bit of a sticky situation.

My customers are not very understanding and now questioning all of the backup data costs, due to this one instance.
At this stage I have to say its a "glitch" which we are unable to pinpoint and no way of identifying if it will happen again.

Happy to provide more logs or information on the case if you need it.

Cheers

[bhagen]

Well, more than a year later I'm back to this post. I've built 6 new hosts with esxi 6.7 and vsan 6.6, migrated all vms from our 6.0/6.2 environment to the 6.7/6.6 environment, set every vm to FTT=1, and continued doing VBR 9.5 backups.

And still, my veeam jobs report the FTT=1 size of the vms; not the sized of the drives that Windows / Linux reports.

However, the actual backup files are the "correct" size...they reflect the size of the used data that Windows / Linux sees.

I guess I can understand that; since Veeam is only using the vmware apis, and in vcenter the vm sizes are reported at the FTT=1 size.

Just an update in case anybody else just ran out of space on their backup NAS, recalculated the sizes of their backup jobs, and asked their boss for more hard drives...