简短回答：写入文件时记录一个哈希值，以后再进行比较。如果哈希值不同而又没有任何东西编辑过该文件，那就是字节在你不知情时发生了变化。
其他任何东西都发现不了。一块存在静默损坏的磁盘能通过“急救”，SMART 报告一切正常，挂载也毫无问题。
存储是物理的。旋转磁盘上的磁畴会减弱。闪存单元中的电荷会泄漏，温度高时更快，驱动器长时间断电闲置时还要更快。数据线在传输中可能丢失一个比特。固件也有缺陷。
驱动器会自行纠正其中大部分问题，靠的是纠错码，以及重新分配发现正在变坏的扇区。真正要紧的损坏是漏过这一切的那部分：一次读取返回了与写入时不同的字节，却报告成功。
人们争论的是名字。有人叫它位衰减，有人叫它静默数据损坏，有人叫它数据退化。对我们来说它们是一回事：文件变了，而没有任何提示。
这部分值得理解，因为它解释了为什么你会去找的每一个工具都是错的工具。
cp 和 Finder 只是读取字节、写入字节。如果读到的字节是错的，它们就会忠实地写入错误的字节。所以实话是：你的 Mac 没有任何机制会告诉你。第一个症状是一张照片上出现一条乱码，一个打不开的归档，或一段放到一半就停住的视频。
对单个文件来说很罕见，但对一大批文件经过很长时间来说并不罕见，而这正是备份要应对的情况。有两点会明显提高几率：
它在备份中比在工作磁盘上更重要，原因在于工作文件会被打开，而打开一个损坏的文件，就意味着你发现了损坏。备份写入一次就再也不读，这意味着备份中的损坏要到你需要备份的那天才会被发现。
记录你写入的内容：
cd /Volumes/Backup
find . -type f -exec shasum -a 256 {} \; > ~/backup-hashes.txt然后，几个月后，再检查它是否仍然相同：
cd /Volumes/Backup
shasum -a 256 -c ~/backup-hashes.txt | grep -v ': OK$'打印出来的任何文件，其字节都已改变。如果你没有编辑过它，这就是答案。
两条实用建议。把哈希文件存放在它所描述的驱动器以外的地方，否则你会同时失去两者。而且这需要读完整块驱动器的时间，所以请安排在夜间运行。
以上种种，正是这款应用以现在这种形态存在的原因。它把备份的每一块数据都以其内容的哈希值存储，然后按计划读回备份，并按存储时的哈希值核对每一块数据。
因此，不匹配就是证据：这些字节不是当初写入的字节，无论怎么解释都不可能没问题。在备份底下被删除的数据块会报告为缺失。而主界面上的分数只计算最近验证过的内容，所以它比人们预期的要低，而这正是重点所在。
在这里，拥有第二个位置比本站任何其他地方都更重要。有两份副本时，其中一份损坏只是麻烦；只有一份时，那就是这个文件的终结。
不能。“急救”检查的是文件系统结构，而不是文件的内容。一块文件已被静默损坏的驱动器能干干净净地通过它，这正是这个问题之所以棘手的原因。
不能解决这个问题。SMART 报告的是硬盘发现并纠正或重新分配的错误，而静默损坏恰恰是它没有发现的那一类。不过对于正在出故障的硬盘仍值得检查，那是另一个更容易察觉的问题。
它只校验自己的元数据，不校验你的文件数据。ZFS 和 Btrfs 会校验文件内容，还能从冗余副本中修复，但两者都无法作为普通的 macOS 启动宗卷或外置宗卷使用。正是这个缺口，让应用层面的检查值得拥有。
频繁到足以在好副本还在的时候发现坏副本。对于存档，每季度一次是合理的；如果是某个无可替代之物的唯一副本，就每月一次。正确答案是你真的不会跳过的那个频率，这正说明它应当自动进行。
不够。验证能告诉你某份副本坏了，却无法把文件还给你。只有存在可供恢复的第二份副本时，检测才有用，这正是 3-2-1 规则的全部论据。
相关阅读：如何检查备份是否可读、存储库格式，以及 3-2-1 规则。