Я представил себе потенциально неисправный жесткий диск емкостью 1 ТБ, содержащий фактические данные объемом около 270 ГБ, используя ddrescue, в работающей системе Lubuntu. Восстановление завершено на 99,9%, есть только область размером 52 КБ, которая не читается рядом с отметкой 300 МБ, но в SMART нет «отложенных» или «перераспределенных» секторов. Первый вопрос: как это возможно? Может ли это быть доброкачественным случаем «логических» поврежденных секторов, то есть секторов, которые физически все еще работают, но находятся в несогласованном состоянии, что приводит к неудаче проверки CRC, и могут ли они быть «надежно» исправлены и надежно просто перезаписаны? Я провел короткую самопроверку, которая была «завершена с ошибкой чтения». Могу ли я по-прежнему доверять данным SMART на 100% и быть уверенным, что если они не сообщат о плохих секторах, на физическом уровне их действительно не будет?

Затем у меня есть 3 запасных диска, которые я мог бы использовать для передачи восстановленных данных владельцу, который использует компьютер MacBook: диск емкостью 320 ГБ в USB2, 500 ГБ в USB3, 1 ТБ в USB3. Исходный диск отформатирован в HFS+. Существует ли безопасный и удобный способ записи этого образа размером 1 ТБ, который действительно занимает только около 270 ГБ (как он был создан в разреженном режиме с помощью ключа -S ddrescue), непосредственно на диск меньшей емкости с помощью бесплатного инструмента для Linux или Windows, в таким образом, что восстановленный жесткий диск легко читается, с согласованной таблицей разделов? (У меня нет опыта работы со схемами разбиения и форматирования Apple.) Или мне лучше создать раздел HFS+ - с помощью какого инструмента, поскольку, по-видимому, GParter не может с этим справиться, - и копировать файлы и папки? Но в этом случае будут ли метки времени и другие метаданные автоматически сохраняться? Или я должен был бы использовать определенный метод, чтобы убедиться в этом? Может ли команда Linux, например «cp», копировать файлы между разделами HFS+ и сохранять все атрибуты, характерные для этой файловой системы?

Благодарю.

1 ответ1

0

Поэтому я сделал то, что сказала мне моя интуиция: я попытался переписать только крошечную нечитаемую область с помощью этой команды ddrescue (это можно сделать с помощью более простого инструмента dd, но я менее знаком с ним):

lubuntu@lubuntu:~$ sudo ddrescue -o 312881152 -s 53248 -f /dev/zero /dev/sdb /media/lubuntu/354E48E260FCFD84/dev_zero_dev_sdb.log

[Note : the -f switch is necessary here since there is natively a protection preventing ddrescue from writing directly to a physical device.]

И это сработало: в качестве проверки я повторно создал первый ГБ, и на этот раз ошибки не было (я пробовал эту частичную обработку изображений перед запуском вышеуказанной команды, и тогда область ошибок все еще была там, с точно таким же местоположением и размером Я также заметил, что он был пропущен сразу же, без замедления, в отличие от того, что обычно происходит, когда есть реальный «физический» плохой сектор, и он замедляется или зависает на несколько секунд перед пропуском); «короткая самопроверка» теперь завершается без ошибок.

До этого я пробовал некоторые инструменты Windows: сканирование на чтение с Hard Disk Sentinel заставляло его зависать на неопределенное время, мне приходилось выключать диск; аналогично, попытка получить доступ к проблемной области с помощью WinHex заставила его зависнуть, пока диск не был выключен.

Итак, я прав, что это был случай «логических» поврежденных секторов, и что диск физически исправен и безопасен для повторного использования, так как в SMART ни разу не отображался «ожидающий» или «перераспределенный» сектор процесса? Какова вероятная причина этого, возможно, операция записи, прерванная неправильным завершением работы? Является ли это распространенной проблемой, и обычно ли это делает диск неработоспособным, когда он влияет на системный файл?

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .