Короткий ответ

Сначала измерьте backlog между членами группы: dfsrdiag backlog (или Get-DfsrBacklog). Пока очередь живая и уменьшается — не делайте authoritative. Ищите диск, квоту staging (Event 4202), сеть RPC, остановленную DFSR, журнал 2213 после dirty shutdown. Не чистите ConflictAndDeleted и не копируйте дерево руками поверх replicating folder «чтобы догнать».

SYSVOL — тот же движок, но другая процедура и риски GPO: SYSVOL. Данные пользовательских RG не лечат D4/D2 «как в статье FRS».

Симптомы и как отличить

  • На \\FS01\data файл есть, на \\FS02\data нет спустя часы.
  • Пользователи DFS Hop между сайтами видят разные версии.
  • Namespace жив, реферал ок — не путать с недоступным корнем.
НаблюдениеНе DFSR backlog
Корень \\contoso.example\public не открываетсяnamespace
Один том 0 байтдиск
NTDS партнёры красныерепликация AD, но DFSR от AD зависит для конфигурации

Возможные причины

  1. Нет RPC/445 между членами, DFSR Stopped.
  2. Staging quota меньше пика изменений (4202/4204).
  3. Огромный первоначальный sync без preseeding.
  4. Event 2213: служба ждёт решения после нештатного выключения.
  5. Disk full / NTFS dirty на одном члене.
  6. Bandwidth throttling в расписании RG (ночь vs день).
  7. Файл открыт эксклюзивно, не реплицируется, пока не закрыт.
  8. Кто-то удалил replicated folder на одном узле.

Диагностика

Подставьте свои RG/RF/имена из оснастки DFS Management (не копируйте SYSVOL RG на данные).

Get-Service DFSR | Format-Table Name, Status
Get-DfsReplicationGroup | Format-Table GroupName, State
Get-DfsReplicatedFolder | Format-Table GroupName, FolderName, DomainName
Get-DfsrMembership | Format-Table GroupName, ComputerName, ContentPath, StagingPath, StagingQuotaInMB, Enabled

Backlog FS01 → FS02:

dfsrdiag backlog /rgname:"RG-Data" /rfname:"Data" /smem:FS01 /rmem:FS02
Get-DfsrBacklog -GroupName 'RG-Data' -FolderName 'Data' -SourceComputerName 'FS01' -DestinationComputerName 'FS02' -ErrorAction SilentlyContinue

Если backlog сотни тысяч и растёт — не «подождём ещё час без диска».

Журнал:

Get-WinEvent -ComputerName FS01 -LogName 'DFS Replication' -MaxEvents 40 |
  Format-Table TimeCreated, Id, Message -Wrap

2213 — ожидание AD/инициации; 4202 — staging; 4412 — конфликт, копия ушла в ConflictAndDeleted.

Диск:

Get-Volume | Format-Table DriveLetter, FileSystemLabel, SizeRemaining

Решение

Сценарий A. Служба и сеть

Start-Service DFSR
Test-NetConnection FS02.contoso.example -Port 135

DFSR использует RPC; фильтр между сайтами часто «забывают» после SMB 445, который для данных тоже нужен.

Сценарий B. Staging

Увеличьте StagingQuotaInMB в членстве до пикового размера одновременных файлов, не «1 ГБ на терабайт данных наугад». Меняйте через DFS Management / Set-DfsrMembership. Дождитесь снижения 4202, не режьте staging файлы в Explorer.

Сценарий C. 2213 на члене данных

Читайте текст события: DFSR может ждать, пока администратор не подтвердит, что БД можно использовать. Следуйте текущей документации Microsoft для data DFSR (это не автоматически D4 SYSVOL). Не запускайте authoritative на обоих концах.

Сценарий D. Первичный sync

Preseed robocopy /copyall /dcopy:DAT /r:1 /w:1 до добавления члена, как в гайде Microsoft. Не зеркальте копированием во время активного DFSR.

