Netuším, jak přesně se chová rsync při kopírování z toho konkrétního zařízení. To že to neskončí chybou a kopíruje nuly rozhodně není košér. Nezměnilo by tam přidání parametru timeout, kdy mu přidáš nějaký časový limit - nevím vteřina - pro získání konkrétního souboru? Pokud při tom read requestu to blokové zařízení nějak váhá, tak by to možná mohlo něco hodit.
Jinak ještě mimoběžně. jediné, co mi trochu vysvětluje, proč by mělo projít kopírování, ale ddrescue selže takhle brzy, je to, že si při sekvenčním kopírování všech bloků FS hrábne na nějakou oblast, kde sice nejsou reálně není žádné alokované soubory, ale SSDčko se z toho přístupu už nevzbelhá.
Já už párkrát používal ddrescue dohromady s partclone - primárně aby netrávil čas zbytečnými opakováními při čtení z oblastí, kde nejsou užitečná data. Pokud je čitelná alokační tabulka, tak partclone vytvoří mapu alokovaných oblastí, a ddrescue pak ignoruje zbytek.
S exfatem a omezením rychlosti čtení u ddrescue by to mohlo být něco jako..
partclone.exfat --domain -s /dev/partition -o /tmp/partition.domain
ddrescue --max-read-rate=$((1024*1024)) --domain-mapfile=/tmp/partition.domain /dev/partition /tmp/image
mount -o loop /tmp/image /mnt/tmp
I když vím, že jestli už máš zachráněno větší část dat rsyncem, tak to možná nebude dávat úplně smysl, krom zkoušky s více možnostmi čtení a chování při chybě, co nabízí ddrescue oproti rsyncu.
Další možnost s ddrescue je - udělat si seznam zbývajících souborů ke zkopírování (třeba rsyncem s dry run), pak případně vytvořit cílovou adresářovou strukturu a finálně to protáhnout smyčkou ve skriptu nebo xargs, co bude pro každé kopírování souboru volat ddrescue s parametry.