Расскажу об одной интересной печальной истории, кому-то, возможно, поучительной, повлекших потерю данных dataloss при использовании двусторонней репликации DFSR и использованием теневых копий (Shadow Copy) файловой системы вместо полноценного резервного копирования.

Предистория:

Было у заказчика две площадки с настроенной двусторонней репликацией DFSR файлового сервиса (объем данных, к слову, около 10 ТБ). Вторая площадка была как бы резервной и мало кто из пользователей подключался к DFS шаре на неё. В качестве резервного копирования заказчик использовал теневые снимки файловой системы (Volume shadow Copie).
Как и положено в лучших традициях печальных историй, события операционной системы никто не смотрел и деятельность по проактивной диагностики не проводилась.

Описание проблемы

В один пятничный день у заказчика появилась проблема "массового случайного пропадания файлов на файловом сервисе".
Загрузка дискового ввода-вывода систем была 100%, процесс - DFSR.
В EventLogs - в глаза попалась volsnap 25
 

volsnap	25	Ошибка	Теневые копии тома D: удалены из-за невозможности увеличения хранилища теневых копий.  Уменьшите загрузку ввода-вывода для системы или выберите другой том для  хранилища теневых копий, который не подлежит теневому копированию.

Так же множественные события

DFSR    4304    Предупреждение    "Службе репликации DFS несколько раз подряд не удалось реплицировать файл из-за постоянных нарушений общего доступа к файлу. Службе не удалось подготовить файл к репликации из-за нарушения общего доступа. "

Если Вы читаете эту статью найдя её по ошибке volsnap 25 в надежде получения решения по восстановлению утерянных Вами теневых копий, - смиритесь и забудьте: ввиду принципов работы NTFS теневые копии утеряны безвозвратно!

Действия:

• Первым делом мы остановили репликацию: сначала убив процесс, после остановив репликацию. 
• Установили права только на чтение на уровне сетевой шары в менее поврежденный и содержащий более старые копии данных (репликация не завершалась успешно последние два с половиной месяца) узел файловой шары на второй площадке. Туда направили пользователей и продолжили разбираться с проблемой вместе с заказчиком.
• Произвели Checkdisk, на предмет устранения ошибок файловой системы.
• Нагрузка спала и мы заглянули в файл конфликтов и свойства DFS, размер для конфликтов был равен по умолчанию всего четырём гигабайтам (на 10 ТБ данных), в итоге средствами Restore-DfsrPreservedFiles восстановили 3209 крайних файла, перемещенных DFSR как конфликтные в соответствующий каталог.

Описание

Из текста выше уважаемый читатель уже понял, что у нашего уважаемого заказчика случился dataloss.

На продуктивной системе файлового сервера возникали незначительные ошибки файловой системы, которые не отражались на производительности или стабильности работы файлового сервиса

С течением времени количество ошибок увеличивалось,и к моменту X достигло большого количества.   Клиенты автоматически переключились на вторую площадку, где абсолютно прозрачно продолжили работу, а репликация со стороны площадки 1 продолжилась. Поврежденная файловая система препятствовала репликации рабочих файлов обратно в копию на основной площадке.Конечный объект папки на второй площадке была помечен как недоступный, автоматически получил меньший приоритет по сравнению с копией в офисе. Клиенты переключились на копию на первую площадку, обнаружили проблему
Одновременно сервер на второй площадке начал синхронизировать повреждения с копией на первой площадке, при этом файлы, отсутствующие в копии первой площадки, оказались мгновенно удалены и на второй площадке.
В этот момент система репликации данных DFSR активно реплицировала поврежденные объекты файловой системы на вторую площадку и обратно, тем самым предельно увеличив нагрузку на систему ввода вывода и породила циклическую перезапись файлов между площадками. Увеличенная нагрузка и проблемы на уровне файловой системы привели к неработоспособности существующих резервных копий данных файлового сервиса осуществляющихся средствами механизма теневых копий.
Таким образом ошибки на файловой системе увеличивались в следствии работы механизма репликации испорченных данных. Причина инцидента и проблемы - технический сбой на файловой системе и разрушительные последствия работы механизма репликации DFSR с испорченными объектами файловой системы.

Говоря короче:
Случился corrupt file system и DFSR в конфигурации двусторонней репликации начала циклически перезаписывать файлы на файловой системе на обоих узлах с учетом отсутствия консистентной копии данных на каждом из узлов.

Контрмеры или что нужно чтобы так не случилось у Вас

• Во первых любая технология требует перед внедрением качественного проработанного подхода к её реализации. DFS и DFSR нужно использовать с умом. В частности обратить внимание на необходимую топологию репликации (избегая по возможности двусторонней репликации), а так же на параметры "Квота на папку конфликтов и удалений" и "Промежуточное хранение". В случае с холодным резервом (односторонняя репликация), если возникнут продолжительные неполадки на узле с основной копией данных (доступной на чтение и запись) нужно предусмотреть сценарий(план действий) для ИТ-оператора включающий:
  1. разрешение на запись на резервном узле
  2. запрет на запись на основном узле
  3. переключить репликацию в обратную сторону
  4. не разрешать запись на основном узле пока репликация не завершится
• По поводу volsnap 25, microsoft приводит полезную рекомендацию, актуальную еще со времен 2003 виндовс:

• If the file system's cluster size is 16 KB or larger, the provider can recognize disk defragmentation I/O and handle it correctly. Microsoft recommends that you use a 16-KB or larger cluster allocation unit size when you format the volume if you plan to defragment volumes that are used for shadow copies of shared folders.
  

• Нужно помнить основные принципы в построении резервного копирования, в частности, держать резервные копии на тех же самых носителях информации, а тем более файловых системах, не есть хорошая идея. Выполнять дополнительно резервное копирование данных на регулярной основе иным чем средством резервного копирования восстановления на иную систему хранения данных.
• Превентивно производить плановые операции проверки состояния файловой системы (Checkdisk) на файловом сервисе
• Превентивно производить проактивный мониторинг событий и проверку наличия теневых резервных копий.