外部SATA / IDEハードドライブにバックアップするためにvdmfecを使用する価値はありますか？

バックアップにエラー修正コード（ECC）を追加することは確かに良いことです。データの重複の形で堅牢性を得るには、追加のスペースを犠牲にする必要があります。

vdmfec良い小さなツールのように見えます。デフォルトでは、ブロックサイズはb = 1024バイトと仮定し、すべてのK = 14入力ブロックに対してN = 18ブロックを書き込みます。つまり、デフォルトでは、出力サイズは14ブロックごとにNK = 4ブロックずつ増加し、サイズは約29％増加します。パラメータKとNを使用するとある程度冗長性が得られますが、ほとんどの場合、デフォルト値は問題ありません。

しかし、知っておくべきいくつかの潜在的な問題があります。まず、マニュアルページによると、次のようになります。

N、K、およびブロックサイズパラメータは出力に書き込まれません。デコーダを実行するときは、同じパラメータを指定する必要があります。 （実際、デコーダは無効なK値を明示的に検出できますが、誤ったブロックサイズまたはN値は不良ブロックとデコード失敗を引き起こします。）

したがって、各バックアップに使用される特定のパラメータをメモしてください。常にデフォルト値を使用しても、新しいバージョンのプログラムではデフォルト値が変更される可能性があるため、これらの値を明示的に記録することをお勧めします。

第二に、マニュアルページには次のように記載されています。

デコーダは、検索できないメディア（パイプなど）からデータを読み取ることができますが、バッファアンダーランを検出できず、エラーが発生します。また、パイプから読み込むときは、ファイル全体を読み取る必要があります。 NブロックのうちK個の良好なブロックのみを読み取る必要があるため、検索可能なストリームからデータを読み取る方が高速です。

これはvdmfec、バックアップを作成するときにコマンドパイプラインの末尾にバックアップを配置するのが最善かつ最も安全であることを意味します。たとえば、

tar -cf - /data | gzip | vdmfec > /backups/data.tgz.vdm

vdmfecバックアップ時にエンコードを最後に行うことで、復元時にvdmfec検索不可能なパイプではなく検索可能なファイルにデコーダを使用できるため、パイプを使用するときに発生する可能性のある問題を回避できます。たとえば、

vdmfec_decode /backups/data.tgz.vdm | zcat | tar -xf -

全体的に、これはvdmfecバックアップをより強力にし、メディアパフォーマンスの低下によるエラーによるデータの損失を防ぐ優れたツールであると言いたいと思います。今日のハードドライブは、増え続けるマルチテラバイト容量を達成するためにますます高いビット密度を使用しているので、安全のためにバックアップに余分な冗長性を追加することは確かに価値があると思います。

最後に、同様の機能を持つ別のツールvdmfecはpar2（マニュアルページ）しかし、完全に異なる動作します。ファイルをアーカイブするpar2必要がある場合は、splitこのツールがより適切なツールかもしれません。これは、par2いくつかの小さなファイルに分割された大容量ファイル（USENETバイナリグループに公開するためなど）にECCを追加するために開発されたためです。