Невозможно записать изображение ddrescue (d) на HD, в итоге остается пустым
361
John D'Eau
У меня есть файл образа неисправного жесткого диска, созданный с помощью ddrescue в Linux. Жесткий диск 750 ГБ, если я правильно помню, не удалось сохранить только около 30 МБ. У меня есть другие неисправные жесткие диски, и я не могу вспомнить, принадлежал ли он моему компьютеру с Windows или Linux.
Я пытаюсь записать изображение обратно на 2 ТБ HD. Независимо от того, отформатирую ли я этот HD-файл как NTFS или EXT и запишу изображение на этот новый HD-файл, после того, как это будет сделано, оно снова отобразится как неформатированное и пустое. Я читал, что мы должны использовать инструменты для исправления ошибок для изображений, прежде чем писать их обратно. Поэтому я попытался использовать fsck и ntfsfix, но никто не может идентифицировать изображение и исправить его.
Если ddrescue удалось так много сэкономить на этом неисправном HD, почему инструменты не могут исправить ошибки и почему они не могут быть записаны обратно? Мне удалось успешно записать еще один неисправный 160 ГБ HD, поэтому я не знаю, почему этот 750 ГБ не будет работать.
Редактировать, чтобы написать обратно изображение, которое я использую:
sudo ddrescue -f seagate750gb.img / dev / sdb restore.log
GPT fdisk (gdisk) version 0.8.8 Partition table scan: MBR: MBR only BSD: not present APM: not present GPT: not present *************************************************************** Found invalid GPT and valid MBR; converting MBR to GPT format in memory. *************************************************************** Disk seagate750gb.img: 1465149168 sectors, 698.6 GiB Logical sector size: 512 bytes Disk identifier (GUID): 2891CCD9-92FB-4380-AB03-801E0E4F90CC Partition table holds up to 128 entries First usable sector is 34, last usable sector is 1465149134 Partitions will be aligned on 2048-sector boundaries Total free space is 1465149101 sectors (698.6 GiB) Number Start (sector) End (sector) Size Code Name
sudo gdisk -l / dev / sdb
(это мой 2TB HD, после того как на него было записано изображение)
GPT fdisk (gdisk) version 0.8.8 Partition table scan: MBR: MBR only BSD: not present APM: not present GPT: not present *************************************************************** Found invalid GPT and valid MBR; converting MBR to GPT format in memory. *************************************************************** Disk /dev/sdb: 3907029168 sectors, 1.8 TiB Logical sector size: 512 bytes Disk identifier (GUID): 59784077-576E-4CC1-918D-773D10916B46 Partition table holds up to 128 entries First usable sector is 34, last usable sector is 3907029134 Partitions will be aligned on 2048-sector boundaries Total free space is 3907029101 sectors (1.8 TiB) Number Start (sector) End (sector) Size Code Name
У вас все еще есть журнал `ddrescue` от этой операции? Если это так, пожалуйста, опубликуйте вывод `head -n 16 the_logfile`. Какую команду вы используете, чтобы написать изображение обратно? Что выводится из `файла the_image_file`? Что выводит `gdisk -l the_image_file`? Что `gdisk -l / dev / sdX` говорит о размере логического сектора вашего жесткого диска объемом 2 ТБ? Пожалуйста, не отвечайте на эти вопросы в комментариях, [редактируйте] свой вопрос и добавляйте туда информацию.
Kamil Maciorowski 6 лет назад
0
1 ответ на вопрос
0
agc
Прежде чем спекулировать, проверьте несколько вещей:
Убедитесь, что образ диска действительно содержит данные. Попробуйте что-то вроде:
lzop < disk.img | wc -c - disk.img
Это займет несколько минут для подсчета символов на изображении и несколько сжатого lzopпотока изображения. Если на изображении все нули, lzopчисло будет относительно небольшим.
Если это lzopчисло составляет не менее 10% от исходного размера изображения, в disk.img есть некоторые данные .
Если кажется, что есть данные, посмотрите, что об этом говорят несколько стандартных утилит:
file disk.img
... должен немного рассказать о том, что там. Если это таблица разделов, попробуйте: