Нет, вы просто проигнорировали и неправильно поняли ответ. Вас просили продолжить обсуждение в нужном месте — на почтовом списке pbs. Мы были бы очень рады, если бы действительно смогли значительно ускорить систему — вам просто нужно объяснить, как... Но пока этого нам не дали.

Ты прав, «большой» — понятие субъективное. Речь идет о 2,6 ТБ и примерно 18 миллионах файлов. Здесь могут влиять несколько важных факторов: полный обход файловой системы (который нужно делать в любом случае), вызов stat() для файла (тоже обязателен, чтобы отслеживать изменения по времени обновления), чтение всего файла, вычисление контрольной суммы всего файла, передача части или всего файла.

Rsync инкрементально выполняет шаги 1 и 2 для старых файлов, шаги 3 и 4 — для остальных, и шаг 5 — для возможных изменений. Однако rsync не умеет находить дубликаты между разными файлами, поэтому — теоретически — на шаге 5 передается много лишних данных.

Думаю, основная проблема pbs в том, что он выполняет шаги 1, 2, 3 и 4 для всех файлов и, вероятно, все проверки (хотя, как я понимаю, у него есть обнаружение дублей по всему бэкапу, а не только для одного файла). К сожалению, шаг 3 — самый тяжелый, особенно учитывая, что большая часть данных не кешируется. В сочетании с шагами 1 и 2 это, скорее всего, и объясняет столь длительное время работы (по моим предположениям).

Я создал запрос на добавление функции https://bugzilla.proxmox.com/show_bug.cgi?id=3138, чтобы ускорить резервное копирование контейнеров, но его несколько раз закрывали без обсуждения и даже с ошибочными претензиями. Запрос вполне обоснованный, потому что PBS — это единственное в мире решение для резервного копирования, которому нужно несколько часов на копирование НЕИЗМЕНЁННЫХ файловых систем. Я утверждаю, что резкое улучшение возможно, и реализовать это не так уж и сложно.