Distributed File System Replication.
В энтерпрайзах (с) удобнейшая вещь, но если вылезло в процессе ее работы "нечто", с этим приходится разбираться долго и упорно. Пересоздание группы репликации, конечно, универсальный выход, в случае чего, но как представишь, что потом по WAN каналам отдавать или принимать десяток гигов, становится тошно. А если этот самый канал еще и не очень стабилен...
Сейчас же ситуация немного другая. Казалось бы, два сервера в одной "полке" (две виртуалки), канал между ними идеален. Но и задачка - под стать этому каналу, реплицировать ни много ни мало половину терабайта. Залили этот каталог на один из серверов и забыли о нем, пусть служба dfsr сама его как хочет, так и жрет.
Она и жрала. Долго, упорно. И вроде как сожрала.
Настало время от этого каталога избавиться. Он временный, а половина терабайта все же нужна. Окей, получили все необходимые разрешения, подписи/печати/визы и нажали заветное Shift+Del, Enter. А потом началось любопытное.
В логе SCOM начали появляться сообщения об ошибках вида "У вас снова нехватает пространства под DFSR-stage каталог". И идут эти сообщения с того сервера, где огромная папка уже удалена. ЧТо за черт. Лезу на сервер, смотрю на диск, где это папка была... и вижу ее на старом месте. Внутрь зайти не могу, у меня на нее прав нет. Но вижу в логах, что в эту папку снова ломятся файлы со второго сервера, где они, по идее, должны вот прямо сейчас удаляться, так как согласно реплике, последнее изменение было именно удалением. Однако ж, это не так.
Эскалировал проблему туда, где с ней будут разбираться, и начал размышлять, как такое вообще может произойти. В процессе размышления поднял свой ручной домен, загнал туда пару файловых серверов под Windows 2012 R2, настроил DFSR... Как я только над ней не издевался, так и не смог получить восстановление файлов.
ОК, идем дальше, в том же домене поднимаем еще пару серверов, но уже под Windows 2008 R2 (боевые именно под ней крутятся). Настраиваю там отдельную группу репликации, в наглую загоняю в DFSR-папку копию каталога C:\windows (чтоб хоть как-то службу dfsr загрузить работой) и наблюдаю. Где-то через минуту после окончания копирования папки винды в папку DFSR на сервере-партнере дерево каталогов уже оформилось. Думаю, ага, должно быть, файлы она тоже перелила. ОК, удаляем папку DFSR\Windows на сервере-партнере. Удалилась, а через пару секунд появилась снова и начала набиваться каталогами и файлами. Что за... подождал пару минут, грохнул папку еще раз. После этого она удалилалсь без следов. И на primary-сервере тоже ушла.
Нет, так не пойдет. Почему папка восстанавливалась? А что если...
Останавливаем службу dfsr на обоих серверах, вычищаем каталог DFSR, запускаем службу. У нас чистая среда. Снова копируем в DFSR папку C:\windows. Скопировалась. А теперь в командной строке даем следующее:
DFSRDIAG BACKLOG /sendingmember:fs3 /receivingmember:fs4 /rgname:dfs2008 /rfname:dfs2008
Получаем прекрасное: в очереди на репликацию где-то около 15 тыщ файлов. Переходим на сервер-партнер, убеждаемся, что дерево каталогов уже готово. И снова удаляем папку Windows из каталога DFSR на этом сервере. Папка, как и предполагалась, сначала удалилалсь, а потом восстала аки феникс. И начала набиваться файликами. А файлики как раз те, что были показаны в бэклоге командой выше. Вот теперь все ясно.
Жрала-жрала служба dfsr ту гигантскую папку, и вроде как прожевала, да видно, какая-то злобная мышь с тех пор успела там поменять кучу файлов. Большую кучу, на несколько гигов. И вот именно эти изменения до сих пор были в очереди репликации с сервера 2 на сервер 1. И они-то как раз и набивались в постоянно восстанавливающуюся папку на диске 1, снова забивая собой место.
Впоследствие мне рассказали, как в итоге избавились от этой мега-папки. Так же, как и я вычищал свое тестовое окружение: остановили службу репликации, вытерли каталог на обоих серверах, включили службу репликации. Грубо, но действенно.