Veeam Job Size or File Size limit?

[edfops]

Looking for input recommendations for job sizes, would a job containing 16TB of VMs be too big for Veeam to handle in one job or reverse incremental chain?
If it is, what is the cutoff/guidelines to split things up?

I do expect a Full to complete well within 24 hours based on the infrastructure we have in place and some testing with smaller batches (4TB or so) of similar VMs, and the change will only be ~200GB per day.

[Shestakov]

Hello,

Looking for input recommendations for job sizes, would a job containing 16TB of VMs be too big for Veeam to handle in one job or reverse incremental chain?

Is it too big or not depends on your infrastructure capabilities, target and transport mode.
For situations like yours Veeam B&R has a storage optimization option. This option provides the lowest deduplication ratio and produces the largest incremental backup file.

If it is, what is the cutoff/guidelines to split things up?

There is no limit for a backup file/job size.

Thank you.

[tsightler]

But from a practical perspective I generally like to keep jobs around 4TB maximum size (i.e. roughly 8TB of source data if using Veeam compression). Many storage systems perform poorly with very large file sizes and the larger the files the more likely to hit various file system limits not related to Veeam.

Also, you need to plan for the ability to occasionally run active full backups. If you have one huge 16TB backup file you'll need the space to keep two of those for your entire retention time. If on the other hand you have 4 backup files of 4TB each, you can stagger full backups and potentially only need 4TB of extra space at any one time. Also, it can make it easier for things like offloading backups with backup copies or if you want to reorganize jobs in the future, for example split to two different repositories.

That being said, it sounds like you have very minimal change rate and it's certainly possible that a single job with all of those VMs will work fine for your use case, but the above are best practices developed based on years of deploying Veeam in the field. Since the release of V7 there's been a general trend toward larger jobs and overall they have worked well, but the practical considerations of managing those huge files can be an issue.

[edfops]

This is good input thank you. Considering we will leverage VM Folders to define what job backs up what VMs, splitting these out into some smaller fragments sounds like the smarter plan long-term.

[dejan.ilic@liu.se]

As Windows deduplication has 1TB maximum (NTFS) or 4TB (ReFS Windows Server 2019) filesize, splitting the Veeam backup files after reaching a pre set value would be very usefull feature.
We have a 21TB fileserver, and everything but the first 4TB is not deduped by Windows due to the limit, so the first fullbackup is just eating up the storage space..