9 листопада 2026 р.

DFS та реплікація файлів

Distributed File System у Windows Server об’єднує файлові ресурси кількох серверів під одним логічним шляхом і, за потреби, синхронізує їхній вміст. Користувачі працюють, наприклад, з адресою \\contoso.local\Files\Departments, не прив’язуючись до конкретного сервера FS01 або FS02. Якщо один вузол тимчасово недоступний, клієнт може отримати інше доступне призначення папки.

DFS складається з двох окремих компонентів. DFS Namespace створює єдиний простір імен, а DFS Replication, або DFSR, передає зміни між серверами. Їх можна використовувати незалежно, але для відмовостійкого файлового контуру зазвичай потрібні обидва компоненти.

Нижче розглянуто практичну конфігурацію для домену contoso.local і двох серверів Windows Server — FS01 та FS02. На кожному вузлі розміщуватиметься локальна папка D:\Data\Departments, а користувачі відкриватимуть її через доменний шлях \\contoso.local\Files\Departments.

Архітектура DFS Namespace і DFS Replication

DFS Namespace не зберігає файли самостійно. Він публікує логічні папки та повертає клієнтам список реальних SMB-призначень. Для папки Departments такими призначеннями можуть бути:

- \\FS01\Departments$; - \\FS02\Departments$.

Клієнт отримує referral — направлення до одного з доступних серверів. Вибір залежить від стану призначень і топології сайтів Active Directory. Якщо сервери розміщені в різних офісах, коректно налаштовані AD Sites and Services допомагають спрямовувати користувачів до найближчого вузла, а не через повільний WAN-канал.

DFSR працює окремо від механізму referrals. Служба відстежує зміни через журнал NTFS USN, передає оновлені блоки та підтримує узгоджені копії даних на учасниках групи реплікації. Технологія Remote Differential Compression може зменшувати обсяг передавання для змінених частин великих файлів, хоча реальний результат залежить від типу даних.

Важливо розуміти обмеження: DFSR не є кластерною файловою системою та не забезпечує спільне блокування одного документа на різних серверах. Якщо два користувачі одночасно змінять той самий файл через різні вузли, одна з версій може потрапити до каталогу конфліктів. Для баз даних, активних віртуальних дисків, PST-файлів та інших постійно відкритих контейнерів DFSR не підходить.

Під час проєктування файлового середовища корисно спочатку визначити вимоги до доступності, резервного копіювання та прав. Такі роботи зазвичай входять до комплексного системного адміністрування, оскільки DFS залежить не лише від файлових серверів, а й від DNS, Active Directory, мережі та моніторингу.

Підготовка серверів і файлових ресурсів

Обидва сервери мають бути введені в домен, використовувати доменні DNS-сервери та мати стабільну мережеву взаємодію. Перед налаштуванням перевірте синхронізацію часу, розпізнавання імен FS01 і FS02, доступність TCP-портів SMB і RPC, а також стан реплікації Active Directory.

Якщо доменна інфраструктура ще не підготовлена, спочатку виконайте створення нового домену Active Directory, а вже потім розгортайте доменний простір DFS.

На FS01 і FS02 встановіть потрібні компоненти:

powershell

Install-WindowsFeature FS-DFS-Namespace, FS-DFS-Replication, RSAT-DFS-Mgmt-Con -IncludeManagementTools

Перевірте результат:

powershell

Get-WindowsFeature FS-DFS-Namespace, FS-DFS-Replication, RSAT-DFS-Mgmt-Con
Get-Service DFSR

Створіть локальні каталоги на обох серверах:

powershell

New-Item -Path "D:\Data\Departments" -ItemType Directory -Force

Далі опублікуйте приховані SMB-ресурси. Команди потрібно виконати окремо на FS01 і FS02:

powershell

