The overall size backup data is around 40TB. My question is, from performance perspective, what is the best practice to present volumes for use as backup repository. Is it better to:
1. Present one large 12x14TB volume. All backup jobs go to one repo.
2. Present smaller volumes, for example two 6x14TB. Half backup jobs backup to first one, and the other half backup to second one.

I would like to hear your advice. Thank you very much in advance for your time and help.

The disadvantage of several smaller volumes compared with one larger one is that it is possible to have more wasted space. This is because jobs cannot split between two repositories, even if you amalgamate two or more repositories into a Veeam 'scale out repository'. If you had a multi-terabyte full backup file it would have to fit squarely into one or other of your repositories. With a scale-out repository (where you join smaller repositories together within Veeam) the backup files on the repositories underneath will have to be channeled to one or other of the repositories. It is possible to have incrementals and full-backup files on separate repositories when you have scale-out enabled. What you lose is the bit of empty space at the end of a volume which isn't big enough to fit a backup into. This can be many terabytes depending on your configuration and the kind of data you're protecting.

With split repositories it is possible your system might not let you share a hot-spare disk with both arrays? So you might lose one of the physical disks... depending on the system and how you configure it.

The advantage of several smaller volumes compared with one larger one is manageability in a recovery or upgrade situation. If an array somehow fails for whatever reason and you have to migrate the jobs off the volume to rebuild it or if you want to upgrade to Windows Server 2019 and want to reformat with the later version of ReFS (for example) then it's less data to move out of the volume. Worst case, if you happened to lose a volume for some reason it would be only half your backups gone rather than all of them!

I've got both kinds of configuration and I'm running out of space on both, there is more wasted space on the split system than there is on the continuous one. So when I set up my next repository I'm drawn more towards setting up the next repositories as continuous volumes. There tends to be a larger number of failure points within a larger volume so it's a bit more risky.

Don't forget to make sure you format your volumes following guidelines from Veeam. You have to set the right cluster size and some other things.

The disadvantage of several smaller volumes compared with one larger one is that it is possible to have more wasted space. This is because jobs cannot split between two repositories, even if you amalgamate two or more repositories into a Veeam 'scale out repository'. If you had a multi-terabyte full backup file it would have to fit squarely into one or other of your repositories. With a scale-out repository (where you join smaller repositories together within Veeam) the backup files on the repositories underneath will have to be channeled to one or other of the repositories. It is possible to have incrementals and full-backup files on separate repositories when you have scale-out enabled. What you lose is the bit of empty space at the end of a volume which isn't big enough to fit a backup into. This can be many terabytes depending on your configuration and the kind of data you're protecting.

Thank you EJ, that's very solid suggestion. I think I will eventually go with one volume.

If you choose ReFS, I would suggest having a look at the post below - it may not be specific to your environment or goals but I think it would provide some context for ReFS. It seems that ReFS v3 has gone through some teething problems, but these appear to be resolved.

We have a similar setup, but with 5x C240 M4 LFF servers, poulated with 6TB HDD.

The advice given above is pretty much where we ended up, after several re-configurations.
1x RAID6, ReFS formatted volume, grouped across all servers into a single SOBR.
Additional 12G RIAD controllers were required, as the basic M4 system only allowed RAID 0,1 or 5.

Just be careful about the defaults for strip size, cache settings etc. The standard settings (particularly when UCS integrated), were the worst possible for Veeam/large vbk processing performance.
We increased the repository performance severalfold, by re-formatting and updating these settings.