btrfsファイルシステム上のファイルを安全に削除します
場合によっては、ファイルシステム内のファイルを削除し、ファイルが本当になくなったことを確認する必要があります。たとえば、機密性の高いパスワードを含むファイルは、ディスクから完全にワイプする必要があります。
典型的なファイルシステムで単純なrmを発行すると、ファイルのiノード（「ポインタ」）が削除されますが、 削除されません 物理ディスク内のファイルの内容-これらは残りますファイルシステムに空き領域が必要なときに上書きされるまでそこにあります。
多くのファイルシステムでは、 shred program を使用すると、このような安全な削除が可能になります。ただし、btrfsなどのCoWファイルシステムでは、 この方法は役に立ちません です。ファイルがボリュームスナップショットに存在する可能性があるという事実によって、問題はさらに悪化します。
Btrfsファイルシステムでa fileを安全に削除する方法はありますか？ （すべてのボリューム上の）すべてのポインターを削除し、 空き領域をゼロで埋める で十分ですか？
安全な削除は、どのファイルシステムでも難しい命題です。ファイルシステムが非常に特殊で、ファイルのほかのコピーがないことを保証しない限り、デバイスのすべての空き領域をクリアする必要があります。コピーオンライトファイルシステムではファイルの多くのビットが見つかる可能性が高くなりますが、実際にはさらに多くの「静的」ファイルシステムではこの保証はありません。多くのファイルが編集されるため、以前のバージョンのビットはファイルが横になっています。
ゼロでの消去は、ランダムなバイトでの消去と同じように優れており、複数のパスを必要としないことに注意してください。ゼロで消去すると、1980年代のハードディスクテクノロジーを使用して、ラボの条件で部分的に回復できる残余データが残りました。これは現在は適用されません。参照 ハードドライブにゼロ（またはランダムデータ）を書き込むのが、1回だけ行うよりも複数回行う方が良いのはなぜですか？
ディスク上のすべてを暗号化することにより、クリアテキストの機密データを取り除くことができます。そのファイルシステムに ecryptfs ボリュームを設定し、すべての（機密）ファイルをそこに移動します。次に、ファイルシステムの未使用のスペースをすべて上書きします。ファイルシステムにcat /dev/zero >zeroを入力すると、そのほとんどを消去できます。不完全なブロック（ファイルの最後のチャンクを含み、その後にガベージが続くブロック（機密ファイルの残り物である可能性があります））にいくつかの情報が残っている可能性があります。不完全なブロックがないことを確認するには、ファイルシステム上のすべてをecryptfsに移動します（ecryptfsのファイルは、少なくともブロックが4kBである一般的な設定で、ブロック全体を使用します）。これをすべてのボリュームに適用し、プレーンテキストの機密データを含むすべてのスナップショットを消去してください。
まだジャーナルに情報が残っている可能性があります。私はそれをスクラブする方法を知りません。
SSDでは、ブロックの再割り当てが原因で、通常のソフトウェア手段では読み取ることができないデータが残っている可能性がありますが、ファームウェアのハッキングまたは物理的なアクセスによって回復できます。そこで唯一の解決策は、SSDを完全に消去することです。
うーん、btrfsは通常のすべての細断方法を無効にしているようです...
nodatacowというマウントオプションがありますが、既存のファイルには影響しないようです。- すでにディスク上に適切なファイルがあるので、この btrfs FAQ エントリは役に立ちません。
- 次に、
debugfsがあります。これはextファイルシステム専用ですが、動作する可能性のある patch があります。これを使用して、影響を受けるブロックアドレスを見つけ、/ dev/sdXYに直接上書きすることができます。しかし、それは非常に危険であり、機能しない可能性があります（特に、ファイルのスナップショットが多い場合） - 特定のスナップショットまたはファイル全体を変更（または細断処理）できるようにするbtrfsパッチを作成する
（本当に本当に機密性の高いデータの）最もクリーンな試みは、次のようになります。
- 別のディスクを購入する（最初のディスクに影響を受けるパーティションのコピー用の十分な空き容量がない場合）
- フルディスク暗号化とその上のファイルシステムをセットアップする
- すべてをディスクaからbにコピーする
- システムbを起動し、ディスク全体を細断します...
これは最も安価な方法ではないかもしれませんが、今日の低いストレージコストと他のオプションで発生する問題を考慮すると、実際には最も安い方法（労働時間の観点）かもしれません。