Распределенная файловая система DFS (Distributed File System) используется в сетях Microsoft для удобства организации доступа к общим сетевым папкам (файловым ресурсам), и (опционально) репликации данных между серверами. DFS позволяет объединить разрозненные сетевые папки, хранящиеся на разных файловых серверах в общую структуру, которая для пользователей выглядеть как единое виртуальное дерево каталогов, доступное по общему UNC пути. Даже при изменении физического местоположения целевой папки, это не повлияет на доступ пользователей к ней.
Реализация DFS в Windows Server основана на двух службах:
- DFS namespace – служба для объединения файловых ресурсов с разных серверов в единое логическое пространство имен DFS. Каждое пространство имен для пользователя выглядит как сетевая папка с подпапками. Пространство имен DFS может содержать сетевые папки с разных серверов, физическая структура и местоположение которых скрыто от пользователей.
- DFS Replication – служба позволяет организовать репликацию (синхронизацию) файлов между папок на серверах в пространстве имен DFS с целью организации высокой доступности и согласованности файлов. При изменении файла на одном из серверов, репликация DFS передает партнерам только измененные части файла.
В этой статье мы покажем, как настроить DFS и репликацию в Windows Server 2025 (в предыдущих версиях Windows Server все настраивается аналогично).
Установка DFS и создание пространства имен DFS в Windows Server
Служба DFS namespace доступна во всех редакция Windows Server. Установить ее можно через консоль Server Manager (File and Storage Services -> File and iSCSI Services -> DFS Namespace) или с помощью PowerShell:
Install-WindowsFeature FS-DFS-Namespace, RSAT-DFS-Mgmt-Con
После установки роли можно создать новое пространство имен DFS
- Откройте консоль управления DFS (
dfsmgmt.msc). - Щелкните New Namespace в правой панели Actions
- Укажите имя сервера, который будет содержать пространство имен DFS (это может быть как контроллер домена, так и рядовой сервер).
- Укажите имя пространства имен (оно будет исопльзоватся для доступа клиентами). Например Public.
- Нажмите кнопку Edit Settings и настройте права доступа к корневому каталогу пространства имен. Обычно тут указывается, что доступ к сетевой папке разрешен Всем (Everyone), в этом случае фактические права доступа проверяются на уровне файловой системы NTFS. Также здесь указывается локальный путь к каталогу DFS (по умолчанию C:\DFSRoots\Public).
- Далее нужно выбрать тип пространства имен. Это может быть Domain-based namespace (доменное пространство имен) или Stand-alone namespace (отдельное пространство имен). Domain-based namespace обладает ряд преимуществ, но для его работы нужен, собственно домен Active Directory и права администратора домена (либо наличие делегированных прав на создание доменных пространств имен DFS).
\\ServerName\Public
, а для доступа к доменному DFS нужно указывать имя домена (
\\DomainName\Public
).Чтобы пользователи при доступе к DFS каталогу видели только те папки, к которым у них есть доступ, откройте свойства нового пространства и включите опцию Enable access based enumeration for this namespace (подробнее о Access-Based Enumeration в Windows).
Вывести все корневые DFS namespace в домене:
dfsutil domain winitpro.ru
Добавим новую сетевую папку в иерархию созданного ранее DFS namespace:
- Выберите его в консоли и щелкните New Folder
- Укажите название нового каталога и его фактический путь к нему (в формате UNC)
Проверьте, что теперь добавленный сетевой каталог доступен пользователям из проводника Windows через пространство имен DFS:
\\winitpro\public\Docs
Пользователи могут открывать файлы из каталога, добавленного в DFS, не зная на каком сервере они находятся фактически. Такой сетевой каталог пользователи могут подключить в виде сетевого диска по его пути в DFS.
Для повышения отказоустойчивости и доступности пространства имен DFS в него можно добавить дополнительные сервер (Add Namespace Server).
Настройка DFS репликации в Windows Server
С помощью репликации DFS-R можно организовать синхронизацию содержимого сетевых папок в пространстве имен DFS между серверами и высокую доступность (в случае недоступности одного из серверов, клиенты автоматически перенаправляются на сервер-реплику). Также в сценариях с филиалами это позволяет обеспечивать пользователям доступ к актуальным версиям файлов, синхронизированных из головного офиса и уменьшать нагрузку на WAN каналы.
На всех серверах, которые будут участвовать в группе репликации DFS нужно установить роль FS-DFS-Replication:
Install-WindowsFeature FS-DFS-Replication, RSAT-DFS-Mgmt-Con
В консоли DFS Managment выберите нужный вам DFS Namespace, щелкните ПКМ по каталогу, для которого хотите создать реплику и выберите Add Folder Target. 
Укажите полный (UNC) путь к сетевому каталогу другого сервера, в котором будет храниться реплика.
На вопрос хотите ли вы создать группу репликации отвечаем Yes.
Запустится мастер настройки репликации. Проверьте имя группы репликации и каталог.
Выберите primary сервер, который будет источником данных при инициальной (первичной) репликации.
Выберите тип топологии (соединения) между членами группы репликации. В нашем примере выбираем Full Mesh (все со всеми).
Затем можно указать расписание репликации и нужно ли включать ограничение на максимально доступную полосу для трафика репликации DFS (bandwidth throttling). В современных интерсетях, даже соединенных через WAN каналы, как правило можно оставить постоянную репликацию с использование всей доступной полосы.
Если нужно, настроить расписание репликации и максимальную полосу пропускания, можно задать в настройках группы репликации в ветке Replication.
Подождите некоторое время, чтобы прошла первоначальная репликация на другие сервера группы DFS репликации. Либо выполните команду для принудительного запуска репликации:
Sync-DfsReplicationGroup -GroupName "wintpro.ru\public\docs" -SourceComputerName "w-fs01" -DestinationComputerName "s-fs02" -DurationInMinutes 15
Служба DFS репликации может игнорировать некоторые файлы. Как правило, не нужно реплицировать временные файлы приложений, которые создаются программами. Откройте свойства DFS папки на вкладке Replicated Folder. Обратите внимание, что по умолчанию включен фильтр для файлов с расширениями
~*, *.bak, *.tmp.
Вы можете отредактировать этот список и добавить свои типы файлов, которые нужно исключать из репликации DFS.
Обратите внимание, что в корне каждой DFS папки на диске появляется скрытый каталог DFSRPrivate. Этот системный каталог, в котором хранятся внутренние данные и метаданные репликации DFS.
Здесь находятся такие служебные папки, значение которых нужно знать администратора DFS:
- Staging – временное хранилище для файлов, которые находятся в процессе репликации. Размер этой папки по умолчанию 4Гб. Квота создается в настройках DFS папки на вкладке Staging. Если размер файла для репликации больше, чем квота Staging, такой файл будет передан в несколько этапов.
- PreExisting — файлы, которые уже существовали в папке до начала репликации и были сохранены системой
- ConflictAndDeleted – содержит удалённые и конфликтные с точки зрения репликации файлы. В эту папку перемещаются файлы, когда несколько пользователей изменили один и тот же файл. Файл в DFS пересматривается последней версией, а более старая версия отправляется в папку ConflictAndDeleted, откуда ее может восстановить администратор.
- Delete – содержит удаленные объекты
Кроме Event Viewer (Applications and Services Logs -> DFS Replication), логи службы DFS можно найти в папке
%windir%\debug\DFSR*.log
.
Рассмотрим полезные команды для мониторинга и получения статуса репликации:
Вывести информацию о файлах, которые находятся в процесс репликации DFS:
Get-DfsrState -ComputerName SRV02 | FT FileName,UpdateState,Inbound, SourceComputerName
Статистику по очередям репликации DFS:
dfsrdiag replicationstate /all
количество файлов, которые находятся в процессе репликации между серверами:
Get-DfsrBacklog -SourceComputerName SRV01 -DestinationComputerName SRV02| select FileName,FullPathName
dfsrdiag backlog /SMem:SRV01 /RGName:Rep_Folder /RFName:share /RMem:SRV02
DFS репликация хороша для редко изменяемых файлов или когда только один сервер активный (а остальные read-only), поскольку в таких сценариях снижается риск конфликтов и проблем с синхронизацией. При частых параллельных изменениях одного файла на нескольких серверах возможны конфликты, которые трудно корректно разрешить автоматическими средствами DFS.
А как дело обстоит с применением изменений файлов, произведенных на разных репликах?
Если разные пользователи одновременно изменят один и тот же файл на разных серверах, служба репликации DFS обнаруживает конфликт и будет использовать ту версию файла, которая была сохранена последней. Другой файл будет помещен в папку DfsrPrivateConflictandDeleted (на компьютере, разрешившим конфликт). Файл будет лежать в жтой папке до ее очистки, которая происходит при превышении заранее заданного размера папки ConflictandDeleted. Также при возникновении конфликта служба репликации DFS регистрирует данное событие в журнале событий репликации DFS. Стоит отметить, что папка ConflictandDeleted не реплицируется.
Здравствуйте! Спасибо за статью. Разъясните, пожалуйста, такую ситуацию
Допустим я использую два сервера DFS для хранения профилей пользователей и перенаправленных папок. При создании пространства имен DFS-сервер занесет в DNS-сервер локального домена адрес(а) нового пространства имен. Я настрою репликацию, чтобы все среплицировалось на второй DFS-сервер. Вот, собственно, вопрос, кто и какие записи сделает в DNS для пространства имен? И что произойдет, когда один из DFS-серверов выйдет из строя? В таком случае его запись необходимо убрать из DNS, чтобы клиенты не ломились в пустоту. В общем, мысли путаются, подскажите…
Добрый день!
В обще-то DFS не лучшее решение для организация перемещаемых профилей и поддерживается MS в весьма ограниченной конфигурации (ознакомьтесь со статьей http://support.microsoft.com/kb/2533009 ).
Создайте новое пространство имен и новую папку в нем. Для данной папки настройте репликацию данных межу двумя серверами DFS. При выходе из строя одного из серверов, клиенты автоматически будут обращаться к оставшемуся серверу. Ведь при обращении к ресурсам DFS используют не имя конкретного узла DFS, а доменный путь UNC к пространству имен DFS, который уже перенеарпавляет пользователя на доступный сервер.
исходя из устройства и принципа действия, понимаю, что само по себе DFS не лучшее решение. Для чего бы то ни было.
Могли бы вы подсказать альтернативный вариант? Ведь, для AD, профилей пользователей и всяких майкрософтных вещей нужен NTFS, чтобы всякие права соблюдались…
А, собственно, какова задача? Если нужно обеспечить отказоустойчивость файлового сервиса (в вашем случае на нем хранится ) то лучше смотрите в сторону кластера.
Вы, похоже, запутались. NTFS — это файловая система, а DFS — сетевой сервис для организации доступа к данным (данные все также хранятся на файловой системе с NTFS).
Нет, не запутался. 🙂 Я к тому, что профили пользователей с перечислением на основе доступа, правами и прочим должны находиться как раз на NTFS разделах. Если использовать другие решения отказоустойчивого файлового хранилища (не от Microsoft) соблюдение всех требования MS для профилей не гарантируется. В прочем, это уже совсем другая история.
К слову, удалось достаточно вменяемо настроить репликацию профилей в DFS, и это даже работает.
Вообще можно, и я так даже делаю. Только смотря что вы копируете… Если, например, это какая-то используемая в реалтайме база данных (sql или 1с) то актуальность данных на другом конце репликации не гарантируется.
А топология — это немного другое. Это скорее для направления, периодичности и количестве членов репликации.
Папки с файлами word/excel, по поводу баз sql понятно, там в них можно настроить репликацию. Топология, я имею в виду при настройке мастер спросит какую топологию использовать, получается для моей задачи это не важно?
Вопрос топологии — это вопрос кому с кем реплицироваться. Если нужно просто реплицировать из точки А в точку G, выбирайте «все со всеми».
Если это файлы с общим доступом, то проблем огребете по уши. Каждый открывает на своем сервере, а при сохранении возникает конфликт и сообщение о невозможности сохранения. не нашел ничего лучше, чем отключить все реплики, кроме одной. работа шла на одном сервере, на остальные только синхронизировалось. но если этот сервер отвалится, то включаешь любой другой и юзеры счастливы. при многосайтовой структуре вариант кривоват, но альтернативы не придумал.
DFS не является решением для резервного копирования. Представьте, что вы будете делать, если на каталоге-источнике был изменен важный файл… Все изменения в нем будут реплицированы по серверам-репликам. Таким образом вернуться к предыдущей версии файла не удастся…
В качестве альтернативы классическому резервному копированию можно посмотреть на Volume Shadow Copy (https://winitpro.ru/index.php/2013/09/05/sluzhba-shadow-copy-v-window-server-2012/)
Спасибо, интересно, жаль что нельзя делать теневые копии на сетевой диск!!!
В корне не верно, DFS это про отказоустойчивость, а не про бекапы.
Подскажите пожалуйста, можно и правильно ли решать средствами DFS задачу резервного копирования, т.е. чтобы копии папок и файлов просто перекладывались на другой сервер если да, то какой тип топологии выбрать.
Добрый день. Есть вопрос по ABE. В настройках пространства имён включил. Сделал несколько папок с разными правами, но всё равно продолжаю видеть их все, если захожу \test.intDFS
Можно как-то прояснить этот момент?
Можно ли использовать DFS для терминальных UPD имея 2 ЦОДа без общего стореджа ???
С отключенным (висящим в фоне) сеансом сервер может остаться только ели полностью потеряет сеть, но сам устоит и будет работать. Когда сеть к нему придут снова — он попытается обновить дискрипторы к открытым дискам, у него это не получится, засыпет все логи ошибками и что будет в итоге предсказать трудно. Возвращение в строй такого сервера лучше сопроводить перезагрузкой.
Ситуация: имеется 2 файловых сервера. Один — основной, второй — реплика. Все изменения проходят на основном сервере и реплицируются на второй. В случае отказа основного сервера пространство имен тут же переключает пользователей на реплику.
Вопрос: при восстановлении основного файлового сервера (например через пару часов, где подверглись изменению 1 Гб данных) все изменения на реплике автоматически синхронизируются с основным сервером?
Добрый день!
Перечисление на основе доступа или не работает или работает не полностью. Допустим у нас есть шара в ней включено перечисление на основе доступа. Пользователи не видят папки на которые не прав. Если эту шару скормить dfs, включить в нем галочку перечисление на основе доступа и зайти по дфсному пути — внутренние папки видно. Зайти в них нельзя, но видно. А по пути шары — не видно. В чем может быть проблема?
Люди помагите настройил дфс на двух серверах все вроди бы норм но реплику не делает кто может подсказать в чем может быть проблемо
Добрый день.
Имеется такая конфигурация:
-Server1 (DC1, DFS namespace)
-Server2(DC2)
-Server3(FileServer1, DFS replication)
-Server4(FileServer2, DFS replication)
Я правильно понял, что можно поставить DFS namespace на Server2 и тогда к пространству имен можно будет обраться даже если один из серверов (Server1, Server2) будет не доступен?
Можно ли использовать dfs, если на файловые сервера хранят постоянно изменяемые бинарные файлы (некая база данных)? Я в том плане, неизвестно же к какому файловому серверу обращается клиент через namespace?
1) Лучше использовать интегрированное в AD пространство имен DFS. В этом случае, конфигурация namespace DFS будет хранится в схеме домена.
2) Да, нужно чтобы клиенты второго домена могли отрезолвить имена namespace
Кому приходилось реплицировать папки большого размера(более терабайта, с дудупликацией)?
Настроил для начала для маленькой папки, проверил, работает.
Настроил для больших папок и уже несколько суток на сервере назначения файлы не появились…
Это баг или фича?)
Как траблщутить?
здравствуйте. Как вам идея использовать DFS в 2016 сервере для репликации файлопомойки между филиалами через VPN ? В филиале планирую RODC и файловый сервер. Репликация нужна для обычных офисных файлов, CAD чертежей и т.п.
Здравствуйте.
Растолкуйте, пожалуйста, новичку в DFS пару непонятных моментов.
Есть созданный по вашей статье namespace (DFS), в нем есть Folder (Shara),
у шары есть 2 target folders (делалось по второй части статьи, для репликации). Репликация мне нужна односторонняя (FS1->FS2), поэтому в свойствах реплики для FS2 membership status выставлено read-only.
Теперь собственно вопросы: Т.к. для \mydomain.localDFSShara указано 2 таргета, не будут ли пользователи открывать файлы с обоих FS? А если все же будут, как будет себя вести репликация, если membership status у FS2 (read-only) ?
Все дело в том, что на FS2 в DfsrPrivateConflictAndDeleted я вижу кучу документов, с которыми каждый день работают пользователи (некоторые файлы по несколько раз за день попадают в ConflictAndDeleted) и не совсем понимаю откуда они тут берутся, если на FS2 они должны просто заменяться «свежими» копиями с FS1. Есть подозрение, что это как раз те файлы, которые перезаписываются новыми с FS1, но полной уверенности нет, зато полно опасений и холодка чуть ниже поясницы :))
«Методом научного тыка» было выяснено- Если просто изменить атрибут «Архивный» у файла на FS1, этот атрибут на на FS2 не перенёсся.
Подскажите как правильно должны быть настроены Referral? И как клиенты определяют с каком именно сервере имён они редактируют скажем какой-нибудь файл? Вот у меня получается что в одном пространстве имён в свойствах разных папках активны разные Referral в одной папке активен сервер имён fs-01 в свойствах другой папки активен fs-02. Я так понимаю это неправильно? Потом будут возникать конфликты и файлы будут помещаться в директорию …DfsrPrivateConflictAndDeleted
Подскажите как правильно должны быть настроены Referral в свойствах папки.
Доброго времени суток. Подскажите, как сделать многоуровневую иерархию в дфс без применения репликации.
На данный момент смог добиться только такого вида:
serverdfsконечный объект папки1, конечный объект папки2, … конечный объект папки n.
А есть необходимость сделать так:
serverdfsпапка1конечный объект папки1, конечный объект папки2.
serverdfsпапка2конечный объект папки3, конечный объект папки4.
Почитайте здесь и тут
Если через GUI, то тыкаете в оснастке «Управление DFS» ПКМ по пространству имен (в вашем примере это dfs) и создаёте папку БЕЗ конечного объекта.
Можно ещё через PowerShell:
New-DfsnFolder
Имейте в виду, что если у DFSN-папки уже есть конечный объект (т.е. шара, на которую она ссылается), то создать подпапку для нее не получится.
Недавно написал шаблон мониторинга DFSR для Zabbix. Взять можно здесь.
Здравствуйте, я правильно понимаю, что автоматом клиент должен коннектиться к ближайшему серверу и только при недоступности его уже к следующему, это при условии, что два сервера в разных филиалах за VPN. Как можно узнать к какому серверу DFS-N клиент подключен в данный момент?
А как можно исключить/удалить первый сервер из dfs?
К примеру, был первый физический сервер, на нем dfs, есть общие шары
Затем добавили второй (виртуальный) сервер, настроили репликацию dfs
Теперь нужно первый, физический, исключить/убрать из dfs, и пользователи будут ходить на второй, виртуальный
По всей видимости, нужно тех. окно чтобы не было открытых файлов в шарах? И как корректно это можно сделать
Здравствуйте. А как сделать что бы она была видна в тут: \имя_домена_или_сервера ? Что бы человек смог пройти по указанному пути, а не набирать строчку целиком «\имя_домена_или_сервераDFS«?
Здравствуйте, возникла проблема такого характера, может кто-нибудь сталкивался, поднята роль Dfs реплицируется на 2-ой сервер, с недавнего времени возникла проблема, что некоторые пользователи не видят файл в папке, но некоторые в этой же папке видят,
Несколько раз пытались внедрить репликацию DFS и так и не получалось. И вот почему. У разных пользователей будто работа велась с разными серверами и вот сидят коллеги в одной комнате и кидают шару. Один закинул, а второй не видит… Ждём-с. Хотя настройки вроде нормальные были..
Потом файл поменял кто-то, а другой долго наблюдает старую версию.
Ну ок, не сразу отключили, но каково было потом удивление, сколько было «конфликтов» на пустом месте.. Хотя вроде файлы редактировали в разное время, но всё равно, были.
В итоге, плюнули и делаем бэкапы раз в сутки… Пока не пригождалось, да и ладно))
Ещё вспомнил, что когда выключали один из серверов DFS, что будто те, кто был привязан к нему, теряли вообще доступ к шаре, т.е. автоматическая работа с другим сервером не производилась.
Репликацию рассматривали как выход файлового сервера из строя и чтобы пользователи ничего не заметили… Может, это нужно для другого? Но зачем тогда? Куча есть кроссплатформенных решений для репликаций.. Или это свой велосипед от MS?)
Добрый день.
Столкнулся с такой проблемой:
Пробую настраивать в пределах одного сервера (srv1 — WinSrv2012).
— создано пространство имён — \domain.localdfs, включено перечисление на основе доступа
— в этом пространстве имён создана папка — share
— добавлены конечные объекты папки — \srv1share1, \srv1share2, \srv1share3, все они расположены на одном диске данного сервера
Не понятно почему, но при обращении по \domain.localdfsshare или \srv1dfsshare, видны и доступны только ресурсы из share1. При этом если подключаться на прямую, \srv1share1(share2, share3), ресурсы доступны в каждом каталоге.
— Сверял все права на директориях, share1, share2, share3 — идентичны.
— Пробовал как вариант, удалять конечные объекты папки, — share1, share2. Т.е. теоретически должны остаться доступны только ресурсы share3, но по прежнему остаются доступны ресурсы только share1. Что весьма странно, и мне совершенно не понятно такое поведение DFS… Пробовал другие комбинации share1, share2, share3, для конечного объекта папки, всё равно доступны ресурсы только share1.
— Пробовал полностью пересоздавать пространство имён. Аналогичная ситуация.
Ни чего не помогает.
Максимум, что удавалось, при создании нового пространства имён, и допустим конечном объекте папки share2, получить доступ к ресурсам данной директории через \domain.localdfsshare или \srv1dfsshare. Но дальше всё как и с share1, — доступны только ресурсы share2 при любых комбинациях конечных объектов, из share1, share2, share3.
Подскажите пожалуйста, что ещё можно попробовать сделать, что проверить?
Подскажите пожалуйста. Есть dfs на fs-srv1, сейчас настроил виртуальный сервер fs-srv2 скопировал все файлы с шарами и acl, и хочу в dns cname сделать с fs-srv1 на fs-srv2. Такое может прокатить или так не заработает? -Ну или fs-srv1 вывести из домена и новый сервер ввести под старым именем?
Если речь о standalone DFS, который не интегрирован в домен, тогда лучше вариант 2 с переименованием серверов.
Подскажите пожалуйста,
есть несколько серверов DFS (в разных городах — разные сайты (site)) c репликацией,
Хочу перевезти сервер и переименовать сервер DFS, как это правильно сделать ? если просто переименовать, будет не доступен путь к папкам по старым именам, это нужно будет каждую удалить и заново добавить ? тогда пойдет заново репликация ?
как переименовать сервер и все пути к папкам с новым названием?
Добрый день!
А можно из двух или трёх физических серверов сделать кластер ради одной большой шары без применения SAN/NAS? т.е сервер сдох да и ладно лиж бы для пользователей прозрачно и без простоя, а потом спокойно новый добавить и на нем полная реплика прошла.
Да, можно. Но при большом объеме изменяемых данных могут затыки синхронизации. Поэтому для высоконагруженной среды, когда сотни пользователей одновременно открывают много файлов на RW — могут появляться конфликты. Особенно если правят одни и те же файлы.
Может кто-то подсказать, где смотреть логи переключения конечного объекта (папки)? Что бы видеть, кто переключил и в какое время.
Есть DFS с каталогами внутри с разными доменными правами, все работает не первый год. Но все пользователи (и программы) могут писать файлы и каталоги в корень dfs, чего быть не должно, только в доступные каталоги.
Как запретить писать в корень DFS?
сам спросил, сам отвечу. На сервере в каталоге корни dfs в безопасности запретил пользователям создание файлов и каталогов