データ復旧後に破損したファイルを識別/修復するには？

だからext4パーティションをマウントしましたが、/home失敗し始めました。 HDDの問題であることを確認したら、使用を中止し、新しいUSBスティックを購入してから、動作しているUSBスティックから新しいUSBスティックをフォーマットしてくださいddrescue。最後にfsck残ったFSの問題を解決してください。

$ sudo ddrescue -f -n /dev/sda1 /dev/sdb1 /root/ddrescue.log
# There were very few bad areas reported (my bad not saving the log file)...
$ sudo fsck -f /dev/sdb1

新しいドライブを取り付けた後、すべてが「正常」に戻りました。ほとんどのアプリケーションは完全に実行されましたが、いくつかの問題が発生しました。特定の設定ファイルに関するこれらの問題を追跡してみると、これらのファイルが「破損」していることを確認でき、次の方法で確認できます。

$ hexdump -C ok.conf 
00000000  5b 63 65 72 74 5d 0a 63  61 5f 66 69 6c 65 3d 0a  |[cert].ca_file=.|
00000010  74 72 75 73 74 65 64 5f  63 65 72 74 3d 65 38 63  |trusted_cert=e8c|
# Truncating output...
$ file ok.conf
ok.conf: ASCII text

$ hexdump -C corrupt.conf 
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000231
# This output is not truncated.
$ file corrupt.conf 
corrupt.conf: data

破損したファイルの場合、ファイルサイズも意味がありません。

$ ls -l *.conf
-rw-rw-r-- 1 user user 561 sep 30 08:36 corrupt.conf
-rw-rw-r-- 1 user user 561 oct  7 09:21 ok.conf

質問は次のとおりです。修復後に破損したファイルを識別する方法はありますか？この問題を解決する方法はありますか？

ノート：すべてのデータを含む元のドライブがまだ残っており、新しいドライブが正常であることを確認できます。さらに読んだ後、一部の人は、読み取りエラーが発生した場合は、2回目の実行でddrescue再試行オプション（）を使用して再試行することを提案していますが、まだ試していないことと-r3違いがあるかどうかわかりません。たぶん誰かがこれについても明らかにすることができます。