DFSR · 16 мин чтения

DFS Replication для филиалов: синхронизация файлов между офисами

Меня зовут Семёнов Евгений Сергеевич, директор АйТи Фреш. За 15+ лет я настраивал DFS Replication примерно в полусотне компаний с филиалами — от стоматологической сети на 5 клиник до строительной компании с 12 площадками по всей России. Тема классическая, но с кучей нюансов: топология, staging, bandwidth, backlog. И каждый раз, когда беру на поддержку чужую инфраструктуру, нахожу там типичные ошибки, из-за которых репликация «вроде работает», но по факту не синхронизирует половину файлов. В этой статье — рабочий гайд без теории.

Когда нужен DFSR

DFS Replication — встроенный механизм Windows Server для синхронизации содержимого папок между серверами. Он использует remote differential compression (RDC), поэтому передаёт только изменённые блоки файлов, а не файлы целиком. Идеален для следующих задач:

У нас на практике главное преимущество DFSR перед «просто shared folder через VPN» — локальный доступ. Сотрудник в Хабаровске работает с файлом на хабаровском сервере со скоростью сети, а не через 6000 км VPN-туннель до Москвы.

Архитектура: hub-spoke и full mesh

Выбор топологии — главное решение перед настройкой. Три варианта:

ТопологияКогдаПлюсыМинусы
Hub-Spoke1 HQ + 2–10 филиаловПростая, мало соединенийHQ — единая точка отказа, долгая синхра между филиалами
Full Mesh3–5 филиалов без явного HQБыстрая синхронизация все-со-всемиМного соединений: N*(N-1)/2
ГибридРегиональные хабы с филиаламиБаланс между скоростью и нагрузкойСложнее планирование

Я почти всегда беру hub-spoke для 2–5 филиалов и гибрид для 6+. Full mesh хорош только при небольшом числе участников и одинаковой важности узлов.

Требования к серверам

DFSR жрёт ресурсы при большом числе файлов. Обязательные требования:

В серьёзной инсталляции на головном сервере я ставлю Dell с Xeon Platinum 8280, 64 ГБ RAM, 2× 4 ТБ NVMe — этого хватает на реплику до 5 ТБ данных и десяток филиалов. В дата-центре МТС с 40G Mellanox головного аплинка нагрузка на сеть распределяется без проблем.

Подготовка серверов и установка роли

Ставим роли File Server + DFS Namespaces + DFS Replication:

Install-WindowsFeature FS-DFS-Namespace, FS-DFS-Replication, FS-FileServer `
  -IncludeManagementTools

Создаём папку для реплики и папку staging на отдельном диске:

# На каждом сервере
New-Item -Path "D:\Shares\Projects" -ItemType Directory -Force
New-Item -Path "S:\DfsrStaging" -ItemType Directory -Force
New-SmbShare -Name "Projects" -Path "D:\Shares\Projects" -FullAccess "Domain Admins" -ChangeAccess "DomainUsers"

Staging folder на отдельном диске — критически важная практика. Если поставить staging на тот же диск, что и реплика, при большом изменении файлов диск 100% занят служебной записью, и система встаёт.

Создание replication group

Я всегда делаю через PowerShell — воспроизводимо и без риска накликать в GUI. Мастер dfsmgmt.msc тоже работает.

# Создаём группу репликации
New-DfsReplicationGroup -GroupName "Projects-RG" `
  -Description "Репликация проектной папки между HQ и филиалами"

# Добавляем участников
Add-DfsrMember -GroupName "Projects-RG" `
  -ComputerName "FS-HQ", "FS-BR1", "FS-BR2", "FS-BR3"

# Создаём replicated folder
New-DfsReplicatedFolder -GroupName "Projects-RG" `
  -FolderName "Projects"

# Прописываем локальные пути на каждом сервере
Set-DfsrMembership -GroupName "Projects-RG" `
  -FolderName "Projects" -ContentPath "D:\Shares\Projects" `
  -ComputerName "FS-HQ" -PrimaryMember $true -Force

foreach ($srv in "FS-BR1","FS-BR2","FS-BR3") {
  Set-DfsrMembership -GroupName "Projects-RG" `
    -FolderName "Projects" -ContentPath "D:\Shares\Projects" `
    -ComputerName $srv -Force
}

PrimaryMember — это сервер, с которого стартует начальная синхронизация. Остальные получают копию.

Топология соединений

По умолчанию DFSR создаёт full mesh — все со всеми. Для hub-spoke удаляем лишние и оставляем только HQ ↔ филиалы:

# Hub-spoke: HQ — центр
Remove-DfsrConnection -GroupName "Projects-RG" `
  -SourceComputerName "FS-BR1" -DestinationComputerName "FS-BR2" -Force
# (повторяем для всех пар филиалов)

# Убеждаемся, что HQ↔филиалы есть
Add-DfsrConnection -GroupName "Projects-RG" `
  -SourceComputerName "FS-HQ" -DestinationComputerName "FS-BR1" -Force
# (повторить для остальных)

Staging folder и квоты

Размер staging — первый источник проблем у всех, кто ставит DFSR впервые. Формула: минимум размер 32 самых крупных файлов в папке. Для CAD-проектов, видеоархивов, баз данных ставлю 64–128 ГБ:

Set-DfsrMembership -GroupName "Projects-RG" `
  -FolderName "Projects" -ComputerName "FS-HQ" `
  -ContentPath "D:\Shares\Projects" `
  -StagingPath "S:\DfsrStaging\Projects" `
  -StagingPathQuotaInMB 102400 `
  -ConflictAndDeletedPath "S:\DfsrConflictAndDeleted\Projects" `
  -ConflictAndDeletedQuotaInMB 20480 -Force

