ну если учесть, что штанов я у них не припомню, как тока будут кеды - я в принципе укомплектован :))

и в нетапках ))

А в кармашек можно положить распечаточку эмблемки Cvtl, и проходя мимо их стенда такой "хайль гидра!" шепотом

Я всю одежду и сумку veeam раздал, да и танцую плоховато

Сайзинг VeeamBR proxy.
https://helpcenter.veeam.com/docs/backup/vsphere/system_requirements.html?ver=110
Ожидание | Реальность.

я вот давно смотрю на эту табличку и у меня ощущение, что мы её неверно читаем. не 2Гб + 200 на каждый таск, а 2.2 на каждый таск. по крайней мере если юзать сайзер или как говорят на vmce-ado - ram=cpu*2  и это больше похоже именно на моё предположение

Логичнее было бы всё же писать "2200 MB per task", но на скрине выше и это не работает.
Я как бы не против отсыпать памяти, но чтобы сколько требуется, а потом спокойно спать без своппинга.

ну заведи кейс - пусть тебе отетят - какого Х оно стока ест, вот и узнаешь

Кстати, а один вим может служить проксей другому виму?

Грубо говоря один в офисе стоит, второй внешний

может

Погодите, кроме vbr на сервере есть роли какие-то ещё?

THE WORD FROM GOSTEV
I thought I'd share a few semi-useful data points from our support big data (obtained through mining debug logs uploaded to support cases) here today. I mean, they were extremely useful to me from the product management perspective, but they are also quite curios in general – and perhaps some will be interesting for you to see how you stack up against other Veeam users!
First report is about typical machine sizes in image-level backups, and more specifically the used space in their disks – so actual useful production data being backed up. I initially requested this report to see how our NAS backup licensing (500GB per 1 VUL with V11) stacks up against using an image-level backup to protect the entire machine instead, which also consumes 1 VUL. According to the big data, the median used space in all machines protected by Veeam is around 200GB. As a reminder, median is different from average, and it means exactly half of all machines have less, and another half have more. Further, the upper quartile is 530 GB – meaning, 75% of all machines have less than this amount of data in their disks. And considering some dozen GBs are operating system and application files that won't be included in the file-level backup, this indeed puts V11 NAS backup weight per VUL in a good place in comparison to using an image-level backup... especially since the first 500GB of data from each data source does not consume a license at all.
When looking at the extremes, 7% of the smallest machines have under 20GB of data, and 7% of the biggest machines have over 2TB. Also, almost 1.5% of machines have over 10TB – which in absolute numbers means that hundreds of thousands of protected machines are what they call "monster" VMs and servers. So, the machine size is definitely not a concern with Veeam (it has been a very common question on the forums).
Second report is the restore options popularity. If we look at the percentage of users who used any given restore option at least once, the top 5 goes like this:
75% did a file-level recovery (63% Windows and 12% Linux)
40% did an entire VM restore
37% did an application item recovery
21% did an instant VM recovery
16% did a VM file or VM disk restore
[These are not supposed to add up to 100%]
However, if we look at the total number of restores performed, the picture changes a bit:
55% of all restores were file-level recoveries (50% Windows and 5% Linux)
17% of all restores were application item recoveries
14% of all restores were entire VM restores
4% of all restores were instant VM recoveries
2% of all restores were VM file or VM disk restores
[These do add up to 100% with the remaining restore options]
So as expected, nearly three quarters of all production restores are granular restores – which is where Veeam has always particularly shined. What was interesting to learn though, is that in case of full VM restores, users are a few times more likely to choose a full VM restore over an instant VM recovery. However, perhaps the previous report explains why this is so - most machines are simply not that large, and can be restored in just a few minutes regardless of the approach. I mean, even at just 350 MB/s, half of all VMs out there can be restored in under 10 minutes even without instant recovery, so I guess why bother? Looks like instant recoveries are only used for those "monster" machines specifically.
Finally, to finish off nice and sweet – what are the top features from the support load perspective? The most reliable major feature generating the least support cases is currently the SOBR Capacity Tier, while the biggest source of support cases are Backup Copy jobs. So, it makes me quite happy that the former allowed many customers to completely get rid of the latter, as the ratio of support cases is like 1 to 100 between these two features. This also shows why we decided to bite the bullet and make all those "painful" changes to our Backup Copy jobs in V11 in order to simplify its engine.

Now we have just a few more tweaks left to make to Backup Copy jobs in V12, at which point it should hopefully become equally robust.

Что-то в этот раз апдейт не пошел - инсталлер сервера вылетел на середине, а VE засрал весь журнал попытками запустить IBMSPDerby с только что удалённой версией JRE