Сценарий E. Конфликты

Смотрите ConflictAndDeleted. Восстанавливайте нужные файлы копированием наружу. Не dfsrdiag purge конфликтов, пока не знаете, что там единственные копии.

Сценарий F. Как отличить «догоняет» от «встал»

Снимите backlog дважды с интервалом 10–15 минут. Если число падает — не трогайте authoritative. Если растёт или dfsrdiag не отвечает — диск, RPC, DFSR Stopped, 2213.

dfsrdiag backlog /rgname:"RG-Data" /rfname:"Data" /smem:FS01 /rmem:FS02
Get-DfsrMembership -GroupName 'RG-Data' -ComputerName FS01 |
  Format-List ComputerName, ContentPath, StagingPath, StagingQuotaInMB, Enabled, State
Get-WinEvent -ComputerName FS01 -LogName 'DFS Replication' -MaxEvents 20 |
  Where-Object { $_.Id -in 2213,4202,4412,5002 } |
  Format-Table TimeCreated, Id, Message -Wrap

4202: увеличьте staging quota, дождитесь, пока DFSR переварит крупные файлы. Ручное удаление файлов из staging ломает состояние. Content том 0 байт — сначала диск.

Расписание RG с «0 Мбит днём» выглядит как вечная отсталость офиса B. Проверьте bandwidth/schedule в группе, не только backlog.

Preseed нового члена: robocopy до включения membership, затем enable. Включение пустого диска против терабайта на WAN без seed — дни backlog и тикеты «DFS сломался».

Не путайте с SYSVOL: для Domain System Volume процедура 2213/D2 описана в статье SYSVOL. На RG-Data не копируйте те шаги слепо.

Как проверить, что проблема устранена

dfsrdiag backlog /rgname:"RG-Data" /rfname:"Data" /smem:FS01 /rmem:FS02
dfsrdiag backlog /rgname:"RG-Data" /rfname:"Data" /smem:FS02 /rmem:FS01

Очередь стремится к нулю в обоих направлениях (или к вашему нормальному фону). Создайте тестовый файл на FS01, через разумное время он на FS02. Event 4202 нет. Пользователь сайта B видит ту же версию.

Если не помогло

  • Backlog не считается: неверные RG/RF/имена, член Disabled.
  • Только большие файлы: квота staging и RDC.
  • Один каталог: ACL/открытый handle.
  • После снимка VM члена — риск базы DFSR; не лечите снимками DC/DFSR как backup.

Сверьте ContentPath на обоих членах: разные буквы дисков после переноса VM ломают membership. Не копируйте SYSVOL D2/D4 на RG-Data. Если 2213 висит сутками, читайте KB Microsoft по событию для data DFSR, не форумный скрипт «нажать F». Пользователи, пишущие в оба конца одного файла, будут плодить 4412 даже при нулевом backlog.

Профилактика

  • Мониторинг backlog и свободного места staging/content.
  • Расписание: не душить WAN до нуля в рабочее время без SLO.
  • Два члена не на одном диске без запаса.
  • Не смешивать SYSVOL RG и данные в одной голове при аварии.
  • Backup файлов и понимание, что DFSR не backup.

FAQ

Можно ли ускорить, скопировав файлы руками на FS02?

Пока DFSR жив, вы плодите конфликты. Preseed — только на новом члене до включения membership.

Backlog 50 файлов — авария?

Нет, это нормальный хвост. Авария — рост часами/днями или 2213.

Чем DFSR отличается от репликации AD?

AD — база каталога. DFSR — файлы. Зелёный repadmin не значит, что Data RG догнал.

Нужно ли останавливать пользователей?

Если делаете authoritative или rebuild базы — да, иначе пишут в расходящиеся копии.

Event 4412 каждый день.

Два пользователя правят один файл на двух концах. Это коллизия, не «сломан DFSR». Учите ходить в свой сайт / блокировки приложений.