Каким образом лучше подключать систему хранения данных (СХД) к Proxmox Backup Server?

Коротко — обе опции рабочие, но выбор зависит от требований по производительности/надёжности/фичам СХД. Ниже — развернутое сравнение плюс практические рекомендации для Proxmox Backup Server (PBS).

Основные факты, которые нужно учитывать
- PBS сам по себе делает контент‑адресуемую дедупликацию и хранит множество мелких «чанков» в репозиториях. То есть бэкап‑дедупликация выполняется на уровне PBS, не на СХД.
- СХД, предоставляющая LUN по iSCSI, даёт «блок‑устройство», на которое вы ставите локальную ФС (XFS, ext4, ZFS и т.д.). При NFS вы используете файловый экспорт — PBS видит обычные файлы в дереве.
- Многие NAS/СХД умеют делать дедупликацию/компрессию «на NFS» (файловая/блоковая) и не применяют её/не так хорошо применяют к «сырым» iSCSI LUN — поэтому ваш комментарий про дедупликацию по NFS верен и это важный аргумент.

Плюсы iSCSI LUN
- PBS видит диск как локальный блок — можно настроить любую локальную ФС или ZFS; полная контроль над параметрами ФС/монтирования.
- Поддержка multipath/MPIO (multipathd) — удобна для избыточности путей и увеличения пропускной способности при наличии нескольких каналов.
- Часто чуть более предсказуемая/низколатентная производительность для случайных IO при правильной настройке.
- Можно строить ZFS поверх LUN для целостности данных/снэпшотов (но ZFS dedup — дорого по памяти).

Минусы iSCSI LUN
- Если СХД не делает дедупликацию на блочном уровне, вы теряете её преимущества.
- Дополнительная настройка multipath, инициатор iSCSI, форматирование LUN—слегка сложнее.
- При ошибочной настройке можно случайно отформатировать LUN и потерять данные — управление LUN‑ами надо вести аккуратно.

Плюсы NFS (экспорт)
- Проще в настройке: создаёте экспорт/шару и монтируете на PBS.
- СХД может применять дедупликацию/компрессию/снэпшоты на файлах; при хорошей реализации это может существенно сэкономить место.
- Управление квотами и доступом на уровне файловых систем удобнее.
- Подходит для большого количества репозиториев/быстрой экспансии.

Минусы NFS
- Нельзя легко использовать традиционный блок‑уровень multipath; отказоустойчивость/агрегация каналов делается сетевыми средствами (bond, LACP) или через функциональность СХД (мультиадресный экспорт, pNFS/RDMA — редко и сложнее).
- Качество работы зависит от реализации NFS на СХД: корректность fsync, atomic rename, POSIX‑семантики, блокировки — критична для целостности репозитория PBS. Если СХД «обманывает» fsync (асинхронные операции без опций sync), возможны повреждения репо при крахе.
- Производительность может быть ниже/менее предсказуемой при большом числе мелких файлов (именно такие файлы создаёт PBS). Дедупликация/индексация на СХД при большом количестве мелких файлов может быть CPU‑ и метаданно‑интенсивной.
- Экспорт должен быть настроен с правильными правами (root access / no_root_squash / uid mapping) — иначе проблемы с правами.

Практические рекомендации для вас (учитывая прямое оптическое подключение и что СХД умеет дедуп)
1. Если дедупликация на СХД по NFS действительно хорошая и вы хотите её использовать — NFS вполне корректен и часто применяется для PBS. При этом:
   - Уточните у вендора СХД: гарантирует ли NFS экспорт корректные fsync/atomic/locking semantics для приложений, требующих устойчивости данных (в т.ч. PBS).
   - Настройте выделенную сеть/порт для NFS (у вас прямое оптическое подключение — отлично).
   - Монтируйте с подходящими опциями (hard,_netdev, noatime/nodiratime; версию NFS выбирайте в зависимости от СХД — NFSv3 иногда предпочтительнее для производительности, v4 — для безопасности/аутентификации). Протестируйте производительность и поведение при перезагрузках/сбоях.
   - Проведите нагрузочное тестирование: создание репозитория, запись/удаление/verify бэкапов, имитация отказа сети/СХД и восстановление — убедитесь, что репозитории не ломаются.

2. Если для вас критичны:
   - блок‑уровневая multipath‑резервирование/агрегация, или
   - вы хотите управлять файловой системой на хосте (ZFS с контролем целостности, снэпшотами, компрессией на стороне хоста)
   — то выбирайте iSCSI LUN, форматируйте LUN в XFS/EXT4/ZFS и используйте multipathd. Это даст более предсказуемую «локальную» работу и удобство работы с ФС.

