Ошибка устройства хранения read dev sd0a

Пропадает HDD на PVDR-24NRL2

Приветствую.
Появилась проблема с регистратором PVDR-24NRL2. При выключении/включении не виден жесткий диск (Seagate ST3000VX000). При повторной перезагрузке появляется и все работает нормально до следующей перезагрузки.
В момент когда жесткий не виден, в журнале есть следующие записи:
1513 2015-03-31 20:55:09 Вход default
1514 2015-03-31 20:55:28 Очистить /mnt/idea0
1515 2015-03-31 20:55:28 Ошибка накопителя Read, /dev/sd0a, X
1516 2015-03-31 20:55:28 Ошибка накопителя Read, /dev/sd0a, X
1517 2015-03-31 20:55:28 Ошибка накопителя Read, /dev/sd0a,
1518 2015-03-31 20:55:51 Вход user<Web:192.168.1.98>
…

Что это, жесткий или регистратор сдыхает?
Работало все нормально до этого где-то полгода

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

Вы должны авторизоваться, чтобы оставлять комментарии.

Авторизация

Диск SATA-NTFS начал глючить. Я скинул все на комп и отформатировал его. После начал перекидывать на него фильмы. Скачалось несколько и выдало ошибку —

Error mounting /dev/sdb1 at /media/ura/U: Command-line `mount -t "ntfs" -o "uhelper=udisks2,nodev,nosuid,uid=1000,gid=1000,dmask=0077,fmask=0177" "/dev/sdb1" "/media/ura/U"' exited with non-zero exit status 13: $MFTMirr does not match $MFT (record 0).
Failed to mount '/dev/sdb1': Input/output error
NTFS is either inconsistent, or there is a hardware fault, or it's a
SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows
then reboot into Windows twice. The usage of the /f parameter is very
important! If the device is a SoftRAID/FakeRAID then first activate
it and mount a different device under the /dev/mapper/ directory, (e.g.
/dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation
for more details.

Сейчас просто диск не подключается.
Прошу конкретной помощи.

Забыл написать что при подключении к телевизору через приставку DTV все отлично воспроизводит

Здравствуйте!

Xubuntu 20.04
Внешний жёсткий диск на 500Гб в контейнере на один диск от AGE STAR, подключается через USB.
Мать ASUS возраст 10 лет.

Настроил автомонтирование этого внешнего диска.
Сначала физически включаю диск, потом комп.
Сразу при загрузке стоит работа бэкапа — BackinTime.
Всё нормально работало несколько месяцев (обновления системы за этот период не было).

Теперь (ничего вроде не менялось в системе) диск не монтируется:

— на уровне железа и в БИОСе он виден и нормально на этом этапе подключается при запуске;

— во время загрузки (ещё чёрно-белый экран, но режим монитора уже вроде бы графический) процесс загрузки надолго застревает — что-то с SATA, к внешнему диску идёт непрерывное обращение, после его физического выключения (выключателем) процесс загрузки продолжается нормально;

— если после завершения загрузки системы сразу попытаться снова включить этот (уже выключенный во время проблем с загрузкой — см.выше) внешний диск (выключателем), то он непрерывно работает, но ОС его не видит (диск непрерывно мигает как при обращении к нему, а GParted говорит, что не может получить статус такого устройства, называя конкретное устройство) (подождав, диск выключаем выключателем);

— если, не выключая компа, подождать некоторое время и снова включить выключателем внешний жёсткий диск — то он сам по себе тихо работает, но GParted его не видит вообще и даже не пытается искать;

— если теперь, не выключая компа, выключить выключателем внешний жёсткий диск и перемкнуть его в другой USB-разъём, то при его повторном включении он снова начинает долго мигать, а GParted опять говорит, что не может получить статус такого устройства.

Что это может быть:

1) Железо? Где? Мать, контейнер, диск?
2) ОС? Баг? Настройки?
3) Неудачная конфигруация бэкапа? Но почему это начинается ещё до запуска графической оболочки?

Как это исправить?

Спасибо

Эх. тоже немного уйду в оффтоп
Проблема с секторами ушла на нет, на созданный выше раздел заинсталлил ось, ребутнулся — все ок.
Но спустя некоторое время ось начала вставать колом, хард судя по всему потерялся на лету (собрать анамнез не удалось, т.к. ни одна утилита не стартовала, терминал, чей рабочий набор памяти жил в оперативе только беспомощно подмигивал курсором с периодическими фризами всего) После перезагрузки reset’ом — знакомая картинка:

Диска биос больше не нашел

Зацепил обратно к другому десктопу — все гуд, только автоматом восстановилось несколько потерянных inode судя по dmesg:

[   69.116972] EXT4-fs (sda1): 273 orphan inodes deleted
[   69.116976] EXT4-fs (sda1): recovery complete
[   69.314627] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)

Опять забил весь нулями — 372 гб пролетели без проблем

chocobo@desktop ~ $ ls -l /mnt/testfile 
-rw-r--r-- 1 root root 390960017408 янв 20 20:08 /mnt/testfile
chocobo@desktop ~ $ df -h
Файл.система   Размер Использовано  Дост Использовано% Cмонтировано в
...
/dev/sda1        367G         367G     0          100% /mnt

Видимо пришла очередь прощаться с

PSU

. Комплексная проблема — коварная штука, вроде и хард был с unrecoverable секторами, так еще и БП чудит

Сейчас воткнул туда ноутбучный 2,5″ хард на 5400 rpm, которому мощей нужно поменьше — вот уже несколько часов работает, зараза

Как не надо восстанавливать данные, или чтобы вам тоже так везло

Все мы периодически сталкиваемся с отказами устройств хранения. В интернете написаны сотни инструкций, как без специального оборудования прочитать все что только возможно с устройств, еще отвечающих на обычные запросы ОС. Но мне долгие годы не везло, диски либо умирали совсем-совсем, либо файловая система была еще доступна и я просто читал все то, что читалось в обычном режиме. И ждал. Должно же было случиться, чтобы умирающий диск попал мне именно в состоянии, требующем большего, чем самые элементарные действия?

И вот этот день настал. На разделе поверх софтового raid0, хранившем, откровенно говоря, всякую ерунду, файлы оказались недоступны, а причина — долгожданный I/O Error. Неожиданным было то, что устройства-носителя второй половинки рэйда вообще не оказалось в выводе fdisk, хотя список файлов был доступен. Перезагрузка — и массив собрался, а файлы прекрасно читаются. В отчете SMART видно огромное количество переназначенных секторов. Как раз то, что нужно. Отключаю диски и начинаю продумывать стратегию восстановления.

Для вычитывания уцелевших секторов решено было использовать GNU ddrescue — специализированную версию dd для чтения данных с умирающих дисков, которая позволяет выбирать стратегию чтения и умеет строить карту диска для продолжения работы после сбоев, а они обязательно будут, работаю ведь с неисправными устройством.

Итак, подключаю первый диск к своему десктопу, и POST торжественно сообщает, что один из подключенных дисков совсем плох. Загрузка ОС прошла штатно, если не считать пару сообщений о каких-то ошибках ata устройства. После успешной загрузки fdisk -l пациента видит, ну наконец-то я буду восстанавливать целостность данных raid0.

ddrescue -ndAvv /dev/sdd1 bad mapbad

Процесс пошел довольно резво, 80 МБ/с. Из-за шума охлаждающего диски вентилятора, изъятого специально по такому случаю из списанного сервера, леденящих кровь звуков чтения умирающего диска было бы не слышно, даже если бы они были. Возможно, не слышать их даже лучше. Меньше знаешь — крепче спишь.

К утру работа ddrescue завершилась, и на новеньком диске лежали образ и карта погибающего товарища. Но повторный запуск ddrescue почему-то завершался подозрительно быстро, а карта

«Что-то очевидно пошло не так», — подсказал сонный внутренний голос. «А попробуй-ка fdisk -l» — вот, и разум уже подключился. /dev/sdd в выводе не оказалось. — Как такое вообще возможно?, — Ах да, на сервере было тоже самое, — Значит, не все еще пропало: примерно такие мысли обитали в голове весь рабочий день.

Вечером подопытный диск опять подавал признаки жизни, а передо мной стояла непростая задача: что делать с полученным образом, ведь ddrescue c финализированной картой что-либо читать отказывался, оставив мне файл образа меньше размера раздела.
С одной стороны, ddrescue умеет заполнять — блоки произвольными данными, чтобы потом определить битые файлы. С другой стороны, я не просил его делать спарс-файл (параметр -S), и усиленное гугление вопроса о том, как именно будет заполняться меньший-чем-раздел файл образа, осталось без ответа.

Полагаться на случай крайне не хотелось, и я решил с калькулятором в руках изучить карту диска. Оказалось, что 96% содержимого диска успешно прочиталось и попало в первый + блок. Но к сожалению, сумма всех + блоков не давала размер считанного образа, что окончательно спутало мне все карты. По-этому я пошел другим путем: раз у меня есть хорошее начало и черт знает что в конце, почему бы не достать старый добрый dd и не слепить из непонятного образа как раз то, с чем можно спокойно работать?

dd if=bad of=bad_new bs=16M count=42751
dd if=/dev/zero of=bad_new bs=1024 seek=700432384 count=32139617

Результат — новенький образ, который теперь в точности такого же размера, как и умирающий раздел, а именно 750153729024 байт. Теперь займемся ноликами в конце. Делаю вручную

и запускаю:

ddrescue -ndAvv /dev/sdd1 bad_new mapbad

Ура! Теперь все хорошо. Читающиеся блоки с диска переехали на пустое место нового образа по нужным адресам, а карта опять финализировалась, и мои приключения подходят к концу. Но может быть сделать последний рывок и перечитать — блоки по одному сектору? Теперь даю ddrescue

и запускаю так:

ddrescue -ndAvv /dev/sdd1 -с1 bad_new mapbad

В общем, он повел себя совсем не так, как я рассчитывал. Наткнувшись на плохой сектор в — блоке, он переходил к следующему — блоку, пока не зацепился за уверенное чтение из последнего — блока. Час спустя я остановил это безобразие с помощью CTRL-C и запустил чтение на нормальной скорости. Еще несколько гигабайт из конца раздела прочитались, пока ddrescue снова не напоролся на сбойные сектора, что почему-то опять привело к пропаданию /dev/sdd из системы и финализации карты, которая сильно распухла и представляла собой месиво из +, — и ? блоков. Разбирать все это не было уже никакого смысла, и я решил прекратить мучить умирающего и заняться, наконец, сборкой массива. Но перед этим захотелось выяснить, что было бы, если бы я использовал режим заполнения. Готовлю заполнитель и включаю режим заполнения, не забыв заменить карту на первоначальную:

printf "BADSECTOR" > tmpfile
ddrescue --fill-mode=- tmpfile bad mapbad

И получаю еще один образ правильного размера! Как он это сделал для меня осталось загадкой, ведь я несколько раз пересчитал сумму размеров + блоков из карты, и она не совпадала с размером готового файла.

И вот на месте отдающего магнитную душу богу уже его здоровый собрат, а я выполняю команды:

losetup /dev/loop1 bad_new 
mdadm --assemble -o /dev/md12 /dev/loop1 /dev/sdd1

Но результат, мягко говоря, не тот, что я ожидал после 24 часов надежды на успех:

mdadm: no RAID superblock on /dev/loop1
mdadm: /dev/loop1 has no superblock - assembly aborted

Что делать, попробуем теперь пообщаться с гуглом и разделами:

#mdadm --examine /dev/loop1
mdadm: No md superblock detected on /dev/loop1.

— То есть как это no md superblock detected?
— А у этого, который пока здоров?

#mdadm --examine /dev/sdd1
/dev/sdd1:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 64d38efd:b8e92c8c:f5292846:21864477
  Creation Time : Fri Oct 10 20:22:23 2008
     Raid Level : raid0
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 2

    Update Time : Fri Oct 10 20:22:23 2008
          State : active
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0
       Checksum : 6f768a67 - correct
         Events : 1

     Chunk Size : 4K

— Версия 0.90.00? А где должен быть суперблок у mdadm 0.90.00?
— В конце раздела.
— А как его прочитать с помощью mdadm?
— Никак.
— То есть как это никак? Ну ладно, так где там он поточнее?
— Не дальше 128K но не ближе 64К от конца раздела, выровнен по границе 64К, размер 4К.

Н-да, беру dd и проверяю:

dd if=/dev/sdd1 of=last128 bs=1024 skip=732571873 count=128
dd if=last128 of=bad_new bs=1024 seek=732571873 count=128

Да, суперблок записался в конец раздела по правильному адресу, но собираться массив с двумя одинаковыми суперблоками все равно не хочет, значит надо дать ему именно тот суперблок, с помирающего.

Снова замена диска, только бы прочитался:

#dd if=/dev/sdd1 of=last128 bs=1024 skip=732571873 count=128
dd: reading `/dev/sdd1': Input/output error
0+0 records in
0+0 records out

