Veeam на Linux appliance не достаёт файлы из ReFS: зачем в 2026 году нужен Windows mount server

Файлы с томов ReFS и с включённой дедупликацией Windows Veeam восстанавливает только через Windows mount server: Linux такие тома не читает. Поэтому Linux appliance не отменяет одну маленькую Windows-машину рядом. Ниже: что умеет каждый тип mount server, как я это нашёл у клиента, как настроить и проверить.

Почему Linux appliance не читает ReFS и при чём тут mount server

Когда клиент переезжает на Veeam Software Appliance, он обычно слышит красивое: «Windows больше не нужен, сервер резервного копирования теперь на Linux». Про сам сервер резервного копирования это правда. Про восстановление файлов — нет. Любой, кто занимается резервным копированием и защитой данных, рано или поздно упирается в простую вещь: бэкап — это только половина дела, вторая половина — достать из него нужный файл. И вот тут Linux внезапно вспоминает, что ReFS придумал не он.

Механика такая. Чтобы вытащить из бэкапа один файл, Veeam не разворачивает всю виртуальную машину. Он монтирует диски из резервной копии на специальную машину и показывает вам содержимое файловой системы. Эта машина называется mount server. Монтировать нужно уметь файловую систему гостя, и если гость хранит данные на ReFS, то монтирующая сторона обязана ReFS понимать. Linux в базовой поставке ReFS не читает, а Windows читает по определению. Отсюда простой вывод, который почему-то всех удивляет.

Что говорит документация Veeam. Для восстановления файлов из ReFS и из томов с Data Deduplication нужен Windows mount server. Это написано в разделе про ограничения восстановления файлов гостевой ОС, и я перепроверял формулировки по справке для версий 12 и 13. Я бы не стал считать это багом или недоработкой версии: это следствие того, как устроены файловые системы Microsoft. Разработчики Veeam не могут научить Linux читать ReFS по своему желанию в рамках штатной сборки.

Меня до сих пор веселит, как часто слово «appliance» читают как «всё уже внутри, ничего больше не нужно». Это не так, и ниже я покажу, где именно эта вера ломается.

Windows mount server или Linux mount server: что каждый умеет в Veeam 13

В версиях до 13 у репозитория был один mount server, и это обязательно была 64-разрядная Windows-машина. В Veeam Backup & Replication 13 у репозитория можно указать два: один на Windows и один на Linux. Нужен хотя бы один. Если выбранный сервер недоступен или не назначен, Veeam переключается на mount server по умолчанию. Звучит как «выбирайте любой», но разница между ними принципиальная, и она хорошо видна в таблице.

Сводка по возможностям выглядит так. | Что восстанавливаем | Windows mount server | Linux mount server | |---|---|---| | Файлы с NTFS (обычные тома) | да | да, с ограничениями | | Файлы с ReFS | да | нет | | Тома с Data Deduplication | да | нет | | Файлы с ext4, XFS, Btrfs | нет | да | | Динамические диски | да | нет | | Symbolic links и reparse points | да (reparse points только на NTFS) | не восстанавливаются |

Таблица выше собрана из справки Veeam и описания версии 13. Для Linux mount server в справке прямо сказано: восстановление не поддерживается для рабочих нагрузок с включённой дедупликацией, а при монтировании бэкапа Windows-машины исходные буквы дисков и имена томов не восстанавливаются: том показывается со случайным идентификатором. Причина понятна: эти данные лежат в реестре Windows, а Linux до него не добирается. Плюс ещё три оговорки из того же списка: файлы Windows-гостя Linux mount server достаёт только с NTFS-дисков, восстановление с динамических дисков не поддерживается, а symbolic links и reparse points не восстанавливаются вовсе. Если файловый сервер когда-то собирали на динамических дисках «чтобы потом расширять», это ваш случай. Если вы читаете это перед переездом, обратите внимание на оговорку: Linux mount server нужен в первую очередь для Linux-гостей, а не как замена Windows.

Linux mount server сам по себе тоже не бесплатное удовольствие. В справке Veeam 13 для него названы дистрибутивы семейства RHEL 9 и Rocky Linux 9, а также образ Veeam Infrastructure Appliance; точную минорную версию (9.6, 9.7) сверяйте со справкой своей сборки, потому что в релиз-нотах и в справке она называется по-разному. Для обычных RHEL и Rocky перед добавлением сервера нужно поставить пакеты, перечисленные в документации (среди них aspnetcore-runtime-8.0 или новее, bindfs, samba-client и ntfs-3g; в описании роли mount server отдельно упомянут libmsi1, который на RHEL и Rocky живёт в репозитории EPEL, по умолчанию выключенном). Каждая такая машина — это ещё один сервер, который надо обновлять. Так что аргумент «уйдём с Windows полностью» на практике превращается в «поменяем одну заботу на другую».

Если вы только планируете миграцию, рекомендую заранее прочитать мой разбор о переезде с Windows на VSA: там я показываю, что надо проверить до того, как выключать старый сервер Veeam. Mount server в этом списке стоит одним из первых пунктов, а не последним.

Как я нашёл это у «Клумбы и газона»: бэкап работал, восстановление нет

Клиент — компания по озеленению «Клумба и газон», 35 рабочих мест. Мы перевели у них резервное копирование на Veeam Software Appliance 13: старый Windows-сервер с Veeam освободили, репозиторий переехал на отдельный сервер хранения. Задания отрабатывали каждую ночь, статус зелёный, отчёт на почте приходил без ошибок. Классическая ситуация, когда все довольны и никто ничего не проверял.

На третий день после переезда я сделал то, что делаю всегда: тестовое восстановление файла из бэкапа файлового сервера. Это виртуальная машина с Windows Server 2022. На диске D: лежали рабочие каталоги и сметы по объектам (около 1,2 ТБ) на ReFS; на диске E: архив фотографий объектов (около 900 ГБ) на томе с включённой Data Deduplication. Диск C: с системой был обычным NTFS. Попытка восстановить файл с C: прошла гладко. Попытка восстановить файл с D: закончилась ошибкой монтирования. С E: то же самое. То есть рабочие данные компании в бэкапе были, но достать их точечно было нельзя.

Причина оказалась ровно той, что описана выше. Mount server по умолчанию у нас стоял на Linux-стороне, а Windows mount server никто не назначил: при переезде этот пункт тихо отсутствовал в чек-листе. Работающее резервное копирование приняли за подтверждение, что работают все сценарии восстановления. Это самое частое заблуждение, которое я встречаю: задания «зелёные», значит, всё хорошо. Нет. Зелёное задание подтверждает, что данные записаны. Что их можно достать, оно не подтверждает.

Главное: виноват тут не администратор клиента. Виновата привычка проверять только запись бэкапа. Если бы мы не сделали тестовое восстановление, о проблеме узнали бы в день, когда бухгалтер попросит вернуть удалённую смету. Лучше тест на спокойном третьем дне, чем звонок в панике. Подробно о том, как проверять бэкап регулярно, я писал в материале про тест восстановления бэкапа.

Типичная реакция на такую находку: «ну у нас же есть бэкап, значит, как-нибудь достанем». Достанем, конечно: можно развернуть всю виртуальную машину рядом и выковырять файл вручную. Только вместо одиннадцати минут это займёт полдня и потребует свободных терабайта-двух на хранилище. Для 35 сотрудников, у которых смета нужна «прямо сейчас, клиент на проводе», это совсем другая история. Именно разницу между «точечно за минуты» и «целиком за полдня» и покупает маленькая Windows-машина рядом с Linux appliance.

Если у вас на руках такая же картина — appliance работает, а восстановление файлов с ReFS никто не пробовал — напишите нам. Мы за час посмотрим ваши бэкапы и скажем, какие тома у вас не восстановятся точечно и что для этого нужно.

Как настроить Windows mount server для ReFS и дедупликации

Хорошая новость: для этого не нужен дорогой сервер. У «Клумбы и газона» мы подняли отдельную виртуальную машину с Windows Server 2022 (4 vCPU, 8 ГБ памяти, диск 120 ГБ) на том же гипервизоре, что и файловый сервер. Требования Veeam к mount server в целом скромные: 4 ГБ памяти плюс не менее 1 ГБ на каждый одновременно обрабатываемый диск машины, двухъядерный процессор плюс по ядру на каждые две дополнительные задачи. Выбор версии Windows важнее, чем выбор железа, и об этом дальше.

Первый шаг — убедиться, какая файловая система на томах гостя. На файловом сервере это проверяется одной командой, а наличие дедупликации — вторым запросом:

fsutil fsinfo volumeinfo D:
Get-DedupVolume

В выводе первой команды смотрим строку File System Name, второй — перечень томов, на которых включена дедупликация. Если вы видите ReFS или тома в списке дедупликации, Windows mount server обязателен.

Второй шаг — подготовить саму Windows-машину. Если на томах гостя включена Data Deduplication, на mount server должна быть установлена роль дедупликации. Установка из PowerShell от имени администратора, по документации Microsoft:

Install-WindowsFeature -Name FS-Data-Deduplication

Нужно ли включать дедупликацию на самих томах mount server? В справке Veeam для версии 12 сказано, что на машине, где создаётся точка монтирования, дедупликация должна быть включена, а версия Windows Server не ниже версии гостевой ОС. Если вы на версии 13, сверьте формулировку в своей справке, потому что страницы со временем обновляются.

