Windows Server · 16 мин чтения

DFS Namespaces и Replication в Windows Server: что мы делаем у клиентов

Меня зовут Семёнов Евгений Сергеевич, я директор АйТи Фреш. DFS (Distributed File System) — это та технология, про которую все знают, но мало кто умеет правильно настраивать. За 15 лет я развернул её у двух десятков клиентов: от мелких офисов на 10 человек до распределённых компаний с тремя филиалами в разных городах. В статье делюсь практикой: какие задачи DFS реально решает, как правильно проектировать пространство имён и репликацию, и какие грабли поджидают неопытного админа.

Зачем вообще DFS, если есть просто шары?

Самый частый аргумент: «у нас уже файловый сервер, всё работает». Соглашусь, для офиса из 5 человек DFS не нужна. А вот когда появляется второй сервер, или второй офис, или нужно перенести большую шару между машинами без простоя — без DFS становится больно.

Что DFS даёт на практике:

Архитектура DFS: что под капотом

Технически DFS — это две независимые роли, которые часто работают вместе:

В типовом проекте я делаю Domain-based Namespace + два-три DFSR-таргета. Standalone использую только в тех случаях, когда клиент категорически против AD (что в 2026 году бывает крайне редко).

Что нужно перед установкой DFS

Чек-лист, без которого я не начинаю:

  1. Active Directory с уровнем функциональности леса 2008 R2 или выше (для DFSR с поддержкой большого числа объектов).
  2. Минимум один сервер 2019/2022 на роль Namespace Server. Лучше два или три для отказоустойчивости.
  3. Серверы-таргеты с дисковым пространством под данные + 20 % запаса на staging area DFSR.
  4. Стабильное сетевое подключение между серверами. Для филиалов с медленными каналами обязательно настроить ограничение полосы пропускания DFSR в расписании.
  5. Понимание объёмов: сколько файлов, какой средний размер, как часто меняются, кто и откуда работает.
  6. Решённый вопрос с правами NTFS — DFS их не правит, права остаются как есть на исходных шарах.

Установка DFS Namespaces и DFS Replication

На Windows Server 2022 ставится через Server Manager или PowerShell. PowerShell быстрее:

# На сервере, который будет Namespace Server
Install-WindowsFeature -Name FS-DFS-Namespace -IncludeManagementTools

# На серверах, которые будут хранить данные
Install-WindowsFeature -Name FS-DFS-Replication -IncludeManagementTools

# Проверяем установленные роли
Get-WindowsFeature -Name FS-DFS-* | Where-Object Installed

Никакой перезагрузки не требуется, обе роли поднимаются на горячую. Дальше открываем DFS Management (dfsmgmt.msc) и начинаем создавать пространство имён.

Создание Domain-based Namespace

Через GUI:

  1. В DFS Management → Namespaces → New Namespace.
  2. Выбираем сервер, который будет Namespace Server (например, FS01).
  3. Указываем имя — например, Files. Получится \\company.local\Files.
  4. Выбираем Domain-based namespace и Mode 2008 (это дефолт для современных лесов, поддерживает access-based enumeration и до 50 000 папок).
  5. Готово. Namespace создан, можно добавлять folders.

То же самое через PowerShell:

# Создание domain-based namespace
New-DfsnRoot -TargetPath "\\FS01\Files" -Type DomainV2 -Path "\\company.local\Files"

# Добавляем второй namespace server для отказоустойчивости
New-DfsnRootTarget -TargetPath "\\FS02\Files" -Path "\\company.local\Files"

# Добавляем папку (link) в namespace
New-DfsnFolder -Path "\\company.local\Files\Documents" -TargetPath "\\FS01\Documents$"

# Добавляем второй target к этой папке
New-DfsnFolderTarget -Path "\\company.local\Files\Documents" -TargetPath "\\FS02\Documents$"

Настройка DFS Replication между серверами

DFSR работает группами репликации (Replication Group), внутри которых задаются папки и расписание. Настроим простой сценарий: репликация папки Documents между FS01 в Москве и FS02 в Новосибирске.

Через DFS Management:

  1. Replication → New Replication Group.
  2. Multi-purpose replication group.
  3. Имя — DocumentsReplication.
  4. Добавляем серверы FS01 и FS02.
  5. Топология — Full mesh (для двух серверов).
  6. Полоса пропускания — Full bandwidth для теста, потом ограничим.
  7. Primary member — FS01 (с него реплика пойдёт на FS02).
  8. Папка для репликации — D:\Documents на FS01.
  9. На FS02 указываем локальный путь — D:\Documents, и оставляем Disabled на старте, чтобы первая полная репликация прошла.

