Как определить, есть ли на диске проблемы с использованием smartctl?
У меня есть сервер Ubuntu 12.04, использующий программный RAID1, который полностью перестал отвечать. Я перезагрузился, и он завис при загрузке с сообщением «/ tmp не готов или отсутствует», поэтому я пропустил и запустил терминал ручного восстановления. Все выглядело нормально, за исключением того, что моя ресинхронизация RAID была ужасно медленной. Тем не мение, cat /proc/mdstat не показывает фактических сбоев RAID.
Я наткнулся на мой /proc/sys/dev/raid/speed_limit_min следуя инструкциям Вот, но это не слишком помогло. Мой массив 1 ТБ повторно синхронизируется уже 30 минут, но завершен всего на 0,3%.
Итак, я установил smartmontools и проверил диски с помощью:
sudo smartctl --all /dev/sda
sudo smartctl --all /dev/sdb
Оба сообщают о состоянии «ПРОЙДЕНО», но sdb также показывает несколько строк, например:
Error 83 occurred at disk power-on lifetime: 15147 hours
Error 82 occurred at disk power-on lifetime: 15147 hours
Error 81 occurred at disk power-on lifetime: 15147 hours
Error 80 occurred at disk power-on lifetime: 15147 hours
вместе с каким-то шестнадцатеричным дампом для каждого.
Что это значит? Должен ли я интерпретировать эти ошибки как означающие, что мой диск sdb умирает? Как мне это подтвердить?
Изменить: также связано с тем, что с момента сбоя я теперь не могу подключиться к серверу по SSH. Я могу получить к нему доступ с физического терминала, и, похоже, нет чрезмерной нагрузки. Я убедился, что брандмауэр отключен, и я все еще могу пинговать сервер, но ssh myuser@myserver приводит к "Превышено время ожидания подключения".
Что касается вашей резервной копии - ждать ошибки или предупреждения SMART уже слишком поздно, чтобы делать резервную копию. Передовой опыт будет включать проверенный план резервного копирования, а также достаточную избыточность подсистемы хранения для обработки ожидаемых отказов оборудования.
Если один из дисков выпал из рейда, скорее всего, причина в этом. Я бы заменил неисправный диск (звучит как sdb) и вместо этого восстановил бы его. Переходим к умным данным.
Есть большой раздел в smartctl -a вывод в интеллектуальной структуре данных. Это большая матрица слов и чисел, которая сообщает вам текущие пороговые значения для конкретных тестов. Вот некоторые из наиболее важных, на которые стоит обратить внимание:
Все это связано с проблемами с поверхностью диска (за исключением идентификатора 10, который связан с двигателем шпинделя). Поверхность диска, скорее всего, выйдет из строя из-за всего, что находится в приводе. Если какой-либо из них ненормально высок (сотни или тысячи), вы точно знаете, что существует большая проблема.
Регистры внизу выглядят примерно так:
ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 ff ff ff 0f Error: UNC at LBA = 0x0fffffff = 268435455
В этом случае на диске произошла ошибка UNC (неисправимая ошибка чтения / записи).
Я считаю, что если вы видите что-то подобное:
Error 518 occurred at disk power-on lifetime: 16859 hours
... диск следует заменить, когда это будет удобно.
Проблема SSH может быть связана с диском (возможно, поврежденная часть находится в двоичном файле SSH), но это, вероятно, что-то еще, что вам следует исследовать отдельно.
Многие атрибуты в таблице атрибутов SMART являются полезными индикаторами неисправности дисков. Не могли бы вы обновить свое сообщение выводом 'smartctl -data -A / dev / sdb'? Таблица атрибутов зависит от диска, поэтому я не могу перечислить те, которые будут актуальны, кроме довольно общих, таких как Reallocated_Sector_Ct, Offline_Uncorrectable и т. Д. Страница Википедии на УМНАЯ содержит описания большинства атрибутов.
Самопроверка SMART, показывающая четверную удачу, тоже полезна, но эти счетчики атрибутов могут сразу сказать вам, если диск выходит из строя. Накопитель может не вызывать общее предупреждение о вреде для здоровья SMART, но очевидно, что он исчезнет.
Прежде всего, убедитесь, что у вас есть резервная копия.
Что касается ошибки / tmp, это известная ошибка:
https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1091792
Re: Ошибки SMART:
Пройдите длинный тест: smartctl -t long /dev/sdb
Вы можете запустить это в любое время. Это займет некоторое время. Посмотреть результаты с smartctl -l /dev/sdb когда это будет сделано.
И, конечно же, прежде всего убедитесь, что у вас есть резервная копия.
Наибольшее беспокойство, которое я бы вызвал из того, что вы опубликовали, заключается в том, что у вас, кажется, внезапный кластер ошибок (при активности диска <2 лет). Однако отказавший диск не должен вывести вашу систему из строя (на самом деле вы должны увидеть много других шумов в журналах примерно в то время, когда он завис). Случайные ошибки - это нормально, но многие в то же время вызывают беспокойство.
SMART полезен для раннего предупреждения иногда, вы, конечно, не можете полагаться только на это.
Так что не помешает снова вернуться назад. Но не думаю, что у вас есть повод для паники.