«Да, такого удара Великий комбинатор не испытывал никогда», — почему-то в памяти всплыла именно эта бессмертная цитата.
Ну ладно, так легко мы не сдаемся. А мы вот так:

dd if=/dev/sdd1 of=last128 bs=1024 skip=732571873 count=128 conv=noerror

Эх, размер last128 >0 но <128К. И где там что? Как с этим работать? А как сделать нолики-то вместо убитых секторов? А вот так:

dd if=/dev/sdd1 of=last128 bs=1024 skip=732571873 count=128 conv=noerror,sync

dd if=/dev/sdd1 of=superblock bs=4k skip=183142976 count=1 

Вот они, последние 128К. Прописываю их в конец образа, перезагружаюсь со здоровым диском, и массив собрался!
Осталась простая команда и:

#mount -o ro /dev/md11 /srv/old/
mount: wrong fs type, bad option, bad superblock on /dev/md11,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Ну вот это уже как-то совсем обидно. Последний раз на сервере массив собирался и ext3 монтировалась. Вывод dumpe2fs подозрений не вызывает, статус раздела clean, адреса альтернативных суперблоков видны, но с ними почему-то тоже не монтируется. Надо бы ее полечить, но в таком виде и с половиной данных без бэкапа лечить нельзя. Эх, придется перекинуть еще полтора терабайта. Конечно, по-хорошему надо бы сделать образ с теперь уже условно рабочего диска с помощью ddrescue, но все это уже сильно надоело и поэтому делаю так:

dd if=/dev/md11 of=ext3 bs=16M conv=noerror,sync

И спать, а наутро пробую:

losetup /dev/loop2 ext3 
mount -o ro /dev/loop2 /srv/old/

И оно монтируется! Структура каталогов на первый взгляд не изменилась, а файлы, от которых у меня есть хэши, прочитались без ошибок. На восстановленном разделе свободно всего 20 ГБ, поэтому его loop-файл получил заслуженный атрибут:

chattr +i ext3

и запись в fstab:

/srv/ext3	/srv/old	ext3		ro,loop	0	0

В качестве заключения дочитавшему до сюда рекомендую:

• настроить автоматическое резервное копирование важных и не очень данных,
• периодически просматривать отчеты SMART,
• использовать для восстановления устройство USB to SATA, или аналогичное для вашего диска,
• относиться к любому диску, с которого нужно снять образ, как к умирающему и использовать GNU ddrescue,
• помнить, что если дело дойдет до восстановления действительно важных данных, то такого везения точно не будет.