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