5 филиалов и 5 версий одного файла: DFS-репликация для логистической компании

Прежде чем предлагать решение, мы объехали каждый филиал и собрали реальную картину. Она оказалась, мягко говоря, пёстрой:

• Самара (головной) — Windows Server 2022, файловый сервер с общими папками, 850 ГБ данных, Active Directory
• Казань — Windows Server 2019, локальный файловый сервер, 320 ГБ данных, присоединён к домену через site-to-site VPN
• Нижний Новгород — Windows Server 2019, аналогично Казани, 280 ГБ
• Пермь — NAS Synology DS920+, не в домене, 200 ГБ данных
• Уфа — общие папки на рабочей станции Windows 11 Pro (!!!), 150 ГБ

Связь между офисами — site-to-site VPN на MikroTik, полоса от 20 до 50 Мбит/с в зависимости от направления. Проблемы вырисовывались сами собой:

• Нет единого пространства имён — пользователи подключают сетевые диски вручную по IP-адресам
• Нет автоматической репликации — файлы копируются вручную или через почту
• Конфликты версий — два человека редактируют один файл, побеждает «последний сохранивший»
• Пермь и Уфа — вне домена, нет централизованного управления

Выбор пал на связку DFS Namespaces + DFS Replication (DFSR) — компоненты, встроенные прямо в Windows Server, без доплат за лицензии. Почему не облако или сторонние решения? Сравнили варианты — DFS выиграл по совокупности факторов:

Нативная интеграция с Active Directory, ноль дополнительных затрат и полная прозрачность для сотрудников. Люди работают с привычным UNC-путём \\roslogistic.local\shared и даже не подозревают, с какого именно сервера в данный момент получают файл. Это принципиально важно, когда менять привычки 180 человек никто не собирается.

Архитектура получилась следующая:

# Архитектура DFS
┌─────────────────────────────────────────────────────┐
│     DFS Namespace: \\roslogistic.local\shared       │
│     (Domain-based, Windows Server mode)              │
└───────────┬──────────────┬──────────────┬───────────┘
            │              │              │
     ┌──────▼──────┐ ┌────▼──────┐ ┌─────▼─────┐
     │  Самара     │ │  Казань   │ │  Н.Новгород│
     │  DC01-SAM   │ │  FS-KAZ   │ │  FS-NNO   │
     │  (Hub)      │ │  (Spoke)  │ │  (Spoke)  │
     └──────┬──────┘ └───────────┘ └───────────┘
            │
     ┌──────▼──────┐ ┌────────────┐
     │  Пермь     │ │  Уфа       │
     │  FS-PRM    │ │  FS-UFA    │
     │  (Spoke)   │ │  (Spoke)   │
     └────────────┘ └────────────┘

  Топология: Hub-and-Spoke (Самара — центр)

Пермь и Уфа потребовали отдельной работы. В Перми Synology заменили на Windows Server 2022 Standard — подняли виртуальную машину на уже имеющемся Hyper-V хосте, железо докупать не пришлось. В Уфе история грустнее: файловый сервер на рабочей станции с Windows 11 Pro — это, конечно, не дело, поэтому развернули нормальный сервер с нуля:

# Пермь: установка Windows Server 2022 на Hyper-V
# После установки ОС — присоединение к домену
Add-Computer -DomainName roslogistic.local -Credential (Get-Credential) -Restart

# Уфа: аналогично, после установки
Add-Computer -DomainName roslogistic.local -Credential (Get-Credential) -Restart

# Проверяем, что все серверы в домене
Get-ADComputer -Filter * -SearchBase "OU=Servers,DC=roslogistic,DC=local" | Select-Object Name, DNSHostName

# Name        DNSHostName
# ----        -----------
# DC01-SAM    dc01-sam.roslogistic.local
# FS-KAZ      fs-kaz.roslogistic.local
# FS-NNO      fs-nno.roslogistic.local
# FS-PRM      fs-prm.roslogistic.local
# FS-UFA      fs-ufa.roslogistic.local

