LINUX.ORG.RU
ФорумAdmin

Накрылся HDD c Linux


0

0

Ситуация: стоял CentOS 5.4 на 2 HDD WD4000AAKS. Корневая ФС находится на единственном разделе ext3 1 диска, остальные разделы находятся на программном RAID1 (зеркало) на 1 и 2 HDD.
При загрузке ОС пишет примерно следующее (скопировал из чужой темы, но суть та же):

/:UNEXPECTED INCONSYSTENCY; RUN fsck MANUALLY.

(i.e., without -a or -p options)



***An error occurred during the file system check.

***Dropping you to a shell; the system will reboot

***When you leave the shell.



Give root password for maintenance

(or type Control-D for normal startup):

(Repair filesystem) 1 # //а


Запускаю fsck.

Pass 1:Checking inodes, blocks, and sizes

Error reading block 3408065 (Attempt to read block from filesystem resulted in short >read) while doing inode scan Ignore error?


Судя по всему, накрылся 1 HDD.
Вопросы:
1)Как скопировать содержимое SRAID с HDD2?
2)Как хотя бы частично восстановить корневую ФС для переноса сохранившихся файлов на новый CentOS?
3)Имеет ли смысл пробовать восстановить корневую ФС полностью и какую диагностику провести, чтобы это понять?

Заранее благодарен за любую помощь


Ответ на: комментарий от macumazan

а что это? чем отличается от fsck?

mvi
() автор топика

Дополнение: Проверил поверхность Викторией, которая показала 30 дефектов UNCR.

Вопрос: есть ли смысл пытаться полностью восстановить файловую систему (тогда как это лучше сделать) или придется заново устанавливать ОС и переносить отдельные файлы? Вообще, при появлении UNCR дефекта файл, который на него попал безвозвратно поврежден или есть вероятность его полностью восстановить?

mvi
() автор топика
Ответ на: комментарий от mvi

>Вообще, при появлении UNCR дефекта файл, который на него попал безвозвратно поврежден или есть вероятность его полностью восстановить?

512 байт (минимум) ушло на каждый UNCR; восстановить - утилями, умеющими вычитывать через ReadLong ATA комманды, при этом ессно восстановится часть из потерянных 512 байт (насколько большая часть - зависит и от софтины, вернее - ее алгоритма вычитки и знакомства с механизмом рассчета CRC конкретного семейства, и от состояния собссно инфы в секторе) - только незадача в том, что таких утилит особо в свободном доступе нет. Насколько это критично для файла - вам виднее. Проще всего - как уже упомянули, fsck с проверкой поверхности и маркировкой бэдблоков; ну или перед этим - в виктории/MHDD римэп... А уже по факту - бороться с возникшими глюками, или просить менеджер пакетов, дабы он проверил состояние файлов (умеет ли менеджер пакетов вашего дистра такое - вам виднее).

NiTr0 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.