Эх...

Кто ж виноват, что ваш кейс выглядит как "доктор, у меня живот болит"?

Значит кто то в нем живет

Чего эх? Берёте тестилку скорости и смотрите сколько у вас write speed . Можно атто, она пакетная

Я плохо разбираюсь ещё в виртуализации...

Раз так должно быть, как говорите, то зачем делать замеры?

Ты всему веришь что пишут ?)

Ну нет конечно)) но специализированному каналу приходится)

А, если скорость записи на диски 15МБ то конечно же будет предел. А так, да, чтение быстрее происходит всегда.

Книги тоже пишут дольше, чем потом читают 🤷‍♂

Когда вы делаете бэкап или восстановление, то на скорость операции I/O (ввода/вывода) влияет сеть передачи данных до источника и сеть передачи данных до получателя (например, FC), а также сама производительность источника/получателя.
Емнип, у Veeam даже в бесплатной версии был достаточно клевый диагност узкого места.
Ну и уж совсем спойлерну, но, например, восстановление из дедуплицированных данных ВСЕГДА медленнее, чем бэкап туда.
UPD: хотя вряд ли это ваш случай, судя по Veeam Zip...
Еще можно в бэкап чатике этот вопрос задать, вдруг там кому-то интересно будет

Сеть между источниками всеми 1Гб. Диски в raid1, sas.

FYI, завтра в рамках Весенних Вебинаров в 11:00 по МСК будем разговаривать по катастрофоустойчивость. Меньше про продукты и больше про концепции, подходы и принципы (в том числе DR vs Stretched cluster). Присоединяйтесь.

Александр, диагностика причин низкой производительности сродни жертвоприношению: вы приносите в жертву богу девственницу, а затем начинаете выяснять, почему бог вам не благоволит.
То ли не девственница, то ли резус-фактор не подошел.

Лучше берите какой-нибудь гайд типа Troubleshooting performance и идите по нему

Главное потом не спрашивать, почему прокси бекапа загружен на 100% cpu

ну банально боттлнек виам рисует же

То есть? Не понимаю я((

вим анализирует в процессе бэкапа всех участников и вычисляет бутылочное горлышко

но там своих тонкостей море, у них в блоге на хабре очень интересно многие вещи описаны