Роли DFS Namespaces и DFS Replication ставятся через Server Manager или PowerShell — кому как удобнее:

# На каждом файловом сервере (можно удалённо через Invoke-Command)
$servers = @('DC01-SAM','FS-KAZ','FS-NNO','FS-PRM','FS-UFA')

Invoke-Command -ComputerName $servers -ScriptBlock {
    Install-WindowsFeature -Name FS-DFS-Namespace, FS-DFS-Replication -IncludeManagementTools
    Get-WindowsFeature FS-DFS* | Format-Table Name, InstallState
}

# Результат на каждом сервере:
# Name                    InstallState
# ----                    ------------
# FS-DFS-Namespace        Installed
# FS-DFS-Replication      Installed

На каждом сервере создали единообразную структуру папок — это важно для последующей настройки репликации:

# Создаём корневую папку для DFS-данных
$servers | ForEach-Object {
    Invoke-Command -ComputerName $_ -ScriptBlock {
        New-Item -Path 'D:\DFSRoots\Shared' -ItemType Directory -Force
        New-Item -Path 'D:\DFSStaging' -ItemType Directory -Force

        # Создаём SMB-шару
        New-SmbShare -Name 'Shared' -Path 'D:\DFSRoots\Shared' -FullAccess 'ROSLOGISTIC\Domain Admins' -ChangeAccess 'ROSLOGISTIC\Domain Users'
    }
}

# Создаём доменное пространство имён
New-DfsnRoot -TargetPath '\\DC01-SAM\Shared' -Type DomainV2 -Path '\\roslogistic.local\shared' -Description 'Общие файлы РосЛогистик'

# Добавляем целевые папки (folder targets) для каждого филиала
# Папка "Документы" — реплицируется на все серверы
New-DfsnFolder -Path '\\roslogistic.local\shared\Документы' -TargetPath '\\DC01-SAM\Shared\Документы'
New-DfsnFolderTarget -Path '\\roslogistic.local\shared\Документы' -TargetPath '\\FS-KAZ\Shared\Документы'
New-DfsnFolderTarget -Path '\\roslogistic.local\shared\Документы' -TargetPath '\\FS-NNO\Shared\Документы'
New-DfsnFolderTarget -Path '\\roslogistic.local\shared\Документы' -TargetPath '\\FS-PRM\Shared\Документы'
New-DfsnFolderTarget -Path '\\roslogistic.local\shared\Документы' -TargetPath '\\FS-UFA\Shared\Документы'

# Папка "Бухгалтерия" — только Самара и филиал, где работают бухгалтеры
New-DfsnFolder -Path '\\roslogistic.local\shared\Бухгалтерия' -TargetPath '\\DC01-SAM\Shared\Бухгалтерия'
New-DfsnFolderTarget -Path '\\roslogistic.local\shared\Бухгалтерия' -TargetPath '\\FS-KAZ\Shared\Бухгалтерия'

# Папка "Шаблоны" — реплицируется read-only на филиалы
New-DfsnFolder -Path '\\roslogistic.local\shared\Шаблоны' -TargetPath '\\DC01-SAM\Shared\Шаблоны'

# Проверяем пространство имён
Get-DfsnFolder -Path '\\roslogistic.local\shared\*' | Format-Table Path, State

# Path                                           State
# ----                                           -----
# \\roslogistic.local\shared\Документы           Online
# \\roslogistic.local\shared\Бухгалтерия         Online
# \\roslogistic.local\shared\Шаблоны             Online

Чтобы клиенты всегда обращались к ближайшему серверу, настроили AD Sites and Services и порядок referral. Без этого шага DFS работает, но медленно и непредсказуемо — проверено на собственных граблях:

# AD Sites (должны быть уже настроены, если нет — создаём)
# Site: Samara — subnet 10.10.1.0/24
# Site: Kazan — subnet 10.10.2.0/24
# Site: NNovgorod — subnet 10.10.3.0/24
# Site: Perm — subnet 10.10.4.0/24
# Site: Ufa — subnet 10.10.5.0/24