3. Не забывайте про то, что один и тот же PBS‑датастор не должен одновременно монтироваться несколькими PBS (нельзя иметь два PBS одновременно работающими над одним и тем же репозиторием). Это касается и NFS, и iSCSI (если LUN подключен нескольким хостам — нужна кластерная ФС).

4. Тестируйте: лучший способ — развернуть тестовый datastore на NFS и на iSCSI LUN и прогнать реальные сценарии: бэкап большого объёма, восстановление, прерывание связи, нагрузка по параллельным задачам. Сравните throughput, IOPS и поведение при сбоях.

Короткий вывод/рекомендация
- Если вы хотите простую настройку и рассчитываете на дедупликацию/компрессию на стороне СХД — NFS — нормальный и часто используемый вариант, при условии, что экспорт корректно реализует fsync/atomic semantics и вы протестировали сценарии отказа.
- Если вам важны block‑level multipath, предсказуемая производительность и/или управление ФС на хосте (например ZFS), — используйте iSCSI LUN.

Если хотите, могу:
- подсказать конкретные mount/iscsi/multipath настройки для PBS,
- привести пример проверки корректности NFS‑экспорта (тесты fsync/rename/симуляция отказа),
- или помочь выбрать filesystem (XFS/ZFS) и параметры для LUN.

Зря рассчитываешь на дедупликацию СХД по NFS — PBS хранит данные как мелкие chunks, которые уже дедуплицированы самим бэкапером. Дедупликация СХД там практически ничего не даст. <br/> <br/> По производительности NFS для PBS хуже: PBS работает с кучей мелких файлов-chunks, и NFS на этом паттерне I/O заметно медленнее чем iSCSI. Это известная проблема, не только у тебя. <br/> <br/> С прямым оптическим подключением — iSCSI, multipath поднять там не так страшно как кажется.

При монопольном доступе к данным (в ситуации с резервным копированием обычно это так, когда в один момент только один сервер работает с образом/архивом) наилучшим с точки зрения производительности - это блочные системы публикации хранилища, потому что операционная система может максимально эффективно выбирать что и когда записывать и читать, использовать кеши, асинхронную запись и т.п. лучше всего это видно на мелких файлах или даже базах данных. <br/> <br/> Самый известный протокол iscsi (лично я считаю его в большинстве ситуаций, особенно маленьких организаций и дома - перегруженным, но спасибо есть простые сервера для самодельных nas типа linux istgt). <br/> До него был еще проще (с точки зрения нагрузки на сервер/nas) NBD (network block device) - очень простой и эффективный по ресурсам для NAS (особенно для слабых машин). <br/> Есть еще старый AOE (ata over ethernet), он позволяет публиковать диск/образы по ethernet вне ip/tcp стека (т.е. минус оверхед от организации сети). <br/> Еще нагуглил NVMe over tcp (я знал что есть по fibre такая технология, но что ее сделали по tcp я не знал). <br/> Все это прекрасно работает в linux, но нужно смотреть поддержку NAS. <br/> <br/> p.s. помимо организации самой работы, нужно думать что произойдет во время сбоя связи между сервером и NAS, к примеру если диски примонтированы mount (особенно если диски примонтированы на хост машине а не каждый диск внутри VM) то разрыв связи создаст проблемы на сервере, подвисание с длительным периодом решения этой проблемы. <br/> <br/> Так же нужно понимать, что ппубликация блочного устройства подразумевает что он будет монтироваться (т.е. к нему потребуется полный не контролируемый доступ, максимум readonly можно выставить) на хост системе или внутри виртуальных машин, т.е. организационные сбои (ошибки администратора) или к примеру вирусы, смогут уничтожить копию на этом диске. Правильная система резервного копирования должна работать наоборот, backup-сервер должен подключиться к машинам с данными, и копировать их по своей логике и правилам. <br/> <br/> По поводу организации резервного копирования, есть неплохие идеи при использовании мощных ZFS/btrfs файловых систем, у них встроенная и бесплатная по ресурсам система организации снапшотов, а главное есть возможность отправлять по сети/или хранить разницу между указанными снапшотами в виде файла (полный аналог diff/patch для текстов), и удаленно применяя эти патчи к холодной резервной копии (или просто хранить в виде файлов, но при необходимости их придется применять к стартовому состоянию на бакап сервере в правильном порядке без пропусков), на текущий момент это наилучший способ организации инкрементального резервного хранилища, универсально подходит под любые нужды, хоть VM хоть типовой сервер.