Через PowerShell, что я обычно делаю в скрипте автоматизации:

$RGName = "DocumentsReplication"
$Folder = "Documents"

# Создаём группу репликации
New-DfsReplicationGroup -GroupName $RGName

# Добавляем серверы
Add-DfsrMember -GroupName $RGName -ComputerName FS01,FS02

# Добавляем папку
New-DfsReplicatedFolder -GroupName $RGName -FolderName $Folder

# Указываем локальный путь на каждом сервере
Set-DfsrMembership -GroupName $RGName -FolderName $Folder -ComputerName FS01 \
    -ContentPath "D:\Documents" -PrimaryMember $true -Force

Set-DfsrMembership -GroupName $RGName -FolderName $Folder -ComputerName FS02 \
    -ContentPath "D:\Documents" -Force

# Создаём двунаправленное подключение
Add-DfsrConnection -GroupName $RGName -SourceComputerName FS01 -DestinationComputerName FS02

Расписание и ограничение полосы пропускания

Это самый частый недочёт у админов: запустили DFSR с full bandwidth и удивляются, почему канал между офисами лежит. Между Москвой и регионом канал обычно 50–200 Mbit, и если там полночь идёт реплика 200 GB изменений за день, утром все сидят без интернета.

В DFS Management → Replication Group → Connections → правый клик → Schedule and Bandwidth. Я обычно ставлю:

Через PowerShell:

# Ограничить пропускную способность 16 Mbit с 9 до 19 в будни
Set-DfsrConnectionSchedule -GroupName "DocumentsReplication" \
    -SourceComputerName FS01 -DestinationComputerName FS02 \
    -ScheduleType Custom -BandwidthDetail @{
        Monday = @{Hour9_19 = 16; Hour19_24 = "Full"}
        # ... аналогично для остальных дней
    }

Как работает разрешение конфликтов

Когда один и тот же файл изменили на двух серверах одновременно, DFSR применяет правило «last writer wins». Побеждает версия с более поздним timestamp (с точностью до 100 нс). Проигравший файл не удаляется, а переименовывается с уникальным GUID и кладётся в специальную папку DfsrPrivate\ConflictAndDeleted на сервере, который этот файл проиграл.

Восстановить проигравшую версию можно вручную через утилиту Conflict and Deleted Manifest:

# PowerShell: показать все конфликтные файлы
Get-DfsrPreservedFiles -ComputerName FS02 -FolderName "Documents"

# Восстановить конкретный файл
Restore-DfsrPreservedFiles -ComputerName FS02 -FolderName "Documents" \
    -FileName "Report.docx" -Path "D:\Restore"

Размер папки ConflictAndDeleted ограничивается квотой (по умолчанию 660 MB или 4 GB в зависимости от размера папки). Старые файлы вытесняются. Если у клиента активная работа в общих файлах, я часто увеличиваю квоту до 50 GB и использую её как «короткую корзину» для экстренного восстановления.

Миграция SYSVOL с FRS на DFSR

До сих пор у меня периодически попадаются домены 2003/2008, где SYSVOL реплицируется через древний FRS, и админ боится мигрировать. Зря. Процедура отработана, занимает один вечер, и без неё нельзя поднимать функциональный уровень леса.

Шаги через dfsrmig.exe (запускать с PDC Emulator):

# Проверяем текущее состояние
dfsrmig /getmigrationstate
# Должно быть: All Domain Controllers have migrated to the Start state (0).

# Переходим в Prepared (state 1)
dfsrmig /setglobalstate 1
# Ждём, проверяем
dfsrmig /getmigrationstate

# Когда все DC синхронизировались — Redirected (state 2)
dfsrmig /setglobalstate 2
# Ждём окончания

# Финал — Eliminated (state 3), удаляет FRS
dfsrmig /setglobalstate 3

Между состояниями жду минимум 24 часа на больших доменах, чтобы все DC успели среплицироваться. Если что-то идёт не так — на этапе Prepared и Redirected можно откатиться обратно. После Eliminated — точка невозврата, FRS удалён.

Мониторинг и диагностика DFS

На каждый DFS-сервер я ставлю в Zabbix несколько проверок:

Полезные команды для диагностики, которые я регулярно использую:

# Проверить состояние всех DFSR-членов
Get-DfsReplicationGroup | Get-DfsrMember

