У меня есть сервер под управлением Windows Server 2008 R2 с (родным для Windows) программным массивом raid-5. Массив состоит из 7 дисков Western Digital RE3 и RE4 емкостью 1 ТБ. У меня есть автономные резервные копии этого массива.
Проблема в следующем: несколько дней назад после копирования большого файла на диск я заметил, что с этим файлом возникла проблема с целостностью - это был файл размером ~ 12 ГБ, который я загрузил через uTorrent. Переместив его в массив raid, я использовал uTorrent, чтобы переместить место загрузки, и выполнил повторную проверку, чтобы я мог засеять его из этого места. Повторная проверка показала, что только 6308/6310 фрагментов скопированного файла остались нетронутыми.
Следующим моим шагом было написать быстрый сценарий PowerShell, который копировал бы файлы в массив, выполняя хеш-код SHA1 исходного и результирующего файлов и сравнивая их. Файлы меньшего размера (100-1000 МБ) копируются нормально. Когда я начал копировать большие данные (~ 15 ГБ), я обнаружил, что проверка хэша не удалась примерно в 2/3 случаев. У поврежденных файлов были очень и очень маленькие несоответствия - менее 0,01% (РЕДАКТИРОВАТЬ - более поздние эксперименты показали, что поврежденные фрагменты данных всегда имеют длину 60 байт, причем на каждые 15 ГБ скопированного файла обычно проявляется от одного до трех. Поврежденные данные появляются случайным образом , без последовательного набора перевернутых битов). Я также исключил возможность проблем с сетью или клиентов, поместив этот большой файл в папку C: \ сервера и многократно копируя его оттуда в массив, получая аналогичные результаты.
Копирование данных через проводник, PowerShell или стандартную командную строку Windows дает те же результаты. Ни одна из копий не выходит из строя и не сообщает о каких-либо проблемах. Сам массив raid указан как работоспособный в управлении дисками.
После нескольких экспериментов я выключил сервер и на ночь запустил memtest. Ошибок не обнаружено. Базовый запуск chkdsk не выявил проблем, но я не использовал флаг / R, так как не был уверен, как это может повлиять на программный том raid-5.
Затем я запустил Crystal Disk Info, чтобы проверить интеллектуальные данные на дисках, но обнаружил, что CDI обнаружил только 5 из 7 дисков в массиве. Понятия не имею почему. Тем не менее, CDI показывает следующие флажки «предостережения» на одном из дисководов:
05 199 199 140 000000000001 Reallocated Sectors Count
C5 200 200 __0 000000000001 Current Pending Sector Count
Это немного настораживает, но я действительно не знаю, что мне делать с этой информацией. Я не думаю, что причиной этого мог быть один перераспределенный сектор.
На этом этапе я ищу совета, что делать дальше. Мне нужно определить причину этой проблемы, но я не решаюсь запускать chkdsk / R или какие-либо средства проверки работоспособности загрузочного диска, потому что я боюсь, что они могут сломать массив. Я подумал о том, чтобы запустить повторную синхронизацию массива, но на самом деле я не уверен, как это сделать, не делая чего-то глупого, например, вручную отбрасывая диск, а затем восстанавливая его.
Буду очень признателен за любой совет, который мог бы помочь мне выяснить точную причину этой проблемы.
Поскольку ни одна из выполняемых вами операций не завершается неудачно, выполняется chkdsk /R вероятно, не принесет никаких результатов - chkdsk не сможет восстановить что-либо, что не определено как поврежденное.
Повреждения данных, подобные тем, которые вы наблюдаете, могут иметь несколько возможных источников:
Вам следует выбрать методический подход, чтобы исключить те, которые вы можете исключить:
Число 4 - биты переворачивания при чтении - должно быть довольно легко распознать по тому факту, что перевороты будут происходить для разных областей данных, поэтому хэши md5 или sha1 будут время от времени отличаться, вы пытаетесь вычислить их для большого файла.
Номер 3 - перевороты на магнитных носителях - маловероятно, что они останутся незамеченными, поскольку каждый жесткий диск содержит алгоритмы упреждающего исправления ошибок, а также контрольные суммы обнаружения ошибок, и вы определенно будете видеть неисправимые ошибки чтения сектора на несколько порядков чаще, чем скольжение битов. сквозной - достаточно взглянуть на невосстановимые ошибки чтения SMART, чтобы исключить эту
Номер 2 - его довольно сложно обнаружить. Хотя протокол SATA защищает передаваемые данные с помощью алгоритмов исправления ошибок, где применяется логика 3. случая и замедляет любую передачу в обход, прежде чем пропустить перевернутый битовый сектор, повреждение может произойти где-то еще и остаться незамеченным - в буферах для пример.
Номер 1 - я считаю это наиболее вероятным случаем. Либо ошибка в реализации, либо (что более вероятно, поскольку ошибка такого значения, вероятно, будет отмечена и задокументирована где-то еще через 4 года после выпуска ОС) аппаратный сбой, такой как неисправная RAM, может вызвать такого рода перевороты битов. Сделайте пару проходов memtest, чтобы исключить ОЗУ, особенно если вы не используете память ECC. Повторно запустите тесты в аналогичной среде с той же конфигурацией программного обеспечения (желательно с образом вашей системы), чтобы исключить программную причину.
Вы также можете расширить свои тесты на копирование файлов меньшего размера на 15 ГБ, чтобы увидеть, повлияет ли повреждение на один из них после записи определенного количества данных. Если это было так (что, вероятно, с учетом вашего описания), вы должны предположить, что аналогичное повреждение произошло с данными, уже размещенными на ваших дисках - попробуйте сравнить с исходными данными или заведомо надежными криптографическими хэшами с файлами большего размера, чтобы оценить степень повреждения. .
Кроме того, было бы неплохо выполнить повторный расчет контрольных сумм XOR и сравнить их с данными четности, хранящимися на дисках, и большинство систем RAID 5 предлагают эту функцию, которая обычно называется «очисткой». В Windows, похоже, нет возможности сделать это из коробки. Мне удалось найти только службы восстановления данных, делающие это за вас.
Удачной охоты.
chkdsk (без / R) будет первым, что вы запустите. Если есть проблема, запустите chkdsk / R. Возможно, у вас проблема с контроллером диска, а не с дисками. Если chkdsk каждый раз при запуске сообщает, что разные блоки повреждены (без / R), значит, проблема с контроллером, а не с диском.