New-ADReplicationSite -Name 'Samara'
New-ADReplicationSite -Name 'Kazan'
New-ADReplicationSite -Name 'NNovgorod'
New-ADReplicationSite -Name 'Perm'
New-ADReplicationSite -Name 'Ufa'

New-ADReplicationSubnet -Name '10.10.1.0/24' -Site 'Samara'
New-ADReplicationSubnet -Name '10.10.2.0/24' -Site 'Kazan'
New-ADReplicationSubnet -Name '10.10.3.0/24' -Site 'NNovgorod'
New-ADReplicationSubnet -Name '10.10.4.0/24' -Site 'Perm'
New-ADReplicationSubnet -Name '10.10.5.0/24' -Site 'Ufa'

# Настройка referral ordering — приоритет ближайшему серверу
Set-DfsnRoot -Path '\\roslogistic.local\shared' -EnableSiteCosting $true -EnableInsiteReferrals $true

# Таймаут кэша referral — 30 минут
Set-DfsnRoot -Path '\\roslogistic.local\shared' -TimeToLiveSec 1800

Теперь при обращении к \\roslogistic.local\shared\Документы клиент в Казани первым делом получит referral на FS-KAZ. Только если тот недоступен — пойдёт на серверы других сайтов. Пользователь ничего не замечает, просто работает.

# Создаём группу репликации для папки "Документы"
New-DfsReplicationGroup -GroupName 'RG-Documents' -Description 'Репликация общих документов' | Out-Null

# Добавляем все серверы в группу
$members = @('DC01-SAM','FS-KAZ','FS-NNO','FS-PRM','FS-UFA')
$members | ForEach-Object {
    Add-DfsrMember -GroupName 'RG-Documents' -ComputerName $_
}

# Добавляем реплицируемую папку
Add-DfsrReplicatedFolder -GroupName 'RG-Documents' -FolderName 'Документы'

# Настраиваем пути на каждом сервере
Set-DfsrMembership -GroupName 'RG-Documents' -FolderName 'Документы' -ComputerName 'DC01-SAM' -ContentPath 'D:\DFSRoots\Shared\Документы' -PrimaryMember $true -StagingPathQuotaInMB 32768
Set-DfsrMembership -GroupName 'RG-Documents' -FolderName 'Документы' -ComputerName 'FS-KAZ' -ContentPath 'D:\DFSRoots\Shared\Документы' -StagingPathQuotaInMB 16384
Set-DfsrMembership -GroupName 'RG-Documents' -FolderName 'Документы' -ComputerName 'FS-NNO' -ContentPath 'D:\DFSRoots\Shared\Документы' -StagingPathQuotaInMB 16384
Set-DfsrMembership -GroupName 'RG-Documents' -FolderName 'Документы' -ComputerName 'FS-PRM' -ContentPath 'D:\DFSRoots\Shared\Документы' -StagingPathQuotaInMB 8192
Set-DfsrMembership -GroupName 'RG-Documents' -FolderName 'Документы' -ComputerName 'FS-UFA' -ContentPath 'D:\DFSRoots\Shared\Документы' -StagingPathQuotaInMB 8192

Для пяти точек выбрали топологию Hub-and-Spoke: центральный сервер в Самаре связан с каждым филиалом напрямую, филиалы между собой — нет. Проще управлять, меньше трафика на слабых каналах:

# Создаём соединения Hub-and-Spoke (Самара — центр)
$spokes = @('FS-KAZ','FS-NNO','FS-PRM','FS-UFA')

