В итоге я сделал примерно то же самое — всё взорвал и собрал заново. Полностью уничтожил весь пул жестких дисков, назначил новые OSD для каждого жесткого диска и для SSD DB/WAL с подходящим размером, потом физически забрал свой сервер для бэкапов, чтобы он был локальным и не имел тех самых 30 миллисекунд задержки.  

В итоге столкнулся с проблемой постоянной порчи базы данных на OSD с жесткими дисками. Полагаю, это из-за ограниченного количества IOPS, что вызвало проблемы с синхронизацией, ведь база данных, журнал предварительной записи (write ahead log) и сами данные находились на спиннинговых дисках — в итоге это привело к повреждению. Эта проблема меня не раз подкосила, больше, чем я хочу вспоминать, так что я её исправил.  

Сейчас скорость с бэкап-сервера у меня порядка 55-60 мегабайт в секунду вместо 10. Задержки HDD OSD упали с сотен и тысяч миллисекунд до десятков. Это не решает проблему надежности PBS, но зато мои 12 терабайт теперь скопируются меньше чем за 4 недели — а значит шанс на сбой меньше.  

Для справки, у меня PBS — это ZFS RAID10 из 4 дисков. В работе 8-терабайтные Exos на 7200 оборотов в минуту, настоящие «зверьки» из дата-центра. Теоретически, они не должны быть узким горлышком по производительности.  

Рад слышать, что добавление диска помогло у тебя! А какую скорость ты сейчас показываешь?

Это последнее сбой было во время Live Restore или офлайн восстановления? В первом случае любая неполадка в цепочке разрушит процесс восстановления, как уже объяснялось ранее:

Это именно то, чего я в итоге хотел бы добиться в PBS — надежности при восстановлении, такой же, как у резервного копирования, пусть даже с долгим ожиданием, потому что я всегда могу отменить, если не хочу ждать. В моём случае добавление третьего жёсткого диска в пул ZFS решило проблему (больше никаких проблем с восстановлением), так что это была не сетевая ошибка, а проблема с диском.