Почему VMware прекращает запись данных с использованием ddrescue?

Я использую VMware Workstation 15 Pro для запуска виртуальной машины, содержащей довольно актуальный аварийный Linux, для восстановления данных с неработающего USB-жесткого диска с помощью ddrescue. Это начинает нормально работать для некоторых ГБ данных, затем ddrescue замедляется из-за повреждения диска, в конечном итоге пропускает некоторые блоки и в зависимости от того, откуда читать, начинает читать снова с более высокой пропускной способностью. Такое поведение, как и ожидалось, в конце концов. Проблема в том, что в какой-то момент VMware просто перестает записывать восстановленные данные:

В то время как ddrescue утверждает, что спасает много ГБ данных, целевое устройство в какой-то момент больше не увеличивается этими данными. Вместо этого последней записанной метке времени может быть несколько дней или, даже если она увеличивается во время перезапуска ВМ, она увеличивается только один раз и никогда больше. Не имеет значения, перезапускаю ли я только ddrescue или всю ВМ или даже всю мою систему, кажется, что никакие данные больше никогда не добавляются на целевой диск. Кроме того, это не совсем одна и всегда одна и та же точка, в которой это происходит, но это произошло уже после ~ 150 ГБ спасенных данных, ~ 500, ~ 385 и т. Д. Конечно, я не вижу каких-либо конкретных ошибок записи или подобных в VMwares логи или те самого хоста. Целевое устройство разрежено, поэтому я подумал, что все спасенные данные могут быть равны нулю, но это не так, Я проверил, используя xxd и входную позицию ddrescue. Это были не все 0, ddrescued утверждал, что спасает данные, и ничего не было записано в цель. Это не объяснило бы разный размер целевого устройства, когда проблема возникала и в прошлом.

Моя установка немного особенная:

Хост - Windows 10, а сломанный USB-жесткий диск содержит NTFS, которая больше не может быть прочитана различными версиями Windows. Вот почему я пробую Linux-VM и ddrescue, потому что монтирование в Linux как NTFS также дает сбой. Поскольку сломанный USB-HDD довольно большой, я создал спасательную виртуальную машину на другом, большем USB-HDD. Эти виртуальные машины содержат один VMDK для / и другой VMDK для получения данных с неисправного USB-HDD. И, как уже было сказано, это работает в целом, виртуальная машина работает и начинает восстанавливать данные, но в какой-то момент прекращает их запись.

Интересно то, что сломанный USB-HDD все еще читается, что видно по мигающему светодиоду и выходу ddrescue, а целевой USB, содержащий виртуальную машину, также используется, например, для хранения карты ddrescue. Поскольку это еще один VMDK, я вижу изменения в этом файле карты, отметка времени для этого VMDK, его размер со временем увеличиваются и т. Д. Так что VMDK работает. Кроме того, у меня есть ощущение, что если ddrescue спасает данные, мигающий светодиод VM-USB-HDD часто мигает, слишком сильно только для файла карты ddrescue, как если бы записывались ГБ данных. Но они просто никогда не достигают целевой VMDK по какой-то причине. Я даже уже использовал Process Monitor для Windows, чтобы увидеть, записывается ли целевой VMDK, а после возникновения проблемы - нет. Он только иногда читается, но не ГБ данных.

Я прилагаю несколько скриншотов, которые документируют два запуска ddrescue: Первый - это то, где я остановился вчера вечером, после чего целевой VMDK уже не был записан в течение нескольких часов. Его размер составляет ~ 385 ГБ данных, а ddrescue утверждает, что спас ~ 580 ГБ. Второй - с сегодняшнего дня, когда ddrescue заявил, что спас дополнительные ~ 15 ГБ данных, но размер целевого VMDK остается таким же, как и раньше. Третий показывает позицию ввода второго снимка экрана, которая не является всеми 0, поэтому, по крайней мере, некоторые байты данных должны были быть записаны в целевой VMDK.

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

Спасибо!

Logfile 1 Logfile 2