foreach ($spoke in $spokes) {
    Add-DfsrConnection -GroupName 'RG-Documents' `
        -SourceComputerName 'DC01-SAM' `
        -DestinationComputerName $spoke `
        -Description "SAM <-> $spoke"
}

# Настраиваем ограничение полосы (bandwidth throttling)
# Каналы до филиалов: Казань 50 Мбит, Н.Новгород 30 Мбит, Пермь 20 Мбит, Уфа 20 Мбит
# Ограничиваем DFSR до 50% канала в рабочее время и 90% ночью

# Расписание для FS-KAZ: рабочее время 9:00-18:00 — 25 Мбит (50%)
Set-DfsrConnectionSchedule -GroupName 'RG-Documents' `
    -SourceComputerName 'DC01-SAM' `
    -DestinationComputerName 'FS-KAZ' `
    -Day Monday,Tuesday,Wednesday,Thursday,Friday `
    -BandwidthDetail @{TimeSlotIndex=36; Bandwidth='25Mbps'}

# Ночное время 22:00-06:00 — 45 Мбит (90%)
Set-DfsrConnectionSchedule -GroupName 'RG-Documents' `
    -SourceComputerName 'DC01-SAM' `
    -DestinationComputerName 'FS-KAZ' `
    -Day Monday,Tuesday,Wednesday,Thursday,Friday `
    -BandwidthDetail @{TimeSlotIndex=88; Bandwidth='45Mbps'}

# Для Перми и Уфы — более жёсткие ограничения
Set-DfsrConnectionSchedule -GroupName 'RG-Documents' `
    -SourceComputerName 'DC01-SAM' `
    -DestinationComputerName 'FS-PRM' `
    -Day Monday,Tuesday,Wednesday,Thursday,Friday `
    -BandwidthDetail @{TimeSlotIndex=36; Bandwidth='10Mbps'}

Staging folder — промежуточное хранилище, куда DFSR складывает файлы перед отправкой партнёру. Размер staging — одна из тех настроек, которую все игнорируют, а потом удивляются, почему репликация тормозит:

# Рекомендация Microsoft: staging quota = 32 × размер крупнейших файлов
# У РосЛогистик самые крупные файлы — сканы договоров до 50 МБ
# 32 × 50 МБ = 1600 МБ — но мы ставим с запасом

# Проверяем текущие настройки staging
Get-DfsrMembership -GroupName 'RG-Documents' | Select-Object ComputerName, ContentPath, StagingPath, StagingPathQuotaInMB | Format-Table

# ComputerName  ContentPath                        StagingPath                             StagingPathQuotaInMB
# ------------  -----------                        -----------                             --------------------
# DC01-SAM      D:\DFSRoots\Shared\Документы       D:\DFSRoots\Shared\Документы\DfsrPrivate\Staging  32768
# FS-KAZ        D:\DFSRoots\Shared\Документы       D:\DFSRoots\Shared\Документы\DfsrPrivate\Staging  16384
# FS-NNO        D:\DFSRoots\Shared\Документы       D:\DFSRoots\Shared\Документы\DfsrPrivate\Staging  16384
# FS-PRM        D:\DFSRoots\Shared\Документы       D:\DFSRoots\Shared\Документы\DfsrPrivate\Staging  8192
# FS-UFA        D:\DFSRoots\Shared\Документы       D:\DFSRoots\Shared\Документы\DfsrPrivate\Staging  8192

# Перемещаем staging на отдельный диск для лучшей производительности (если есть)
# На DC01-SAM:
Set-DfsrMembership -GroupName 'RG-Documents' -FolderName 'Документы' -ComputerName 'DC01-SAM' -StagingPath 'E:\DFSStaging\Документы'

Когда staging переполняется, DFSR начинает его принудительно чистить — и скорость репликации падает в разы. Мы настроили мониторинг размера staging через SCOM, чтобы поймать проблему до того, как её заметят пользователи.

При конфликте DFSR применяет два правила — в строгом порядке:

• Для существующих файлов — побеждает тот, у кого дата модификации свежее. Если временны́е метки совпадают, система выбирает файл с сервера с бо́льшим GUID — тай-брейкер, о котором мало кто знает заранее
• Для новых файлов/папок с одинаковым именем — побеждает тот, кто создан раньше. Логика простая, но на практике это ловит пользователей врасплох

«Проигравшая» версия не пропадает — она уходит в папку ConflictAndDeleted:

# Проверяем квоту для конфликтных файлов
Get-DfsrMembership -GroupName 'RG-Documents' | Select-Object ComputerName, ConflictAndDeletedQuotaInMB

# По умолчанию 4096 МБ — увеличиваем на хабе
Set-DfsrMembership -GroupName 'RG-Documents' -FolderName 'Документы' -ComputerName 'DC01-SAM' -ConflictAndDeletedQuotaInMB 8192

# Скрипт для отчёта о конфликтах (запуск раз в день)
$report = Get-DfsrBacklog -GroupName 'RG-Documents' -SourceComputerName 'DC01-SAM' -DestinationComputerName 'FS-KAZ' -Verbose

# Проверяем ConflictAndDeleted на всех серверах
$members | ForEach-Object {
    $path = "\\$_\d$\DFSRoots\Shared\Документы\DfsrPrivate\ConflictAndDeleted"
    $count = (Get-ChildItem $path -ErrorAction SilentlyContinue | Measure-Object).Count
    Write-Host "$_`: $count conflicted files"
}

