我想快速、可靠地销毁一些数据。该怎么做？

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 模式（因此 shred 的效果有限），该模式除了记录元数据外，还记录文件数据。在 data=ordered（默认）和 data=writeback 模式下，shred 均可正常工作。可以通过在 /etc/fstab 文件中为特定文件系统的挂载选项添加 data=something 选项来更改 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