Let me preface this by saying that I am new to Veeam. I started working with it about a year ago starting with v10. I work for an MSP where most of our clients have 20 or less VMs with typically less than 3TB of data. The typical setup is to run the VBR server as a VM with the backup repository as a local volume mapped via iSCSI to a Synology NAS. I have migrated 18 clients over to Veeam so far.
With v10 I ran into an issue where I had created a separate backup job for VMs that we wanted to backup hourly and found that sometimes that job would get stuck "waiting for backup resources" and wouldn't run every hour. So I setup a new repository folder on the local D volume and created a new repository. Then I lowered the maximum concurrent tasks for each job to stay within the overall limit. This is now kind of a moot point with High Priority jobs in v11 however I wanted to know what the accepted best practice is for this. Looking at some of my clients I was setting up a backup repository per job with the thinking that no job would be able to block another job from running. This doesn't seem correct to me now looking back on it. What is the best practice for when to create a new repository or how many to have on a single physical device?
Looking at some of my clients I was setting up a backup repository per job
that sounds complicated
What is the best practice for when to create a new repository or how many to have on a single physical device?
something between 200-400TB is what our architects recommend. Many customers go beyond that. The number of repositories on one storage is irrelevant from a Veeam perspective. I recommend KISS (keep it simple)
Best regards,
Hannes
PS: I edited the title to storage. because you use iSCSI and when people read NAS, they expect SMB / NFS.
PPS: I assume you use REFS https://www.veeam.com/blog/advanced-ref ... suite.html - if not, I recommend to also switch that if you re-design
Thanks for the reply! Yes, I found out after about a month that ReFS is the only way to go which is why I went from using SMB shares to ReFS over iSCSI.