New-SmbShare `
  -Name "Departments$" `
  -Path "D:\Data\Departments" `
  -FullAccess "CONTOSO\Domain Admins" `
  -ChangeAccess "CONTOSO\File-Departments-RW" `
  -ReadAccess "CONTOSO\File-Departments-RO"

Назви домену та груп замініть на актуальні. Не надавайте широкі дозволи Everyone: Full Control без обґрунтованої потреби. Практичний підхід полягає в тому, щоб залишити дозволи спільного ресурсу відносно простими, а детальне розмежування виконувати через NTFS-групи доступу.

Для однакової роботи після перемикання між вузлами NTFS ACL мають збігатися на обох серверах. Перед першою синхронізацією перевірте власника каталогів, успадкування та групи доступу:

powershell

Get-Acl "D:\Data\Departments" | Format-List
Get-SmbShareAccess -Name "Departments$"

Розміщуйте дані на томі NTFS. Не використовуйте для реплікованої папки FAT, ReFS у непідтримуваному сценарії, змонтований мережевий ресурс або каталог усередині іншої реплікованої папки. Також заздалегідь оцініть вільне місце для staging і conflict-and-deleted каталогів.

Створення доменного простору імен

Для відмовостійкої конфігурації використаємо доменний простір імен типу DomainV2. Спочатку на FS01 створіть окремий каталог і SMB-ресурс для кореня namespace:

powershell

New-Item -Path "D:\DFSRoots\Files" -ItemType Directory -Force
New-SmbShare `
  -Name "FilesRoot" `
  -Path "D:\DFSRoots\Files" `
  -FullAccess "CONTOSO\Domain Admins" `
  -ReadAccess "CONTOSO\Domain Users"

Створіть корінь DFS:

powershell

New-DfsnRoot `
  -Path "\\contoso.local\Files" `
  -TargetPath "\\FS01\FilesRoot" `
  -Type DomainV2

Щоб сам namespace не залежав від FS01, підготуйте такий самий кореневий ресурс на FS02, після чого додайте другий root target:

powershell

New-DfsnRootTarget `
  -Path "\\contoso.local\Files" `
  -TargetPath "\\FS02\FilesRoot"

Тепер створіть логічну папку Departments і додайте обидва файлові призначення:

powershell

New-DfsnFolder `
  -Path "\\contoso.local\Files\Departments" `
  -TargetPath "\\FS01\Departments$"

New-DfsnFolderTarget `
  -Path "\\contoso.local\Files\Departments" `
  -TargetPath "\\FS02\Departments$"

Перевірте конфігурацію:

powershell

Get-DfsnRoot -Path "\\contoso.local\Files"
Get-DfsnRootTarget -Path "\\contoso.local\Files"
Get-DfsnFolderTarget -Path "\\contoso.local\Files\Departments"

На цьому етапі користувач уже може відкривати логічний шлях, але файли між FS01 та FS02 ще не синхронізуються. Наявність двох folder targets без DFSR створює ризик отримати два незалежні набори даних. Тому не відкривайте ресурс для звичайної роботи, доки початкова реплікація не завершиться.

Налаштування групи DFS Replication

Створіть групу реплікації та репліковану папку з адміністративної PowerShell-сесії, яка має права на зміну конфігурації DFS:

powershell

New-DfsReplicationGroup -GroupName "RG-Departments"
New-DfsReplicatedFolder `
  -GroupName "RG-Departments" `
  -FolderName "Departments"

Додайте обидва сервери:

powershell

Add-DfsrMember -GroupName "RG-Departments" -ComputerName "FS01"
Add-DfsrMember -GroupName "RG-Departments" -ComputerName "FS02"

Створіть двосторонні з’єднання. Параметр -CreateFullMesh особливо зручний для невеликої групи з двох або трьох вузлів:

powershell

Add-DfsrConnection `
  -GroupName "RG-Departments" `
  -SourceComputerName "FS01" `
  -DestinationComputerName "FS02" `
  -CreateFullMesh

Призначте локальні шляхи та визначте FS01 первинним учасником для початкової синхронізації:

powershell

Set-DfsrMembership `
  -GroupName "RG-Departments" `
  -FolderName "Departments" `
  -ContentPath "D:\Data\Departments" `
  -ComputerName "FS01" `
  -PrimaryMember $true `
  -Force