# Backlog файлов между двумя серверами
Get-DfsrBacklog -GroupName "DocumentsReplication" -FolderName "Documents" \
    -SourceComputerName FS01 -DestinationComputerName FS02

# Состояние реплицируемой папки
Get-DfsrState -ComputerName FS02

# Тест разрешения путей DFSN
dfsutil /pktinfo
dfsutil diag viewdfspath \\company.local\Files\Documents

Лучшие практики, которые я вынес из 15 лет

  1. Не складывайте в DFSR файлы баз данных. SQL, 1С, Postgres — нет. DFSR не умеет реплицировать открытые файлы по дельте, и у вас будут постоянные конфликты. Для баз — Always On Availability Groups или специализированная репликация.
  2. Не реплицируйте папку Outlook OST. Файлы кэша почты по 50 GB, активно меняются, генерируют постоянный поток — убивают канал и базу DFSR.
  3. Включайте RDC только на медленных каналах. На локальной гигабитной сети RDC создаёт лишнюю нагрузку на CPU и не даёт выигрыша.
  4. Регулярно делайте Health Report. В DFS Management → Replication → Create Diagnostic Report. Пробегайте отчёт раз в месяц.
  5. Антивирус на сервере с DFSR требует исключений. Папка контента + папка DfsrPrivate + база ESE. Иначе AV открывает файлы, DFSR пытается их синхронизировать, начинаются конфликты.
  6. Защита от шифровальщиков. DFSR честно среплицирует зашифрованные файлы на все таргеты. Поэтому DFSR — это не бэкап, нужна отдельная стратегия с теневыми копиями и off-site бэкапами.
  7. Документируйте схему репликации. Через год вы забудете, какая папка куда реплицируется. Я веду в Confluence таблицу: Replication Group → Folder → Members → Schedule.

Кейс: DFS для торговой компании с 4 филиалами

В декабре 2025 нас позвали в торговую компанию: офис в Москве, филиалы в Питере, Краснодаре и Екатеринбурге, по 12–18 рабочих мест в каждом. До этого они работали так: каждый филиал жил на своём маленьком файловом сервере, документы передавались по почте и в чатах. Куча версий одного и того же договора, никто не понимает, какая актуальная.

За три недели мы развернули единую DFS-инфраструктуру:

Через полгода компания выросла до 5 филиалов — добавление нового заняло 2 часа: установка таргета, добавление в namespace, дождались первой синхронизации. Никаких изменений на рабочих местах.

Нужно развернуть или починить DFS у вас в офисе?

Я лично выезжаю на аудит инфраструктуры в Москве и в радиусе 50 км от МКАД. Проектирую DFS под ваши задачи, разворачиваю Namespaces и DFSR, обучаю ваших админов. Без обязательств.

Телефон: +7 903 729-62-41
Telegram: @ITfresh_Boss
Семёнов Евгений Сергеевич, директор АйТи Фреш

FAQ — частые вопросы по DFS

В чём разница между DFS Namespaces и DFS Replication?
Namespaces создают единое имя \\company.local\Files, за которым прячутся реальные шары на разных серверах. Replication копирует данные между серверами по дельте RDC.
Можно ли использовать DFSR без домена?
Нет, DFSR требует Active Directory. Альтернативы для рабочих групп: Robocopy с расписанием, Resilio Sync, Syncthing.
Какой максимальный размер реплицируемой папки в DFSR?
На Windows Server 2012 R2+ теоретического лимита нет. Практически 100 TB и миллион файлов работают, дальше начинаются проблемы.
Что делать при конфликте имён в DFSR?
DFSR разрешает по timestamp: побеждает более позднее изменение. Проигравший файл переименовывается и кладётся в ConflictAndDeleted.
Как мигрировать SYSVOL с FRS на DFSR?
Через dfsrmig.exe в 4 этапа: state 0 → 1 → 2 → 3. Между состояниями ждём окончания репликации.

Подпишитесь на рассылку ITfresh

Раз в неделю — практические гайды для руководителя IT и сисадмина: безопасность, 1С, миграции, резервные копии, лайфхаки из реальных проектов.

Реквизиты оператора персональных данных

ООО «АЙТИ-ФРЕШ», ИНН 7719418495, КПП 771901001. Юридический адрес: 105523, г. Москва, Щёлковское шоссе, д. 92, корп. 7. Контакт: info@itfresh.ru, +7 903 729-62-41. Оператор обрабатывает e-mail подписчика в целях рассылки информационных и рекламных материалов до момента отзыва согласия.