Расписание и throttling

По умолчанию DFSR синхронизируется 24/7 на полной скорости. Для филиалов с узким каналом это плохо: днём рабочие чертежи залили, сервер в Москве принимает 200 Мбит и кладёт филиалу интернет. Надо ограничивать:

# Установка пропускной способности для конкретного соединения
Set-DfsrConnectionSchedule -GroupName "Projects-RG" `
  -SourceComputerName "FS-HQ" -DestinationComputerName "FS-BR1" `
  -ScheduleType UseCustomSchedule `
  -BandwidthDetail (
    @{Day="Monday..Friday"; HourRange="8:00-19:00"; BandwidthIn=8192},   # 8 Мбит рабочее время
    @{Day="Monday..Friday"; HourRange="19:00-8:00"; BandwidthIn=0},      # unlimited ночью
    @{Day="Saturday..Sunday"; HourRange="All"; BandwidthIn=0}
  )

В GUI то же самое рисуется цветной сеткой в свойствах соединения — удобно визуально проверить.

DFSN поверх DFSR

Чтобы пользователи не лезли напрямую на \\fs-hq\projects, а ходили через логическое имя \\corp.ru\projects с автоматическим выбором ближайшего сервера — добавляем DFS Namespace:

New-DfsnRoot -TargetPath "\\FS-HQ\Projects" `
  -Type DomainV2 -Path "\\corp.ru\Projects"

Add-DfsnRootTarget -Path "\\corp.ru\Projects" -TargetPath "\\FS-BR1\Projects"
Add-DfsnRootTarget -Path "\\corp.ru\Projects" -TargetPath "\\FS-BR2\Projects"

DFSN-клиент на рабочем месте автоматически выбирает сервер в своём AD-сайте — пользователь из Казани ходит на FS-BR1, из Москвы — на FS-HQ.

Реальный кейс: сеть стоматологий

В феврале 2025 клиент — сеть стоматологических клиник, 6 филиалов в Москве — захотела централизовать работу с клиентскими снимками КТ. Проблема: каждая клиника хранила снимки локально, стоматолог из клиники №3 не видел историю пациента из клиники №1. Снимки весят по 200–500 МБ, всего 2 ТБ.

Развернули DFSR hub-spoke: HQ в головном офисе на Dell с Xeon Platinum 8280, 64 ГБ RAM, 4 ТБ NVMe в дата-центре МТС. Шесть филиалов — по серверу 2U на каждый. Каналы 100 Мбит между филиалами и HQ. Staging folder 100 ГБ, throttling 20 Мбит в рабочее время / unlimited ночью. DFSN \\corp.stomadent.ru\CT-images.

Первичная синхронизация 2 ТБ на каждый филиал заняла 3–4 дня на каналах 100 Мбит. Дальше инкрементальные изменения — до 200 МБ в день, укладываются в пятнадцать минут. Стоматологи стали видеть снимки из других клиник. Стоимость проекта — 170 000 руб. на развёртывание плюс стоимость шести серверов для филиалов. Окупилось экономией времени врачей за полгода.

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

DFSR требует постоянного наблюдения. Основные команды:

# Очередь синхронизации
dfsrdiag backlog /rgname:"Projects-RG" /rfname:"Projects" /smem:FS-HQ /rmem:FS-BR1

# Форсировать репликацию сейчас
dfsrdiag syncnow /partner:FS-HQ /rgname:"Projects-RG" /time:60

# Состояние репликации на локальном сервере
dfsrdiag replicationstate /member:FS-HQ /verbose

# Проверка здоровья
Get-DfsrState -ComputerName "FS-HQ"

# Репорт health check
Get-DfsrBacklog -GroupName "Projects-RG" -SourceComputerName "FS-HQ" -DestinationComputerName "FS-BR1"

Я настраиваю алерт, если backlog > 500 файлов в течение часа. Это ранний сигнал проблемы.

Типичные грабли

Настроим DFSR между вашими филиалами

Я лично проектирую и внедряю DFS Replication для компаний с 2–20 филиалами. Выбор топологии, настройка staging, throttling, DFS Namespace, мониторинг — под ключ. Срок — от 5 рабочих дней.

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

FAQ

В чём разница DFS Namespaces и DFS Replication?
DFSN — это логические пути \\corp\shared, которые указывают на разные сервера. DFSR — механизм блочной синхронизации содержимого между серверами. Обычно используются вместе: DFSN даёт единую точку входа, DFSR держит данные в синхроне.
Какая топология лучше: hub-spoke или full mesh?
Hub-spoke (звезда) — когда один центральный офис и несколько филиалов. Full mesh — когда все филиалы должны видеть друг друга. На практике для 2–5 филиалов чаще hub-spoke с штаб-квартирой.
Какой размер Staging folder задать?
Microsoft рекомендует брать размер 32 самых больших файлов. Минимум — 4 ГБ. Для видеоархивов, CAD-чертежей ставлю 50–100 ГБ. При маленьком staging реплика зависает на больших файлах.
Можно ли ограничить пропускную способность?
Да, через Bandwidth Schedule в свойствах соединения репликации. Можно по часам задать 128 Кбит/с ночью и 4 Мбит/с в рабочее время. Или запрещать репликацию в пиковые часы.
Как диагностировать проблемы DFSR?
Командой dfsrdiag. Ключевые: dfsrdiag backlog (очередь), dfsrdiag syncnow (форсировать), dfsrdiag replicationstate (состояние). Плюс журнал DFS Replication в Event Viewer.

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

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

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

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