Set-DfsrMembership `
  -GroupName "RG-Departments" `
  -FolderName "Departments" `
  -ContentPath "D:\Data\Departments" `
  -ComputerName "FS02" `
  -Force

Первинний учасник має значення лише під час першої ініціалізації. Після переходу групи у нормальний стан обидва вузли стають рівноправними учасниками реплікації.

Прискорте отримання конфігурації з Active Directory:

powershell

Update-DfsrConfigurationFromAD -ComputerName "FS01" -Verbose
Update-DfsrConfigurationFromAD -ComputerName "FS02" -Verbose

Створіть на FS01 тестовий файл і не змінюйте дані на FS02 до завершення initial sync:

powershell

Set-Content `
  -Path "D:\Data\Departments\dfsr-test.txt" `
  -Value "DFS replication test"

Перевірте backlog між учасниками:

powershell

Get-DfsrBacklog `
  -GroupName "RG-Departments" `
  -FolderName "Departments" `
  -SourceComputerName "FS01" `
  -DestinationComputerName "FS02" `
  -Verbose

Додатково сформуйте діагностичний звіт:

powershell

dfsrdiag ReplicationState
dfsrdiag Backlog /RGName:RG-Departments /RFName:Departments /SMem:FS01 /RMem:FS02

Для регулярної підтримки DFS потрібні контроль журналу подій, місткості томів, backlog і стану служби. Ці завдання варто включити до стандартного процесу адміністрування серверів Windows і Linux, а не перевіряти лише після звернень користувачів.

Типові помилки

Використання DFSR як резервної копії. Реплікація переносить не тільки корисні зміни, а й випадкове видалення, пошкодження або шифрування файлів. Для відновлення потрібна окрема система резервного копіювання з історією версій та копією поза основним контуром.

Одночасне заповнення обох серверів різними файлами. Перед початковою синхронізацією визначте авторитетний набір даних і первинного учасника. Не дозволяйте користувачам редагувати вміст на другому вузлі, поки DFSR не завершить ініціалізацію.

Публікація namespace до запуску реплікації. Два folder targets можуть бути доступними, хоча їхній вміст ще відрізняється. Спочатку перевірте backlog, події DFS Replication і наявність контрольних файлів на обох серверах.

Ігнорування журналу подій. Основні повідомлення DFSR розташовані в Applications and Services Logs → DFS Replication. Події про зупинену реплікацію, нестачу місця, dirty shutdown або відсутність зв’язку з контролером домену не можна залишати без аналізу.

Неправильний розмір staging. Під час передавання великих файлів служба використовує прихований каталог DfsrPrivate. Замалий staging quota спричиняє постійне очищення та повторну підготовку файлів, що знижує швидкість синхронізації. Розмір потрібно підбирати з урахуванням найбільших файлів і частоти змін.

Реплікація непідтримуваних навантажень. Не розміщуйте в DFSR активні бази даних, файли віртуальних машин, профілі з постійно відкритими контейнерами чи програмні сховища, які очікують синхронного блокування. DFSR орієнтований передусім на звичайні файлові документи та дистрибутиви.

Відсутність перевірки реального перемикання. Після завершення синхронізації тимчасово вимкніть folder target FS01 через DFS Management або PowerShell і переконайтеся, що шлях \\contoso.local\Files\Departments продовжує відкриватися через FS02. Після тесту поверніть призначення в активний стан і повторно перевірте backlog.

Висновок

Зв’язка DFS Namespace і DFS Replication дає користувачам стабільний доменний шлях до файлів та підтримує узгоджені копії даних на кількох Windows-серверах. Надійна конфігурація потребує двох namespace targets, щонайменше двох folder targets, правильної групи DFSR, однакових дозволів і завершеної початкової синхронізації.

Після запуску систему потрібно контролювати так само регулярно, як інші критичні служби: перевіряти backlog, журнал DFS Replication, вільне місце, доступність SMB, стан Active Directory та фактичне перемикання між вузлами. DFS підвищує доступність файлових ресурсів, але не замінює резервне копіювання, керування версіями та план відновлення після пошкодження даних.