解決策 1:
<オール>shred を使用して、できるだけ多くのファイルを削除します。 または単なる rm .cat /dev/urandom > /bigfile を使用して、スペース全体に大きなランダムなファイルを作成します shred で消去 （非常にしない限り、実行する反復回数はあなた次第です shred /bigfile -n 0 -z を使用するだけの機密情報があります 新しくランダム化されたスペースをゼロにします。ただし、大きな注意点が 1 つあります。現時点では、データが存在する物理メディア上のスペースにのみ影響を与えています。ホストがデータが存在する LVM ボリューム/グループを再編成することを決定したため、または負荷再分散の一環として VM がホストからホストに移動され、ホストにバックアップがある可能性があるため、昨日完全に別の場所にあった可能性があります。標準の災害復旧計画の一部として、いくつかの場所で (ホスト マシンが壊滅的に死亡した場合、最後の既知の正常なバックアップからマシンを復元できます)。
データが読み取り不能であることを保証する唯一の真の方法は、強力な暗号化ファイルシステム (または強力な暗号化ブロックデバイス上の古いファイルシステム) を使用し、暗号化キーを適切に安全に保つ (つまり、暗号化されたファイルの近くに保存しない) ことによって、最初から読み取れないようにすることです。コンテンツ自体）。残念ながら、タイム マシンにアクセスできない限り、現在の位置からこれを行うことはできません。データは既に暗号化されていないためです (他の場所でも可能です)。
解決策 2:
Linode のスタッフに彼らの推奨事項を尋ねましたか?私の経験では、彼らは非常に反応が良く、最も正直で率直な反応を示します。
Linode は、すべてのアカウントで Finnix レスキュー イメージを利用できるようにします。そのイメージに LPM のディスク イメージへのアクセスを許可し、Finnix を起動してから、他の回答で概説されている手順を使用して、ファイル システムを安全にワイプできます。
解決策 3:
まず、すべての ext3 パーティションを ext2 としてマウントします。これによりジャーナルの使用が無効になり、物事を適切に破壊できるようになります。これは /etc/fstab を編集することで実行できます ext3 のすべてのインスタンスを変更します ext2まで そして再起動します。
次に find を使用します shred と一緒に /var の内容を破棄して削除する 、 /srv 、 /home 、 /root 、 /usr/local 、および /opt .
find /var /srv /home /root /usr/local /opt -depth \( -type f -exec shred -f -z -u {} \; -o -type d -exec rmdir {} \; -o rm -f {} \; \)
次に、コントロール パネルでボリュームを破棄します。