backup to disk, what's your datastore size? over 2 TB?

[Dude]

Since Veeam does not de-duplicate across the entire backup repository but only across a backup job one needs to include many VMs (at least those who have the same OS version) into the same backup job if one wants high dedup ratios. Many VMs per backup job in turn means that target datastores have to be fairly large.

What's your datastore size? Do you use datastores which are larger than 2 TB?

It seems like the larger the datastore the higher the probability that either something will go wrong with it and that when something does go wrong with it then a large portion of the backups will be affected. Of course there's more than one backup location, but still, this is about the primary repository.

Thoughts?

[Vitaliy S.]

As far as I remember many people are using iSCSI initiated NTFS volumes to store their backups and the size of these volumes is usually above 2 TB.

[Gostev]

Just in case you are thinking of backing up into VMDK attached to backup repository VM, remember that backing up into VMFS is considered a bad practice. You are basically locking the keys in the car by doing that.

[Dude]

I can see how this is the case if the VMDK is part of the vSphere environment that's being backed up, but if the repository is being accessed from a stand-alone vSphere environment on a separate storage array then is this really the "locking the keys in the car" case? Sure, a functioning vSphere environment is required to restore but the benefit of having the backups in a repository VM and being able to move that around easily seems fairly significant?

[Gostev]

but if the repository is being accessed from a stand-alone vSphere environment on a separate storage array then is this really the "locking the keys in the car" case?

No, this approach is rather about adding much unneeded complexity and costs (due to having to maintain separate environment) and reducing reliability (due to more moving pieces that may contain bugs) for no good reason. For example, imagine a hypothetical scenario when vSphere update introduces silent VMFS corruption bug. By the time you notice data corruption in the production vSphere environment, you are likely to have your backup data corrupted in that separate environment as well.

The rule of thumb is that for recoveries, data protection solution should not in any way rely on the system that it is designed to protect. This is because an issue that caused the disaster is somewhat likely to make the recovery impossible, or at least significantly complicate it.

As to the perceived benefits of your planned approach, they are not so great comparing to what you will achieve without introducing VMFS into the picture.

For example, you can even more easily attach the NTFS LUN holding your backups to another server, or even your laptop (should the need arise), and get access to those backup files. I know one customer who did exactly that, which allowed him to spin up domain controller and Exchange on VMware Workstation on his laptop, and run them for a few days while troubleshooting issues with the production cluster (where VMs just would not start due to vSphere bug). True story! Same issue in your scenario means a few days of downtime.

And if you were talking about moving the repository to another physical storage, then again - extra vSphere layer only complicates things. Because with raw LUN, all it takes is just copying backup files with Windows Explorer. This works so much faster, because there is no VMFS in the picture. And does not depend on Storage VMotion, if this is what you are thinking of using for "moving that around easily".

Simplicity always wins complexity in every way.

[Dude]

Thanks for the detailed write-up Gostev, you make some really good points. I'll reconsider our current approach.