Комментарии 42
Не затруднит ли автора статьи пояснить, каков механизм изменения reallocated sector count в этом случае и как он связан с обновлением ПО (очевидно, не HDD, а некоего системного драйвера)?
Я в восстановлении данных не силён, поэтому и прошу комментариев от специалистов. Возможно, это не верное предположение. До инцидента состоянием S.M.A.R.T. не интересовался, не исключено, что проблема уже была, но не припомню момента, когда бы ещё могло быть переназначено столько секторов.
reallocated sector count показывает количество успешно переназначенных секторов.
В данном случае этот счетчик показывает две вещи
1. Данные не были потеряны, они были перенесены из плохих секторов, в хорошие
2. На диске есть плохие сектора
Отсюда следуют логические выводы
1. Так как на диске есть плохие сектора, то стоит посмотреть на динамику роста их количества. Если количество плохих секторов быстро растет, то диск стоит заменить
2. Механизм reallocated sector count подразумевает рост только, когда плохой сектор был все же прочитан (после нескольких повторов) и переписан в другое место. Соответственно если плохой сектор есть, но не был успешно прочитан, то он не будет отражен в этом атрибуте.
3. Плохих секторов может быть больше, чем показывает reallocated sector count. Эти сектора могут бы еще не отмечены диском, либо показаны в других атрибутах. Например в Current Pending Sector Count и Reported Uncorrectable Errors
В данном случае этот счетчик показывает две вещи
1. Данные не были потеряны, они были перенесены из плохих секторов, в хорошие
2. На диске есть плохие сектора
Отсюда следуют логические выводы
1. Так как на диске есть плохие сектора, то стоит посмотреть на динамику роста их количества. Если количество плохих секторов быстро растет, то диск стоит заменить
2. Механизм reallocated sector count подразумевает рост только, когда плохой сектор был все же прочитан (после нескольких повторов) и переписан в другое место. Соответственно если плохой сектор есть, но не был успешно прочитан, то он не будет отражен в этом атрибуте.
3. Плохих секторов может быть больше, чем показывает reallocated sector count. Эти сектора могут бы еще не отмечены диском, либо показаны в других атрибутах. Например в Current Pending Sector Count и Reported Uncorrectable Errors
У вас просто сдох диск, с ПО не связано. Для сигейта нормально забивать перед смертью релокейт лист. Да и вообще наличие хоть одного релокейта конкретно на сигейте говорит о скорой кончине.
Спасибо, буду менять диск.
У меня в компе стоит сигейтовский HDD, за 67000 часов (~8 лет) накопилось 144 ремапа, диск вполне здравствует. А до этого был пятисотгиговый сигейт, который я сразу после покупки уронил на асфальт, после ремапа там было около 400 переназначенных секторов, и он тоже отработал несколько лет.
Тогда подожду пока, понаблюдаю.
Добрый день, вы можете запустить MHDD в режиме ремапа, по тесту поверхности будет понятно, поживёт ли диск, или уже всё, так как в вашем случае повреждения файловой системы — это плохой признак.
Не уверен, что поможет. Буду ждать первого сбоя. Там SeaTools опять попробую исправить. А вообще, склоняюсь к замене HDD в ближайшее время (уж очень много секторов переназначено). Пока был Acronis True Image 2019, еженедельно запускал chkdsk с параметром /r. Количество проблемных секторов не увеличивалось. Данные не должны потеряться. Каждый день делаю бэкап диска (иногда по несколько раз, когда данные часто меняются).
Мндд может и не поможет, но общую картину даст. Может у вас софтовые беды.
Соберусь — посмотрю ещё им. Хотя больше доверия ПО от производителя HDD. Торопиться не буду пока. Acronis, наверняка, даст знать, что что-то не так с диском.
Софтовые бэды — это параметр C5. То, что в 05, потеряно навсегда (нет, теоретически можно очистить G-List, но практически это весьма нетривиальная задача, и обычно бесперспективная).
Я про те, что беды видит, но не переносит.
До ремонта SeaTools смотрел в smartctl только на состояние Pre-fail атрибутов, из них только 05 говорил о больших проблемах. Но его значение так и не изменилось пока. И, полагаю, не изменится. Есть предположение, что ещё не переназначенные сектора расположены в основном на дорожках в области служебного раздела, за диском C:, а он, насколько понимаю, перезаписывается только при каждом полугодовом обновлении Windows 10. Атрибут 197 (C5) по нулям теперь, как было — не запомнил, 187 (BB) — не изменяется. SeaTools меняет ещё Self-test log structure, там до ремонта было указано значение в LBA_of_first_error, теперь прочерк (и ещё теперь «Completed without error», до запуска короткого ремонта было «Completed: read failure»). Commands leading to the command that caused the error, тоже остались только те, что давал SeaTools, до него больше месяца ничего не менялось. Предположение о том, что диск скоро сдохнет, скорее всего, не подтвердится. Изменил систему контроля теперь, провожу всего два теста еженедельно в SeaTools (под Windows): S.M.A.R.T. и DST, перед этим и после просматриваю весь вывод smartctl -a, обращая внимание прежде всего на упомянутые в этом комментарии атрибуты. Это гораздо быстрее и информативнее, чем chkdsk. Решение поменять диск при первом (или втором) сбое осталось, но, возможно, за ближайшие 5 лет, пока планирую работать на этом компьютере, такого не произойдёт. Из этих наблюдений первоначальный вывод о софтовом характере проблемы, пожалуй, может подтвердиться. SeaTools своими действиями подкорректировало сообщение, касающееся атрибута 187 «Error XXXX occurred at disk power-on lifetime:» и приведшие к сбою команды, но помню, что до ремонта все команды, приводившие к сбою касались очереди команд. Также на такое количество переназначенных секторов, возможно, повлиял запуск chkdsk с параметром /r. В качестве правильного решения, как теперь кажется, должны были применяться анализ вывода smartctl -a и короткий тест SeaTools. Постоянный мониторинг S.M.A.R.T. также, вероятно, мог бы вовремя выявить проблему.
Это очень зависит от модели диска. Есть откровенные проблемы, где ремапы являются действительно маркером проблем в механике. Например 7200.12, Grenada (ST2000DM001 ST3000DM001, ST1000DM001 от начала выпуска (2011 и до 2013 года, более поздние надёжней). Да и на тех же ноутбучных все совсем по-другому, там ремапы часто — следствие тряски и ударов, а не деградации механики. Хотя тоже есть проблемные семейства.
Релокейты в случае десятков штку только знак внимание — контролируйте. У меня годами жили диски с релокейтом.
Тема утверждает, что интерфейс ломает hdd.
Тема доведена до вопроса в стиле потыкался и не знаю.
Ресурс превращается в пикабу?
Диск «посыпался». Бывают случаи когда процесс приостанавливается, и диск ещё какое-то время работает, но вероятность этого мала. Если интересно, снимите диагностический дамп тестером rlab.ru/tools/rtester.html и покажите, может быть скажу что-то более детальное о состоянии харда.
Спасибо, возможно воспользуюсь. Но, надеюсь, данные не потеряются (есть бэкапы) пока. Буду проводить периодически тест DST, chkdsk /r. При любой проблеме заменю диск. Смутило, что проблемы возникают как-то внезапно и связано это каждый раз с изменением софта. Да, ещё (не знаю важно ли это) дата фильтра файловой системы стояла такая, что тогда никаких AHCI никто ещё не придумал. Но, возможно, не стоит на это обращать внимание, а дата произвольная.
Смутило, что проблемы возникают как-то внезапно и связано это каждый раз с изменением софта
Всё зависит от того насколько эти изменения масштабны. Обновления софта, как и создание бэкапа — это большая нагрузка на диск по сравнению с его нормально-размеренной работой. Логично, что если есть проблемы, то они вылазят «под нагрузкой». Нередки ведь случаи, когда SMART начинает кричать, человек начинает делать бэкап всей информации и диск сдыхает во время бэкапа.
Контроль за здоровьем HDD должен быть постоянный. Раньше у меня постоянно висел HDD Guardian (тот же smartctl по сути), после того как автор прекратил поддержку проекта пришлось перейти на Crystal Disk Info. При выявлении проблем ПО показывает уведомление + настроена отправка на email.
Далее уже надо правильно интерпретировать информацию о проблеме. Если ПО сообщает об ошибках температуры (это обычно за 50 градусов) — надо делать нормальное охлаждение. Появлении CRC ошибок намекает о замене кабеля данных или просто банальной чистке компьютера (полезно разъёмы продуть). Появление нестабильных секторов это ещё не приговор и можно особо не напрягаться, хотя неприятно. А вот если тикнул счётчик переназначенных секторов, то я уже обычно начинаю напрягаться, что проявляется в виде несрочного планирования полного бекапа. А если он тикает не раз на дню, то уже точно надо бекап делать немедленно и выводить этот диск «на обслуживание»: вместо этого диска подставляется резервный, а проблемный пока остаётся в работе под наблюдением и дальнейшим решением как его дальше использовать.
Далее уже надо правильно интерпретировать информацию о проблеме. Если ПО сообщает об ошибках температуры (это обычно за 50 градусов) — надо делать нормальное охлаждение. Появлении CRC ошибок намекает о замене кабеля данных или просто банальной чистке компьютера (полезно разъёмы продуть). Появление нестабильных секторов это ещё не приговор и можно особо не напрягаться, хотя неприятно. А вот если тикнул счётчик переназначенных секторов, то я уже обычно начинаю напрягаться, что проявляется в виде несрочного планирования полного бекапа. А если он тикает не раз на дню, то уже точно надо бекап делать немедленно и выводить этот диск «на обслуживание»: вместо этого диска подставляется резервный, а проблемный пока остаётся в работе под наблюдением и дальнейшим решением как его дальше использовать.
У меня сейчас работает Intel® Rapid Storage Technology. Проблем не видит, но и не видно, что контролирует. На старом компьютере был Acronis Drive Monitor с указанным функционалом, но насколько помню, с Windows 10 работать не стал, хотя, вроде ещё на 8.1 работал. Счетчик переназначенных секторов с момента инцидента ни разу не увеличился, но, наверно, при таких цифрах переназначений вероятность этого ничтожно мала.
Как вам уже правильно сказали, диску похоже настал маленький пушной зверёк.
По поводу смарта и конкретно количества переназначенных секторов. Жёсткий диск может переназначить сектор только во время записи. Если сектор не читается, диск его не заменит, пока вы не попытаетесь этот сектор перезаписать. Так же есть особенность. Диск при попытке записи, видимо, перепроверяет как оно записалось. Если записалось криво, то заменяет сектор (возможно пробует несколько раз записать-прочитать). Но у меня были случат, когда диск записал информацию, переназначенных секторов нет, но информация из сектора не считывается. Кстати, когда сектор не считывается, он попадает в список кандидатов на переназначение. При перезаписи этого сектора, всё становилось хорошо, но через некоторое время обнаруживалась проблема в другом секторе. В итоге избавился от того диска, т.к. не получалось его нормально ввести в рейд, постоянные неконсистенции.
В вашем случае я бы кроме переназначенных секторов посмотрел бы на уоличество кандидатов. Так же в smartmontools можно посмотреть расширенную информацию смарта, там можно посмотреть, как давно были переназначения секторов. И ещё прогнал бы по всему диску очистку — забил бы его нулями, это нужно для того, чтобы диск смог все плохие сектора переназначить.
Насколько я понимаю, SeaTools как раз и забивает нулями «плохие» сектора во время восстановления. Но переназначение не происходит, потому, что почти все свободные сектора использованы. Возможно у меня устаревшая или неполная информация, но я считал, что переназначение происходит только в пределах цилиндра (для скорости). Если всё так, как Вы пишете, то действительно с диском уже ничего сделать нельзя — S.M.A.R.T. уже не помогает, а chkdsk только читает, насколько помню.
S.M.A.R.T. выполняет задачу диагностики. По сути, это лог работы диска, или статистика его работы. Никаким образом на восстановление диска он не влияет. Он ничего не ремонтирует и не восстанавливает. Это просто отражение того, в каком состоянии диск. Ровно точно так же, как анализ крови не лечит человека.
Если нет переназначения, но есть ещё резерв, то у вас софт беды. Копать в сторону шлейфа и БП. Но викторией проверить стоит.
«чинить» диск любыми чинилками, будь то chkdsk или специализированные утилиты стоит только тогда, когда данные с этого диска не нужны.
Если же данные нужны, то первое что нужно сделать, это исключить запись на диск, так как бывают такие неисправности, при которых любая запись на диск автоматически «убивает» свежезаписанные сектора.
Второй шаг это создание копии диска, чтобы «заморозить» его текущее состояние и вычитать как можно больше информации, до того, как больной совсем отойдет в Валгаллу.
Если же данные нужны, то первое что нужно сделать, это исключить запись на диск, так как бывают такие неисправности, при которых любая запись на диск автоматически «убивает» свежезаписанные сектора.
Второй шаг это создание копии диска, чтобы «заморозить» его текущее состояние и вычитать как можно больше информации, до того, как больной совсем отойдет в Валгаллу.
После ремонта SeaTools новых проблем пока не выявлено. Есть достаточное количество бэкапов: ежедневных почти 2 месяца глубиной, еженедельных ещё больше. Есть опыт восстановления dbf баз данных из нескольких бэкапов. Проблема только в том, чтобы правильно определить какие данные повреждены. На диске не так много места занято, поэтому chkdsk в основном работает в неиспользованных секторах. С момента инцидента диск работает больше месяца, проблемы — только те, о которых написал. Никаких других заметных проблем имеющимися средствами не выявил.
Напишите лучше, как у вас устроены бэкапы, что можно быстро прыгать между снапшотами.
Ну, не совсем быстро. Минут 20 уйдёт при восстановлении с внешнего USB 3.1 диска (после полной копии делаю 30 инкрементных давно уже, такой вариант мне кажется удобным). Ещё желательно перед восстановлением делать полную проверку. Бэкапы делаю часто — не реже раза в день. Acronis True Image 2020 на моих данных делает инкрементный бэкап всех разделов диска не более 10 минут обычно, потом идёт автоматическая проверка бэкапа. А вообще, настроил почти по схеме 3-2-1 — два внешних жёстких диска, один старый (USB 2.0), на него делаю бэкапы раз в неделю, а потом после проверки заливаю в облако. До нового формата бэкапов, появившегося в ATI 2020, можно было ещё примонтировать в качестве жёсткого диска любую копию. Теперь в помощи упоминание есть, но в Release notes пишут следующее:
Да, ещё HDD разбит на диски: C: (небольшой системный) и D: (данные) для удобства восстановления. Систему восстанавливаю целиком, а данные — отдельными файлами обычно. Хотя, когда ремонтировал в этот раз, в одном случае пришлось восстанавливать весь HDD целиком с требуемым разбиением — флешка, созданная RecoveryDrive, сделала один большой диск C:.
Please note that new technology for disk-level backup is introduced in Acronis True Image and is being improved, so it may currently have the following limitations:...TI-172340 The backup mounting option is not present for the new backup formatА раньше как-то помогло — была некая софтина, относительно которой были подозрения, что портит в реестре. Примонтировал бэкап на дату, пока её не было ещё, подключил куст реестра, исправил, а софтину удалил. Хотел сейчас также сделать — набросать скрипт, который бы искал нулевые сектора в файлах (хотя бы так, потоки в рассмотрение не берём) и выдавал в лог. А потом бы сравнил логи за сегодня и перед ремонтом kdiff3, например. Но, видно не судьба.
Да, ещё HDD разбит на диски: C: (небольшой системный) и D: (данные) для удобства восстановления. Систему восстанавливаю целиком, а данные — отдельными файлами обычно. Хотя, когда ремонтировал в этот раз, в одном случае пришлось восстанавливать весь HDD целиком с требуемым разбиением — флешка, созданная RecoveryDrive, сделала один большой диск C:.
Такое ощущение, что прочитал рекламную статью Акрониса.
В тексте — 10 упоминаний, 1 раз в тегах, 5 раз в авторских комментариях.
В тексте — 10 упоминаний, 1 раз в тегах, 5 раз в авторских комментариях.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Иногда для того, чтобы выяснить, что дохнет HDD, требуется среагировать на ошибки, выявленные прикладным ПО