Чтобы конфликтов было меньше, мы ввели простое организационное правило: критические документы — договоры, прайс-листы — редактируются только в Самаре. Филиалы открывают их на чтение, доступ к записи закрыт через NTFS-права. Да, это ограничение. Зато за полгода — ни одного конфликта по этим файлам.

Чтобы рабочие папки пользователей автоматически оказывались внутри DFS, настроили перенаправление через Group Policy:

# Создаём GPO для Folder Redirection
New-GPO -Name 'DFS Folder Redirection' -Comment 'Перенаправление папок в DFS' | New-GPLink -Target 'OU=Users,DC=roslogistic,DC=local'

# Настройка через GPMC (Group Policy Management Console):
# User Configuration → Policies → Windows Settings → Folder Redirection
#
# Папка "Документы":
#   Setting: Basic - Redirect everyone's folder to the same location
#   Target folder location: Create a folder for each user under the root path
#   Root Path: \\roslogistic.local\shared\UserDocs
#   Policy Removal: Redirect the folder back to the local userprofile location
#
# Папка "Рабочий стол":
#   Root Path: \\roslogistic.local\shared\UserDesktop

# Проверяем через PowerShell
Get-GPO -Name 'DFS Folder Redirection' | Get-GPOReport -ReportType HTML -Path 'C:\temp\dfs-gpo-report.html'

# Включаем Offline Files для работы при потере связи
# Computer Configuration → Policies → Administrative Templates
# → Network → Offline Files
#   Enable Offline Files: Enabled
#   Configure slow-link mode: Enabled, Latency=80ms, Throughput=64Kbps

# Проверка бэклога репликации между серверами
Get-DfsrBacklog -GroupName 'RG-Documents' -SourceComputerName 'DC01-SAM' -DestinationComputerName 'FS-KAZ'

# Identifier                  : {A1B2C3D4-5678-9ABC-DEF0-123456789ABC}
# BacklogFileCount            : 3

# Бэклог 3 файла — нормально. Бэклог 10000+ — проблема.

# Массовая проверка бэклога
$hub = 'DC01-SAM'
$spokes = @('FS-KAZ','FS-NNO','FS-PRM','FS-UFA')

foreach ($spoke in $spokes) {
    $backlog = (Get-DfsrBacklog -GroupName 'RG-Documents' -SourceComputerName $hub -DestinationComputerName $spoke).BacklogFileCount
    $backlogReverse = (Get-DfsrBacklog -GroupName 'RG-Documents' -SourceComputerName $spoke -DestinationComputerName $hub).BacklogFileCount
    Write-Host "$hub -> ${spoke}: $backlog files | $spoke -> ${hub}: $backlogReverse files"
}

# DC01-SAM -> FS-KAZ: 3 files | FS-KAZ -> DC01-SAM: 1 files
# DC01-SAM -> FS-NNO: 0 files | FS-NNO -> DC01-SAM: 5 files
# DC01-SAM -> FS-PRM: 12 files | FS-PRM -> DC01-SAM: 0 files
# DC01-SAM -> FS-UFA: 0 files | FS-UFA -> DC01-SAM: 0 files