Третий шаг — добавить эту машину в инфраструктуру Veeam как управляемый Windows-сервер и назначить её Windows mount server в настройках репозитория. В консоли и в веб-интерфейсе в мастере репозитория есть шаг Specify Mount Server Settings, там и выбирается нужный сервер. После этого файловое восстановление с ReFS идёт через неё. Если вы ещё не решили, кого вообще держать на Windows, посмотрите, как мы строим файловый сервер на Windows Server: там видно, откуда у вас вообще берутся тома ReFS и дедупликация.

У нас с запуском и проверкой ушло около одного рабочего дня. Первое тестовое восстановление папки со сметами (14 ГБ) с диска D: заняло 11 минут, файл с дедуплицированного E: открылся без ошибок. После этого мы дали системе поработать два дня и повторили проверку на другой точке восстановления. Результат стабильный. Стоимость решения для клиента — одна небольшая виртуальная машина (не забудьте, что ей тоже нужна лицензия Windows Server) и примерно день работы, из которого собственно настройка заняла пару часов, а остальное — проверки.

Подводные камни: версия Windows, ReFS и что ещё ломается

Самая частая ошибка после того, как Windows mount server добавлен, — взять машину с более старой Windows, чем у гостя. По справке Veeam, для ReFS машина с точкой монтирования должна работать на Windows Server 2012 или новее и поддерживать ту же версию ReFS, что используется на гостевой ВМ, или более позднюю; для ReFS 3.x нужен Windows Server 2016 или новее. Для томов с Data Deduplication версия Windows Server на mount server должна быть такой же, как у гостя, или новее. Эти формулировки я проверял по справке версии 12, для 13 сверьте их на странице Microsoft Windows File Recovery. Правило простое: mount server делайте на самой свежей Windows Server, которая у вас есть.

Теперь о дедупликации на ReFS. По обзору ReFS от Microsoft, поддержка Data Deduplication на ReFS появилась в Windows Server версии 1709 и далее, а в LTSC начиная с Windows Server 2019. Если в вашей инфраструктуре тома ReFS с дедупликацией живут на 2019 и старше, mount server на 2016 вас не спасёт. И не путайте это с известным ограничением из релиз-нотов Veeam 13: там сказано, что тома ReFS с одновременно включёнными дедупликацией и шифрованием не поддерживаются, но речь о репозиториях на Windows Server 2025 и Windows 11 24H2, то есть о хранилище бэкапов, а не о дисках гостя. Если у вас Windows-репозиторий на свежей ОС, заранее решите, нужно ли вам и то и другое сразу.

Дальше мелочи, которые сильно портят настроение. Обработка reparse points, по справке Veeam, поддерживается только для NTFS, а точки с тегами, отличными от mount point, symlink и дедупликации, могут быть обработаны и восстановлены некорректно (так сказано в справке версии 12). Файлы, зашифрованные EFS, через файловое восстановление не вернуть. Если mount server не назначен или недоступен, Veeam молча переключится на сервер по умолчанию, и вы заметите это только когда восстановление не сработает. Поэтому проверяйте, какой именно сервер участвует в операции, а не надейтесь, что «оно само разберётся». Отдельный сюрприз для Hyper-V: если ВМ была выключена в момент бэкапа, Veeam считает гостя Linux-машиной и по умолчанию предлагает Linux mount server. Для Windows-гостя на шаге выбора mount server в мастере восстановления переключите его на Windows вручную.

И последнее. Файловое восстановление не заменяет восстановление всей машины. Если файловый сервер упал целиком, пригодится восстановление Windows без переустановки, а mount server здесь вообще не участвует. Это два разных сценария, и тест нужен для обоих.

Чек-лист проверки: как убедиться, что файлы из ReFS достаются

Я не доверяю чек-листам, которые нельзя выполнить за час. Вот тот, что выполним. Первое: составьте список всех виртуальных машин в бэкапе и для каждой выясните, какие файловые системы на её томах. Для Windows это команда fsutil fsinfo volumeinfo или оснастка управления дисками. Второе: отметьте машины с ReFS и с дедупликацией; для них Windows mount server обязателен. Третье: убедитесь, что такая машина добавлена в Veeam и назначена в настройках репозитория, и что её версия Windows Server не ниже версии гостей.

Четвёртое: проведите тестовое восстановление по одному файлу с каждого типа тома: системный NTFS, данные на ReFS, дедуплицированный том. Пятое: запишите результат в журнал и повторяйте раз в квартал и после любых изменений: обновления Veeam, смены репозитория, перехода на новую версию Windows. Бэкап делают все, проверяет его почти никто, и именно это отличает спокойный вторник от аврала. Для небольшой компании это полчаса в квартал.

Отдельно скажу про выбор файловой системы для новых томов. ReFS даёт реальные преимущества: контрольные суммы метаданных, блочное клонирование, большие тома. Но если вы выбираете её только потому, что «она новее», вы получаете дополнительное условие для восстановления файлов. Для небольшого файлового сервера NTFS часто проще, потому что восстанавливается любым mount server. Решение за вами, но принимайте его, зная о цене.

Частые вопросы