From what I can recall from talking to consultants and support in the distant past, there isn't really any obstacle to creating backup jobs with 50-100 VMs per job is there?
Heres what we are doing right now, which Im looking to optimise and remove the need to have any admin overhead such as adding VMs to jobs. Please point out if any of my assumptions or plans are wrong.
We are running Veeam 6.5 u3 (9.5.0.1536) with VMware clusters running 5.5 u2
We have a number of backup jobs taking VDI VMs (approx. 25 per job) from our clusters, with each job writing to a different folders within the same CIF share from a production NAS
The target repositories all map the the same common CIFS share.
The VDI VMs vary generally from 30-60GB each. The complete set of VMs all live within datastores of a similar size, in which nothing else but these VDI VMs exist. Each DS contains around 150 VDI VMs.
All connectivity between Veeam and repos is 10gb Ethernet.
All cluster hosts (multiple Blade Chassis) is 10gb eth for connectivity and 10gb fibre for storage.
Due to a couple of admin oversights its transpired that some VMs weren't getting backed up when they should have been. To simplify this, Im looking at creating 1 job per datastore which targets the datastore, thus capturing any VMs in that datastore.
There is ample space in the target repo, after all its the same quantity / size of VMs, and I have a few TB overhead free. Also all backups are forwards following best practice.
So, are there any known clangers creating backup files this large?
Should I enable per-VM on the repo's to mitigate this, or am I OK?
The proxies / repos are set with appropriate number of tasks to not throw fits, im getting a comfortable 6-8 parallel tasks running per proxy.
Aside from the obvious "upgrade VMware" advise to sort out the horrific CBT issues at this version, which is already in plan, any recommendations are greatly appreciated.
O