我想快速可靠地銷毀一些資料。如何？

Question 1

shredGNUcoreutils是專門為此目的而設計的。

從man shred：

重複覆蓋指定的文件，以使即使非常昂貴的硬體探測也難以恢復資料。

shred實際上讀取隨機位元組/dev/urandom並用這些位元組覆蓋檔案內容，最後可選擇用零覆蓋內容（來自/dev/zero）。因此，如果您想重新發明輪子，您可以手動完成此操作，但最好使用shred已經針對該任務進行了最佳化的工具。

例如，對於任何給定的文件my_secured_file.txt，您可以執行以下操作：

shred my_secured_file.txt

這裡：

-v為了冗長
-z用於隨後用零覆蓋文件，以隱藏粉碎
-n 5為迭代次數，預設為3

如果您願意，您可以增加迭代次數，儘管預設值就足夠了，甚至可以刪除檔案（-u, --remove）。

查看man shred。

由於shred對檔案進行操作，用於對目錄中的所有檔案進行操作（遞歸），例如my_secret_dir：

shopt -s globstar
for f in my_secret_dir/**/*; do shred -vzn 5 -- "$f"; done

或者find：

find my_secret_dir -type f -exec shred -vzn 5 -- {} +

筆記：

shred需要注意的是，它無法在日誌、快取、RAID、壓縮檔案系統上正常運作。引用man shred：

注意：請注意，shred 依賴一個非常重要的假設：檔案系統會就地覆蓋資料。這是傳統的處理方式，但許多現代檔案系統設計並不滿足這個假設。以下是 shred 在所有檔案系統模式下無效或不保證有效的檔案系統範例：

日誌結構或日誌檔案系統，例如 AIX 和 Solaris 提供的檔案系統（以及 JFS、ReiserFS、XFS、Ext3 等）

即使某些寫入失敗也能寫入冗餘資料並繼續運行的檔案系統，例如基於 RAID 的檔案系統

製作快照的檔案系統，例如 Network Appliance 的 NFS 伺服器

在臨時位置快取的檔案系統，例如 NFS 版本 3 用戶端

壓縮檔案系統

對於 ext3 檔案系統，上述免責聲明僅適用於 data=journal 模式（因此粉碎的有效性有限），該模式除了元資料之外還記錄檔案資料。在 data=ordered（預設）和 data=writeback 模式下，shred 照常工作。可以透過將 data=something 選項新增至 /etc/fstab 檔案中特定檔案系統的掛載選項來變更 Ext3 日誌記錄模式，如掛載手冊頁 (man mount) 所述。

此外，檔案系統備份和遠端鏡像可能包含無法刪除的檔案副本，這將允許稍後恢復粉碎的檔案。

在 Ubuntu 中，如果您使用的ext4檔案系統也是日誌檔案系統，則日誌模式是元資料的預設模式，而不是資料的預設模式（data=ordered是預設值），因此您應該使用shred-ing 來獲得預期結果，除非您更改預設值.

作為旁注，您可以透過以下方式找到預設檔案系統選項：

sudo dumpe2fs -h /partition |& grep 'Filesystem features'

例子：

% sudo dumpe2fs -h /dev/sda3 |& grep 'Filesystem features'
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize

表示has_journal這是一個日誌 FS，預設日誌選項為：

% sudo dumpe2fs -h /dev/sda3 |& grep 'Journal features'
Journal features:         journal_incompat_revoke

同時兩者：

% sudo dumpe2fs -h /dev/sda3 |& grep 'features' 
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Journal features:         journal_incompat_revoke

Answer