Копирование файлов (cp и rsync) на внешний HDD вызывает ошибки ввода-вывода и потерю данных на целевом устройстве.

Я пытаюсь сделать резервное копирование данных (230 ГБ, 160 000 файлов) по USB 3.0 на новый внешний жесткий диск Seagate Expansion Portable объёмом 4 ТБ, отформатированный в NTFS. Я использую Ubuntu 18.04.3 LTS.

Сначала я попробовал использовать простую команду cp в терминале, но после копирования всего лишь нескольких процентов процесс копирования начал заикаться и замедлился. Спустя некоторое время диск стал неотвечать. Повторная установка диска не сработала. Я попытался подключить диск к другому компьютеру, но сначала не смог его смонтировать, а затем после нескольких попыток он смонтировался, но чтение и запись были очень медленными.

Когда cp начинает давать сбой, я получаю следующие ошибки в dmesg (все эти сообщения повторяются несколько раз, но с разными номерами):

[67598.098118] sd 4:0:0:0: [sdb] tag#18 uas_zap_pending 0 uas-tag 19 inflight: CMD 
[67598.098122] sd 4:0:0:0: [sdb] tag#18 CDB: Write(16) 8a 00 00 00 00 01 1c 75 24 18 00 00 04 00 00 00
[67598.225621] usb 1-9: reset high-speed USB device number 5 using xhci_hcd
[67598.378202] scsi host4: uas_eh_device_reset_handler success
[67598.378466] sd 4:0:0:0: [sdb] tag#14 FAILED Result: hostbyte=DID_RESET driverbyte=DRIVER_OK
[67598.378468] sd 4:0:0:0: [sdb] tag#14 CDB: Write(16) 8a 00 00 00 00 01 1c 74 d0 18 00 00 04 00 00 00
[67598.378470] blk_update_request: I/O error, dev sdb, sector 4772384792 op 0x1:(WRITE) flags 0x104000 phys_seg 128 prio class 0
[67598.378473] buffer_io_error: 246 callbacks suppressed
[67598.378474] Buffer I/O error on dev sdb2, logical block 596515075, lost async page write
[67635.212662] scsi host4: uas_eh_device_reset_handler start
[67635.213657] sd 4:0:0:0: [sdb] tag#28 uas_zap_pending 0 uas-tag 10 inflight: CMD 
[67635.213658] sd 4:0:0:0: [sdb] tag#28 CDB: Write(16) 8a 00 00 00 00 01 1c 75 e8 18 00 00 04 00 00 00
[67635.340988] usb 1-9: reset high-speed USB device number 5 using xhci_hcd
[67635.490335] scsi host4: uas_eh_device_reset_handler success

Я оставил диск на неделю, а затем выполнил SMART-сканирование с помощью средства Seagate Bootable Tool, которое не показало никаких проблем.

Таким образом, я снова попытался скопировать данные. Диск теперь правильно монтировался, и я мог читать и записывать без проблем, так что я запустил команду rsync. Сначала я выполнил

rsync -avh source dest

Это работало, хоть и медленно, для около 20% данных, затем начались заикания, и я остановил передачу. Я перезапустил передачу, используя

rsync -avhW source dest --inplace

, чтобы попытаться ускорить её. Она шла отлично, намного быстрее, чем в первой попытке, но через несколько минут я получил ошибки:

rsync: recv_generator: failed to stat "..." : Input/output error (5)
rsync: write failed on "...": Input/output error (5)
rsync error: error in file IO (code 11) at receiver.c(393) [receiver=3.1.2]

В dmesg я вижу следующее:

[ 6772.890553] buffer_io_error: 1092735 callbacks suppressed
[ 6772.890556] Buffer I/O error on dev sdb2, logical block 874428, async page read

Как только это произошло, диск стал неотвечать. Спустя несколько минут я смог смонтировать его снова, и проверив папку, в которую я копировал данные, она оказалась совершенно пустой, включая файлы, которые были правильно скопированы во время моей первой попытки rsync. Я не пытался восстановить какие-либо данные, чтобы проверить, остались ли данные нетронутыми, я предполагаю, что повреждена только таблица файлов.

Файлы, которые копировались в момент сбоя, были типа .mat.gz, порядка 1 МБ каждый.

Как побочный комментарий, старый внешний жесткий диск Seagate недавно сломался, когда я копировал небольшие объёмы данных с него на этот компьютер (знаменитый клик смерти…), который также был моим первым жестким диском, который сломался.

Я не знаю, что с этим делать, проблема ли в том, как я копирую данные (может ли копирование данных повредить диски?), проблема ли в аппаратном обеспечении (компьютер, HDD, USB-SATA конвертер …) или это связано с Ubuntu… Обычно я использую Manjaro и никогда не сталкивался с такими проблемами.

Спасибо за всю вашу помощь.

Теперь я решил проблему. Я форматировал диск в ext4, а затем использовал команду

rsync -avhW source dest --inplace --exclude=".*/"

, где

-a — для архивирования, что сохраняет права собственности, разрешения и т.д.
-v — для подробного вывода, чтобы видеть, что происходит
-h — для человеко-читаемого формата, чтобы скорость передачи и размеры файлов было легче читать
-W — для копирования только целых файлов, без алгоритма delta-xfer, который должен снизить нагрузку на ЦП
--inplace говорит rsync не создавать временную копию файла, который должен быть передан, а немедленно копировать на место назначения. Это должно ускорить процесс.
--exclude=".*/" предназначено для исключения всех скрытых папок

Средняя скорость передачи для 392 ГБ составила 81.3 МБ/с, что намного быстрее, чем я добился до форматирования диска.

dmesg на этот раз был без ошибок.

Обратите внимание, что я не пытался создать новый раздел NTFS на диске, чтобы проверить, является ли проблема связанной с конкретным NTFS-разделом с завода, или же именно NTFS вызывает проблемы. Это, к сожалению, означает, что у меня нет полного ответа на то, в чём заключалась проблема. Я также не пытался увеличить пороги времени ожидания, но учитывая гораздо более высокую скорость передачи данных на этот раз, я бы сказал, что увеличение порогов времени ожидания в лучшем случае было бы обходным решением, а не исправлением.

Не совсем ответ, а скорее предположение: это может быть связано с индексаторами файлов.

Это случалось со мной с различными файловыми системами (exFAT, NTFS, ext4), разными типами внешних дисков разных брендов (WD HDD, Seagate HDD, SanDisk SSD) и ОС (Ubuntu, Kubuntu, MacOS). Даже если я отформатирую внешний диск и начну всё заново, то всё равно происходит то же самое. Однако я заметил, что проблема волшебным образом исчезает, когда индексаторы файлов выключены. Для Kubuntu это Baloo, а для MacOS это MDS.