我的印象是，如果希望能够完全删除某个文件而不擦除整个驱动器，那么永远不应该将其存储在 SSD 上。是对的吗？即使使用全磁盘加密，如果获得了密钥，似乎也无法确保取证方法无法恢复该文件，除非向驱动器发出固件擦除命令并用非-数据（因为通常不能依赖固件命令）。因此，如果您希望能够完全安全地删除某些内容，而不是删除存储它的整个驱动器，那么您应该只将其存储在 HDD 和 USB 记忆棒上。正确的？
答案1
这取决于你的观点。
从密码学家的角度来看，他们甚至不希望最短的字节序列幸存下来 - 毕竟，它可能是 8 字节密码或 128/256 位密钥（16-32 字节）。对于密码学家来说，即使是非常短的字节序列也已经被认为是至关重要的。
然后是普通用户的观点，他们通常处理兆字节到千兆字节范围的文档、照片和视频，当这些文件被意外删除时，即使不覆盖任何内容，恢复这些文件也已经是一个挑战。
我的印象是，如果希望能够完全删除某个文件而不擦除整个驱动器，那么永远不应该将其存储在 SSD 上。是对的吗？
对SSD的批评源于其实现的复杂性。基本上SSD是一个黑匣子，它有自己的大脑，自己决定在哪里存储数据以及何时删除数据。作为其磨损平衡机制的一部分，它甚至可能选择自行重新定位数据，并使用过度配置和其他内部数据结构，这些数据结构可能填充了用户甚至无法访问的数据，更不用说可靠地删除数据了。
相比之下，HDD 是一种简单得多的存储介质。 HDD 对用户来说更具可预测性，并且虽然它同样保留其扇区储备，但人们更相信只要没有发生表面缺陷/扇区重新分配事件，这些扇区将保持未使用状态。
对于添加额外缓存机制和优化的 SMR 驱动器来说，情况不再那么明确。 HDD 也变得越来越智能。
然而，目前尚不清楚这些考虑因素在实践中的相关性如何。密码学家担心的事情可能不一定与您相关。
在数据恢复情况下，从硬盘恢复文件的成功机会要高得多。对于 SSD，通常根本没有希望。这是因为 SSD 一直在擦除数据。
TRIM/丢弃随处可见——当你每周跑步时fstrim；当你mkfs;当您lvresize或lvremove（如果 LVM 设置为issue_discards=1），或手动使用blkdiscard.数据就这样消失了，您可能无法将其恢复。
从数据恢复的角度来看，SSD是一个非常令人头疼的问题。数据恢复喜欢 HDD，其中数据会无限期地存在，直到被实际覆盖，而讨厌 SSD，出于性能考虑，数据实际上眨眼间就消失了。
因此，在某种程度上，如果您的目标是删除数据，那么 SSD 远远优于 HDD。
即使使用全盘加密，如果获得密钥 [...]
确保密钥无法获得是加密的全部目的。一旦密钥已知，就好像加密根本不存在一样。如果你看到有扳手的人，为你的生命而奔跑。
如果您的目标是防止访问您的文件（无论是删除还是其他方式），全盘加密是您可用的最佳工具。正确使用这个工具是另一回事。如果使用不当，加密很容易被破解——只需要键盘记录器或有人监视您输入密码即可。即便如此，这仍然是你能做到的最好的。
LUKS 等加密方案还可以防止残留的小数据痕迹。 LUKS 不会将其密钥存储为几个字节，而是将其存储为数百千字节的密钥材料，每次输入密码短语时都会从中派生出实际的密钥。这也是 LUKS1 为其标头保留 ~1MiB 的原因，甚至为 LUKS2 保留 ~16MiB 的原因。
它的目的是使擦除的 LUKS 标头恢复的可能性非常小（如果不是完全不可能的话），即使像 SSD 这样的存储介质在内部保留了几页数据。
如果您希望能够完全安全地删除某些内容，而不是存储它的整个驱动器
这些都是相互矛盾的目的。在不擦除整个驱动器或至少整个可用空间的情况下完全安全地删除单个文件或多或少是不可能的。
我们处理文件的方式 - 保存、编辑、再次保存、更多编辑、保存...
每次保存文件时，它通常会被截断为 0 字节并重新写入，从而允许文件系统将其存储在可用空间中的任何位置、完全不同的物理位置。这会创建额外的文件副本，甚至文件系统本身也不知道旧副本位于何处。
shred类似或仅仅对最后一个已知副本进行操作的工具wipe，使其无法安全删除。这甚至没有考虑日志等额外的文件系统复杂性。
除了擦拭整个驱动器之外随机数据，然后读回以验证是否确实存储了完全相同的随机数据，从而证明设备的标称存储容量被覆盖一次，无法安全删除它。这大约是您使用任何存储介质可以独立完成的操作的极限。
由于实际上这样做通常非常不切实际，因此擦除可用空间是下一个最好的事情，SSD（最好是那些在 TRIM 之后支持确定性读取零的SSD）以零成本免费提供该服务。