Правильно ли я понимаю, что все данные жмутся еще на клиенте и передаются на хранение в уже пожатом виде?

Да.

Грамотно ли будет убрать компрессию на клиенте и передавать данные непожатыми, при условии канала в 2Gbit/s и расположения сторадж пула бакулы на zfs томе с включенным lz4. Процессорные мощности и на клиентах и на сервере бакула примерно одинаковые.
Собственно цель всего этого дела — сократить elapsed time.

Попробуй. Недостаточно информации чтобы точно сказать.

Кстати, в bareos тоже есть поддержка lz4.

В bacula-fd.conf клиентов указан режим сжатия gzip-7

Разве можно указывать сжатие в bacula-fd.conf? У меня оно прописано в файлсетах в bacula-dir.conf. И кстати, никогда не задавался вопросом, где выполняется сжатие. Тоже интересуюсь как лучше сделать.

lz4 заруливает gzip и по скорости, и по компрессии.

Все верно, сжатие конфигурится в файлсетах, ошибся в оп-посте.

Буду пробовать. Так же меня смущает этот параметр rate. Если немного посчитать, то получается, что если rate из отчета это скорость отправки данных с клиента, то изменением компрессии еще можно как-то сократить общее время. Если же это скорость, с которой sd-демон пишет на диск, то возникает вопрос — какого черта она вдвое (в моем случае) ниже скорости записи на массив полученной через синтетические тесты? Во втором случае, если я правильно понимаю, никакой тюнинг компрессии мне не поможет в достижении изначальной цели.

Так же меня смущает этот параметр rate. Если немного посчитать, то получается, что если rate из отчета это скорость отправки данных с клиента, то изменением компрессии еще можно как-то сократить общее время. Если же это скорость, с которой sd-демон пишет на диск, то возникает вопрос — какого черта она вдвое (в моем случае) ниже скорости записи на массив полученной через синтетические тесты? Во втором случае, если я правильно понимаю, никакой тюнинг компрессии мне не поможет в достижении изначальной цели.

«скорость отправки данных с клиента» и «скорость, с которой sd-демон пишет на диск» будет одинаковой при любом более-менее серьёзном объёме данных. Просто потому что буферы и кеши не резиновые, а значит FD не сможет отправлять данные быстрее, чем SD их способен писать.

В твоём случае скорость ниже скорее всего из-за того, что всё упирается в скорость сжатия на FD.

В своё время пришлось отрубать компрессию на файлсервере т.к. еженедельные (или месячные, не помню) полные бэкапы занимали что-то около 3 суток... Упирались в проц файлсервера.

Скорость сжатия gzip на современном железе около 20-30мбайт\сек, не больше вроде.

Проблема со сжатием gzip в том, что оно в bacula однопоточное.

Да, именно так. Вообще с многопоточными архиваторами нонче туго дело - тот же LZMA2 вроде как умеет в два потока, если делать больше - прибавки в скорости почти нет. Погонял в 7Zip-е - разница между 1 и 4 потоками в два раза по скорости.

Схоронил

Проблема со сжатием gzip в том, что оно в bacula однопоточное.

Ага, запомним.

Попробовал встроенный алгоритм lz4 в Bareos:

  FD Files Written:       7,637
  SD Files Written:       7,637
  FD Bytes Written:       3,026,305,945 (3.026 GB)
  SD Bytes Written:       3,027,778,075 (3.027 GB)
  Rate:                   37361.8 KB/s
  Software Compression:   35.6 % (lz4)

  FD Files Written:       7,284
  SD Files Written:       7,284
  FD Bytes Written:       2,494,382,331 (2.494 GB)
  SD Bytes Written:       2,495,778,798 (2.495 GB)
  Rate:                   12726.4 KB/s
  Software Compression:   50.5 % (gzip)

Буду ждать выполнения диффов/фуллов для сравнения на более существенных объемах. Хотя уже понятно, что lz4 даст некислое сокращение времени выполнения джобов.

А еще проблема с gzip - при исходныех данных больше 4GB опция --list кажет туфту. Баг формата, описан в man gzip и не лечится ничем (и охватывает pigz). В современных условиях достаточно useless! :(

Себе приспособил 7za (сжатие больших образов) - в формате xz многопоточное (16 потоков 2.4 ГГц) сжатие с трудом вытягивает 25Мбайт/сек, но мне необходимо максимальное сжатие. С кожалению, декомпрессия однопоточная. И, кажется, это касается 7za целиком - все его алгоритмы при декомпрессии однопоточные, хотя сжатие - хороший многопоток (те, что поддерживаются согласно документации).

В документации по bareos, пишут ровно наобарот.

А Вы тестировали LZ4 на клиенте Windows или *nix? По каким-то причинам при включении LZ4 клиент Windows отказывается сжимать данные. Может, ему какой библиотеке не хватает?

А что делает --list? Gzip вообще 1 файл сжимает — это компрессор, а не архиватор.