# Диагностика с dfsrdiag
dfsrdiag backlog /rgname:"RG-Documents" /rfname:"Документы" /sendingmember:DC01-SAM /receivingmember:FS-KAZ

# Состояние репликации
Get-DfsrState -ComputerName $hub | Format-Table FileName, UpdateState, Inbound

# Генерация отчёта о здоровье DFSR
# Запуск через Task Scheduler раз в неделю
$reportPath = 'D:\Reports\DFSR'
New-Item -Path $reportPath -ItemType Directory -Force

# Health report
Write-DfsrHealthReport -GroupName 'RG-Documents' -ReferenceComputerName 'DC01-SAM' -MemberComputerName $members -Path $reportPath -CountFiles

# Propagation report
Write-DfsrPropagationReport -GroupName 'RG-Documents' -ReferenceComputerName 'DC01-SAM' -Path $reportPath -FileCount 100

# Скрипт мониторинга с отправкой алерта в Telegram
$threshold = 100  # Бэклог больше 100 — тревога

foreach ($spoke in $spokes) {
    $backlog = (Get-DfsrBacklog -GroupName 'RG-Documents' -SourceComputerName $hub -DestinationComputerName $spoke -ErrorAction SilentlyContinue).BacklogFileCount
    if ($backlog -gt $threshold) {
        $message = "⚠ DFSR Alert: Backlog $hub -> ${spoke}: $backlog files (threshold: $threshold)"
        # Отправка в Telegram
        $token = 'BOT_TOKEN'
        $chatId = '-100XXXXXXXXXX'
        $uri = "https://api.telegram.org/bot$token/sendMessage?chat_id=$chatId&text=$message"
        Invoke-RestMethod -Uri $uri -Method Post
    }
}

DFSR — не замена резервному копированию. Удалили файл в одном филиале — удаление разъедется по всем нодам. Мы настроили бэкапы с учётом специфики DFS:

# Windows Server Backup на хаб-сервере (ежедневно)
wbadmin start backup -backupTarget:F: -include:D:\DFSRoots -vssFull -quiet

# Veeam Backup на каждом филиальном сервере (еженедельно)
# Важно: бэкапим только хаб (Самара) полностью, филиалы — по расписанию

# VSS snapshot перед бэкапом (не прерывает репликацию)
# DFSR автоматически приостанавливает репликацию во время VSS snapshot
# и возобновляет после его завершения

# Восстановление отдельного файла из ConflictAndDeleted
# (если пользователь перезаписал нужную версию)
$conflictPath = '\\DC01-SAM\d$\DFSRoots\Shared\Документы\DfsrPrivate\ConflictAndDeleted'
Get-ChildItem $conflictPath | Sort-Object LastWriteTime -Descending | Select-Object Name, Length, LastWriteTime -First 20

• Начните с AD Sites — без нормальной конфигурации сайтов DFS referral будет гонять клиентов куда угодно, но не на ближайший сервер
• Hub-and-Spoke для 3+ филиалов — Full Mesh выглядит симметрично на бумаге, но когда что-то ломается, диагностировать паутину из соединений репликации — то ещё удовольствие
• Sizing staging — маленький staging это причина номер один, почему репликация ползёт как черепаха. Не экономьте на этом
• Bandwidth throttling обязателен — без ограничений DFSR спокойно съест весь канал. Остальные сервисы это не оценят
• Организационные правила — договоритесь на берегу: кто и на каком сервере редактирует критические файлы. Техника конфликты разрулит, но нервы потреплет
• Мониторьте backlog — если он начал расти и не падает, это первый звонок: что-то не так с каналом или дисками

После того как DFS заработал в штатном режиме, РосЛогистик утвердил дорожную карту на следующий год:

• Q2 2026 — включить ABE (Access-Based Enumeration), чтобы пользователи не видели папки, к которым у них нет доступа
• Q3 2026 — интеграция с SharePoint Online для совместного редактирования документов Office в реальном времени
• Q4 2026 — присмотреться к Azure File Sync как дополнению к DFSR: облачный бэкап и tiering для редко используемых файлов