Ответы:
ddrescue можно возобновить, но для этого требуется файл журнала. Файл журнала будет записывать прогресс, достигнутый ddrescue, и перезапуск ddrescue прочитает файл журнала и начнет с того места, где он остановился.
Файл журнала будет третьим параметром:
ddrescue /dev/sdd1 ./bye1t.dd_rescue.image ~/sdd1.log
Если вы уже запустили ddrescue без файла журнала и отменили его, при следующем запуске ddrescue он запустится в начале, так как не имеет записи о том, что уже было восстановлено.
Даже если вы забыли указать лог-файл, может быть надежда:
Таким образом, вы не читали учебник и запустили ddrescue без лог-файла. Теперь, два дня спустя, ваш компьютер вышел из строя, и вы не можете знать, сколько данных удалось сохранить ddrescue. И что еще хуже, вы не можете возобновить спасение; Вы должны перезапустить его с самого начала.
Или, возможно, вы начали копировать диск с dd conv=noerror,sync
и теперь находитесь в той же ситуации, как описано выше. В этом случае обратите внимание, что вы не можете использовать копию, созданную dd, если она не была вызвана с sync
аргументом преобразования.
Не отчаивайтесь (пока). В некоторых случаях Ddrescue может сгенерировать приблизительный файл журнала из входного файла и (частичной) копии, который почти так же хорош, как и точный файл журнала. Это можно сделать, просто предполагая, что сектора, содержащие все нули, не были спасены.
Однако, если местом назначения копии был диск или раздел (или существующий обычный файл и усечение не запрашивались), скорее всего вам потребуется перезапустить ddrescue с самого начала. (На этот раз с лог-файлом, конечно). Причина в том, что в накопителе могут присутствовать старые данные, которые еще не были перезаписаны, и поэтому могут быть не проверенными, но ненулевыми.
Например, если вы впервые попробовали одну из этих команд:
ddrescue infile outfile
или
dd if=infile of=outfile conv=noerror,sync
вы можете создать приблизительный лог-файл с помощью этой команды:
ddrescue --generate-mode infile outfile logfile
Как уже говорили другие, вы всегда должны указывать файл журнала в качестве третьего параметра, который позволит возобновить. Так как вы этого не сделали, это не поможет вам здесь. Если вы приблизительно знаете , что указать процесс должен, вы можете использовать --input-position
и --output-position
параметры , чтобы начать с этой точки (убедитесь , чтобы установить оба эти параметры в том же значении, в противном случае выход будет поврежден).
Поскольку вы не указали файл журнала в качестве третьего параметра, возобновление не может быть выполнено автоматически. Вы можете создать файл журнала вручную, если вы знаете уже спасенные сектора, синтаксис прост. Просто запустите другое фиктивное восстановление в другой файл, указав журнал, и позвольте ему читать различные области. Затем отредактируйте журнал, чтобы представить уже спасенные области в вашем первом файле. Теперь повторите вашу предыдущую команду, но в качестве третьего параметра укажите имя файла журнала. Затем ddrescue возобновит работу с первым непроверенным сектором.
Согласно https://wiki.archlinux.org/index.php/Disk_cloning кажется, что с conv=noerror,sync
коммутатором dd
фактически добавляет нули в конце блока, а не точно, где произошли ошибки чтения. Это противоречит информации в ответе Майлза Вольбе от 2013-08-29.
Например, если правильная последовательность есть 198123283
и в середине есть ошибка чтения, она будет писать 198283000
, а не 198000283
.
Таким образом, в случае, если были действительно ошибки чтения, предложенный метод не будет точным - будут области, которые были бы читабельными, которые в конечном итоге будут заполнены нулями, но будут считаться «спасенными».
Кстати, рекомендуется начинать такую попытку восстановления, заполняя целевой диск нулями (или, по крайней мере, свободным пространством, что можно сделать, например, с помощью WinHex).