Иногда для того, чтобы выяснить, что дохнет HDD, требуется среагировать на ошибки, выявленные прикладным ПО

    Взял за правило всегда ставить все обновления ОС, возможно с небольшой задержкой (до недели), также поставил специальное приложение (APP Center) от производителя материнской платы, которое следит за обновлением драйверов и некоторых программ, а также имеет в составе такие полезные программы, как, например, настройка работы вентиляторов или обновление UEFI (в 2018 году пришлось обновить 3 раза из-за выявленных проблем в процессорах Intel). В этом приложении до последнего времени всё работало, как ожидалось. Каждый день проверял, нет ли чего нового и обычно сразу ставил. Так было до недавнего времени. Когда пришло обновления ПО звуковой карты (оно полностью удаляло классическое приложение и ставило новое), подождал немного и решил установить. Небольшая проблема APP Center в том, что он предлагает установить или обновить ещё ряд программ, которые мне не нужны, например антивирус, а купленный меня вполне устраивает, поэтому перед обновлениями всегда пробегаюсь по списку и снимаю ненужные галки. Так было и на этот раз. Но что-то пошло не так.

    Вообще вкладок обычно две, на одной внизу кнопка «Обновить», на другой «Устанавливать», на каждой «Отменить». Одновременно видно содержимое только одной вкладки. В тот день появилась третья. Можно было бы теперь вернуться на момент перед инцидентом и выложить сюда скриншот, а потом вернуться на текущий момент (резервные копии, хотя и старого формата, пока ещё не удалил), но стараюсь без необходимости восстановлением Acronis True Image не пользоваться — даже проблемы сначала пытаюсь решить обычными способами. И уж тем более не перепрыгиваю в различные состояния системы из-за желания сделать скриншот (хотя восстановление происходит быстро и запускается прямо из работающей ОС, требуется только разрешить перезагрузку). Поэтому полагаюсь на память. А она может подвести: в тот день несколько раз пробегал по вкладкам. Делал, вроде, всё логично, но что-то не учёл.

    Перед обновлением не заглянул на третью вкладку, где приложение также поставило галки напротив обновления драйверов на сетевую карту и HDD. Я, если и хотел обновить их, то не в этот день. Поэтому, когда увидел, что-то неожиданное, сразу обновление остановил. Ну и, поскольку видел, что часть драйверов установилась, а часть нет, откатился на утреннюю копию системы с помощью Acronis True Image 2019, что иногда делал в подобных случаях, чтобы завтра обновиться, а пока заняться другими делами. Весь день проработал без проблем, а на следующее утро резервная копия Acronis не создалась из-за ошибок жёсткого диска. Очевидное решение — выполнить chkdsk. Проверка не прошла. Тогда chkdsk c: /scan /v /r. Нашлись ошибки в кеше Хрома, чтобы исправить нужно было перезагрузиться. Согласился. Это было последнее, что удалось сделать.

    При загрузке система выпала в BSOD и начала перезагружаться до следующего BSODа и так в цикле. До рабочего стола не доходило. Не проблема: у меня резервные копии хранятся на внешнем USB HDD, на котором установлен Acronis Survival Kit, который при загрузке позволяет запустить восстановление резервной копии в среде WinRE. Неудача. Программа рекомендовала загрузиться с Linux флешки Acronis и продолжить восстановление. А вот этой флешки я заранее не сделал. Зато была флешка RecoveryDrive, с неё и загрузился (чтобы воспользоваться чужим компьютером, пришлось бы ждать — было раннее утро) и поставил на компьютер чистую систему. Установил True Image и создал-таки загрузочную флешку с Linux версией этого ПО.

    Восстановил копию системы на вечер перед инцидентом и опять проверил жёсткий диск — те же ошибки. Покопался в журнале «Система», нашёл, что проблема, скорее всего, в одном фильтре файловой системы (ошибки возникали сразу после его загрузки, к тому же дата уж больно древняя). На этот раз APP Center (в этой копии) уже не предлагал обновиться, поэтому восстановился на последнюю копию перед инцидентом. Успешно обновил все драйвера, опять всё проверил. Дополнительно поставил smartmontools. Оказалось, что за это время S.M.A.R.T. успел переназначить больше 2200 секторов (почти 100%), в общем HDD испорчен, хотя проблема не в дефектах на поверхности диска, а только софтовая. Но по крайней мере всё работало. До тех пор, пока не купил подписку на Acronis True Image 2020.

    Обновился и опять не смог сделать копию. Точнее, иногда копия делалась, иногда нет из-за ошибок HDD. Написал в техподдержку Acronis (штатные средства не выявляли проблем) и продолжил попытки найти, что не даёт работать на этот раз. Проверил с помощью chkdsk ещё и скрытые диски — нет проблем. Добрался до SeaTools – ПО от производителя HDD как раз для таких случаев. Вот оно и выявило проблему — тест DST не проходил. Предлагалось создать Linux флешку и продолжить ремонт, загрузившись с неё. Что я и сделал. DST также не проходил до конца, запустил полную проверку, а затем короткий ремонт. После этого DST прошёл. И Acronis True Image 2020 стал без проблем делать копии. Но вопросы остались.

    После ремонта smartctl показал, что количество переназаначенных секторов не увеличилось, chkdsk (включая скрытые диски) также не показал увеличения числа дефектных секторов, похоже, проблема полностью не решена и, возможно, проявится в будущем. А это значит, что, наверно, придётся менять HDD. Кстати, поддержка Acronis в понедельник ответила (я отправлял запрос в субботу), но проблема мной была уже решена (хотя купить за рубли недорого Acronis True Image в России уже нельзя, но поддержка для физлиц всё-таки есть, привык с 2010 года к этому софту, менять не собираюсь, буду платить в Евро теперь).

    Возможно, специалисты в области восстановления данных смогут прояснить, верны ли были мои действия и выводы. Сразу скажу, что теперь в Windows 10 восстановление заведомо работоспособной VSS копии не даёт уже уверенности в дальнейшей её нормальной работе.

    UPD: Sergey_datex пишет, что диск сдох. Наверно, так и есть.
    UPD: Поправил заголовок после комментария oller
    UPD: В качестве некоторого вывода к статье вполне, как мне мажется, может подойти этот мой комментарий.
    UPD: Первый сбой диска проявился примерно через полгода после публикации этой статьи. И был связан опять с обновлением, на этот раз самого App Center. Это обновление не прилетело пока автоматически, но появилось на сайте и лежало с декабря, вроде. Решил, что уже пора ставить и установил. Вскоре начались проблемы у Acronis True Image – слетели практически все настройки бэкапов, а это важная часть его работы. Атрибут 5 S.M.A.R.T. увеличился при этом незначительно. Восстановил вчерашнюю копию диска C:, но тут ждал ещё неприятный сюрприз. Восстановление проблемы не решило, а после загрузки ОС (я внешний HDD, с которого прошло восстановление, от компьютера при этом не отсоединял) оказалось, что всё содержимое папки с последними бэкапами, а там было несколько цепочек (несколько полных версий, за каждой — 10 инкрементных копий), исчезло. То есть папка, в которой они лежали оказалась пустой. Здесь и спасла схема 3-2-1. Восстановил с последней еженедельной резервной копии с другого внешнего HDD. На этот раз запускал восстановление не из работающей ОС, а с помощью Acronis Survival Kit. Поставил галку «Выключить компьютер после завершения операции» и отсоединил диск с бэкапами от компьютера перед загрузкой ОС. Но при запуске короткого теста DST вновь выявились проблемы, которые привычно уже решил описанным выше методом. Нормальная работа продолжалась дней 10. А потом диск начал сыпаться. За три дня атрибут 5 увеличился почти до 6500, всё периодически зависало, chkdsk обнаруживал и исправлял различные ошибки, тест DST то не проходил, то благополучно завершался. Купил новый HDD того же объёма, но уже другого производителя, восстановил всё содержимое старого HDD с имеющихся бэкапов практически без проблем и довольно быстро. Наблюдаю теперь за состоянием нового диска через smartctl -a с той же периодичностью.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 42

      0
      Не затруднит ли автора статьи пояснить, каков механизм изменения reallocated sector count в этом случае и как он связан с обновлением ПО (очевидно, не HDD, а некоего системного драйвера)?
        0
        Я в восстановлении данных не силён, поэтому и прошу комментариев от специалистов. Возможно, это не верное предположение. До инцидента состоянием S.M.A.R.T. не интересовался, не исключено, что проблема уже была, но не припомню момента, когда бы ещё могло быть переназначено столько секторов.
          0
          Я в восстановлении данных не силён

          На этом можно закрыть тред, его место на форуме суппорта акрониса
          0
          reallocated sector count показывает количество успешно переназначенных секторов.
          В данном случае этот счетчик показывает две вещи
          1. Данные не были потеряны, они были перенесены из плохих секторов, в хорошие
          2. На диске есть плохие сектора

          Отсюда следуют логические выводы
          1. Так как на диске есть плохие сектора, то стоит посмотреть на динамику роста их количества. Если количество плохих секторов быстро растет, то диск стоит заменить
          2. Механизм reallocated sector count подразумевает рост только, когда плохой сектор был все же прочитан (после нескольких повторов) и переписан в другое место. Соответственно если плохой сектор есть, но не был успешно прочитан, то он не будет отражен в этом атрибуте.
          3. Плохих секторов может быть больше, чем показывает reallocated sector count. Эти сектора могут бы еще не отмечены диском, либо показаны в других атрибутах. Например в Current Pending Sector Count и Reported Uncorrectable Errors
          +1

          У вас просто сдох диск, с ПО не связано. Для сигейта нормально забивать перед смертью релокейт лист. Да и вообще наличие хоть одного релокейта конкретно на сигейте говорит о скорой кончине.

            +1
            Спасибо, буду менять диск.
              0
              У меня в компе стоит сигейтовский HDD, за 67000 часов (~8 лет) накопилось 144 ремапа, диск вполне здравствует. А до этого был пятисотгиговый сигейт, который я сразу после покупки уронил на асфальт, после ремапа там было около 400 переназначенных секторов, и он тоже отработал несколько лет.
                0
                Тогда подожду пока, понаблюдаю.
                  0
                  Добрый день, вы можете запустить MHDD в режиме ремапа, по тесту поверхности будет понятно, поживёт ли диск, или уже всё, так как в вашем случае повреждения файловой системы — это плохой признак.
                    0
                    Не уверен, что поможет. Буду ждать первого сбоя. Там SeaTools опять попробую исправить. А вообще, склоняюсь к замене HDD в ближайшее время (уж очень много секторов переназначено). Пока был Acronis True Image 2019, еженедельно запускал chkdsk с параметром /r. Количество проблемных секторов не увеличивалось. Данные не должны потеряться. Каждый день делаю бэкап диска (иногда по несколько раз, когда данные часто меняются).
                      0

                      Мндд может и не поможет, но общую картину даст. Может у вас софтовые беды.

                        0
                        Соберусь — посмотрю ещё им. Хотя больше доверия ПО от производителя HDD. Торопиться не буду пока. Acronis, наверняка, даст знать, что что-то не так с диском.
                          0
                          Софтовые бэды — это параметр C5. То, что в 05, потеряно навсегда (нет, теоретически можно очистить G-List, но практически это весьма нетривиальная задача, и обычно бесперспективная).
                            0

                            Я про те, что беды видит, но не переносит.

                              0
                              До ремонта 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. также, вероятно, мог бы вовремя выявить проблему.
                                0
                                Сейчас сравнил побайтно наиболее объёмную часть важных для меня данных на диске и в копии до инцидента. Различий не обнаружено. Значит, наверняка можно полагаться на текущий еженедельный мониторинг, а бэкапы со временем удалить.
                      +1
                      Это очень зависит от модели диска. Есть откровенные проблемы, где ремапы являются действительно маркером проблем в механике. Например 7200.12, Grenada (ST2000DM001 ST3000DM001, ST1000DM001 от начала выпуска (2011 и до 2013 года, более поздние надёжней). Да и на тех же ноутбучных все совсем по-другому, там ремапы часто — следствие тряски и ударов, а не деградации механики. Хотя тоже есть проблемные семейства.
                        0
                        ST1000DM001
                        У этих по-моему процент падучести приближается к трёхзначной цифре.
                          0
                          Былы еще подобные на моей памяти. 40гб Samsung-и за пять лет вымерли в трех аудиториях в институте. Все.
                            0
                            У самого один такой издох.
                        0

                        Релокейты в случае десятков штку только знак внимание — контролируйте. У меня годами жили диски с релокейтом.

                        +5

                        Тема утверждает, что интерфейс ломает hdd.
                        Тема доведена до вопроса в стиле потыкался и не знаю.
                        Ресурс превращается в пикабу?

                          0
                          Поправил заголовок.
                            +3

                            Хорошо. Так как связана "реализация интерфейса" с "ремонтом жесткого диска"? Статья вида "я что-то нажал, а оно само, оно виновато". Если это развёрнутый вопрос к читателям, то может воспользуетесь тостером/SO? Если же это полноценная статья, не хватает полноценного разбора.

                              0

                              Upd.: Прошу прощения, первый вопрос отменяется. Увидел сообщение о смене заголовка при не обновившемся заголовке в самой статье и думал, что это новая версия, а старая была еще кликбейтовее.
                              /offtop/ Кстати, а в мобильной версии править свои комментарии нельзя же?

                          0
                          Диск «посыпался». Бывают случаи когда процесс приостанавливается, и диск ещё какое-то время работает, но вероятность этого мала. Если интересно, снимите диагностический дамп тестером rlab.ru/tools/rtester.html и покажите, может быть скажу что-то более детальное о состоянии харда.
                            0
                            Спасибо, возможно воспользуюсь. Но, надеюсь, данные не потеряются (есть бэкапы) пока. Буду проводить периодически тест DST, chkdsk /r. При любой проблеме заменю диск. Смутило, что проблемы возникают как-то внезапно и связано это каждый раз с изменением софта. Да, ещё (не знаю важно ли это) дата фильтра файловой системы стояла такая, что тогда никаких AHCI никто ещё не придумал. Но, возможно, не стоит на это обращать внимание, а дата произвольная.
                              0
                              Смутило, что проблемы возникают как-то внезапно и связано это каждый раз с изменением софта

                              Всё зависит от того насколько эти изменения масштабны. Обновления софта, как и создание бэкапа — это большая нагрузка на диск по сравнению с его нормально-размеренной работой. Логично, что если есть проблемы, то они вылазят «под нагрузкой». Нередки ведь случаи, когда SMART начинает кричать, человек начинает делать бэкап всей информации и диск сдыхает во время бэкапа.
                            +1
                            Контроль за здоровьем HDD должен быть постоянный. Раньше у меня постоянно висел HDD Guardian (тот же smartctl по сути), после того как автор прекратил поддержку проекта пришлось перейти на Crystal Disk Info. При выявлении проблем ПО показывает уведомление + настроена отправка на email.

                            Далее уже надо правильно интерпретировать информацию о проблеме. Если ПО сообщает об ошибках температуры (это обычно за 50 градусов) — надо делать нормальное охлаждение. Появлении CRC ошибок намекает о замене кабеля данных или просто банальной чистке компьютера (полезно разъёмы продуть). Появление нестабильных секторов это ещё не приговор и можно особо не напрягаться, хотя неприятно. А вот если тикнул счётчик переназначенных секторов, то я уже обычно начинаю напрягаться, что проявляется в виде несрочного планирования полного бекапа. А если он тикает не раз на дню, то уже точно надо бекап делать немедленно и выводить этот диск «на обслуживание»: вместо этого диска подставляется резервный, а проблемный пока остаётся в работе под наблюдением и дальнейшим решением как его дальше использовать.
                              0
                              У меня сейчас работает Intel® Rapid Storage Technology. Проблем не видит, но и не видно, что контролирует. На старом компьютере был Acronis Drive Monitor с указанным функционалом, но насколько помню, с Windows 10 работать не стал, хотя, вроде ещё на 8.1 работал. Счетчик переназначенных секторов с момента инцидента ни разу не увеличился, но, наверно, при таких цифрах переназначений вероятность этого ничтожно мала.
                                0

                                У меня ещё а виндовс 7 вопила про проблемы смарт. В биосе есть настройка контроля смарт.

                              0

                              Как вам уже правильно сказали, диску похоже настал маленький пушной зверёк.
                              По поводу смарта и конкретно количества переназначенных секторов. Жёсткий диск может переназначить сектор только во время записи. Если сектор не читается, диск его не заменит, пока вы не попытаетесь этот сектор перезаписать. Так же есть особенность. Диск при попытке записи, видимо, перепроверяет как оно записалось. Если записалось криво, то заменяет сектор (возможно пробует несколько раз записать-прочитать). Но у меня были случат, когда диск записал информацию, переназначенных секторов нет, но информация из сектора не считывается. Кстати, когда сектор не считывается, он попадает в список кандидатов на переназначение. При перезаписи этого сектора, всё становилось хорошо, но через некоторое время обнаруживалась проблема в другом секторе. В итоге избавился от того диска, т.к. не получалось его нормально ввести в рейд, постоянные неконсистенции.
                              В вашем случае я бы кроме переназначенных секторов посмотрел бы на уоличество кандидатов. Так же в smartmontools можно посмотреть расширенную информацию смарта, там можно посмотреть, как давно были переназначения секторов. И ещё прогнал бы по всему диску очистку — забил бы его нулями, это нужно для того, чтобы диск смог все плохие сектора переназначить.

                                0
                                Насколько я понимаю, SeaTools как раз и забивает нулями «плохие» сектора во время восстановления. Но переназначение не происходит, потому, что почти все свободные сектора использованы. Возможно у меня устаревшая или неполная информация, но я считал, что переназначение происходит только в пределах цилиндра (для скорости). Если всё так, как Вы пишете, то действительно с диском уже ничего сделать нельзя — S.M.A.R.T. уже не помогает, а chkdsk только читает, насколько помню.
                                  0

                                  S.M.A.R.T. выполняет задачу диагностики. По сути, это лог работы диска, или статистика его работы. Никаким образом на восстановление диска он не влияет. Он ничего не ремонтирует и не восстанавливает. Это просто отражение того, в каком состоянии диск. Ровно точно так же, как анализ крови не лечит человека.

                                    0
                                    Да, наверно, некорректно выразился. Спасибо.
                                    0

                                    Если нет переназначения, но есть ещё резерв, то у вас софт беды. Копать в сторону шлейфа и БП. Но викторией проверить стоит.

                                    +2
                                    «чинить» диск любыми чинилками, будь то chkdsk или специализированные утилиты стоит только тогда, когда данные с этого диска не нужны.
                                    Если же данные нужны, то первое что нужно сделать, это исключить запись на диск, так как бывают такие неисправности, при которых любая запись на диск автоматически «убивает» свежезаписанные сектора.
                                    Второй шаг это создание копии диска, чтобы «заморозить» его текущее состояние и вычитать как можно больше информации, до того, как больной совсем отойдет в Валгаллу.
                                      0
                                      После ремонта SeaTools новых проблем пока не выявлено. Есть достаточное количество бэкапов: ежедневных почти 2 месяца глубиной, еженедельных ещё больше. Есть опыт восстановления dbf баз данных из нескольких бэкапов. Проблема только в том, чтобы правильно определить какие данные повреждены. На диске не так много места занято, поэтому chkdsk в основном работает в неиспользованных секторах. С момента инцидента диск работает больше месяца, проблемы — только те, о которых написал. Никаких других заметных проблем имеющимися средствами не выявил.
                                      +1

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

                                        0
                                        Ну, не совсем быстро. Минут 20 уйдёт при восстановлении с внешнего USB 3.1 диска (после полной копии делаю 30 инкрементных давно уже, такой вариант мне кажется удобным). Ещё желательно перед восстановлением делать полную проверку. Бэкапы делаю часто — не реже раза в день. Acronis True Image 2020 на моих данных делает инкрементный бэкап всех разделов диска не более 10 минут обычно, потом идёт автоматическая проверка бэкапа. А вообще, настроил почти по схеме 3-2-1 — два внешних жёстких диска, один старый (USB 2.0), на него делаю бэкапы раз в неделю, а потом после проверки заливаю в облако. До нового формата бэкапов, появившегося в ATI 2020, можно было ещё примонтировать в качестве жёсткого диска любую копию. Теперь в помощи упоминание есть, но в Release notes пишут следующее:
                                        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:.
                                        +1
                                        Такое ощущение, что прочитал рекламную статью Акрониса.
                                        В тексте — 10 упоминаний, 1 раз в тегах, 5 раз в авторских комментариях.
                                          0
                                          Чем пользуюсь, о том и пишу. Говорят, что на настоящий момент есть другие достойные конкуренты, но я о них подробно ничего не знаю. А упомянутый в статье продукт не раз спасал в сложных ситуациях, как и в этом случае.

                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                        Самое читаемое