上个月收拾NAS，顺手看了眼照片库的占用：4.6万张、186GB。这数字不对劲——我手机相册里撑死一万三千张，备份了四年也不该翻三倍多。翻了半小时目录，真相很扎心：同一张闺女啃玉米的照片，在库里躺着三份，文件名不一样，内容一模一样。这篇就把我这次清理重复文件的全过程写出来，包括用哪个工具、命令怎么敲、哪些坑别踩，最后清出了18.9GB。
重复文件是哪来的：三个来路，我对号全坐
翻完自己的库，重复文件基本就三个来源。
第一个是换机重新全量备份。我的照片走自动备份进NAS，这套流程我在手机照片备份那篇写过。问题出在换手机：新手机登录App，它认不出云端已有的部分，把相册原样又推了一遍。换两次机，就是两批整建制的副本。这是最大头，我库里三分之二的重复都这么来的。
第二个是微信图片。聊天里的图点保存进相册，相册又会被备份一遍——可这张图对方发我的时候，我可能已经存过一次。同一个文件两进相册，NAS上就是两份。微信那个目录我自己都绕晕：家里老人手机上登录的还是同一个账号，他俩保存过的图，也会顺着共享相册混进来。这部分靠肉眼翻目录根本理不清，只能交给工具。
第三个是相机SD卡反复导入。每次拍完往电脑里导，手一抖新建了个文件夹，赶上哪次没导干净又全导一遍。视频文件大，一个4K素材几百MB，重复两三个就是1GB出去了。我后来统计，217个重复视频就占了11.2GB，比6625张重复照片（7.7GB）加起来还多。清照片之前先盯视频，账最划算。
动手前先想清楚：哈希相同的才叫重复，「长得像」的不算
这一步想不明白，后面容易删错东西。
fdupes这类工具判断重复的依据是文件内容——把文件算一遍哈希，哈希一样才算重复。所以文件名再离谱都不影响，IMG_20240601.jpg和微信图片_20240601102000.jpg只要字节相同就会被揪出来。反过来，你裁剪过、压缩过、加过滤镜的照片，哪怕画面是同一张，哈希完全不同，工具不会碰它。这其实是个保护：动过的文件交给你的记忆去判断，没动过的交给工具。
我的原则就一条：先只扫不删，把清单落成文件看一遍，再动手。命令行工具默认就是只列出重复、不动任何文件，删不删是另一个参数说了算，这个设计本身就挺安全的。
NAS本机跑fdupes：飞牛三行命令，群晖走Docker
先说飞牛。飞牛底层是Debian，SSH登上去装工具就是一条apt的事：
sudo apt install fdupes
装完先干跑，只扫不删，把结果存成清单：
fdupes -r /vol1/1000/photo > /tmp/dup.txt
-r是递归扫子目录。跑完打开dup.txt，重复文件会一组一组排好，每组留哪个你自己定。我这次扫186GB用了3小时40分，N100加机械盘，4.6万个小文件,急不来。这里有个坑提前说：扫描前把硬盘休眠关了，不然扫到一半盘睡过去，要么卡住要么把你之前配的休眠计划全搅了。
看完清单确认没毛病，再用交互模式删：
fdupes -r -d /vol1/1000/photo
-d会一组一组问你保留哪个，列出序号让你敲数字。6842个文件挨个点肯定点不完，我的做法是先拿交互模式过前几十组，确认扫出来的确实都是重复，心里有底了再回头按清单批量处理。批量的土办法很朴素：dup.txt里同组的路径挨着排，我看下来重复基本都集中在换机那两次的老目录里，把老目录整批处理掉，新目录原封不动，比一组组挑省事得多，也不容易手滑。
群晖麻烦一点，DSM套件中心里没有现成的去重套件，SSH下也没有apt。两条路：要么去下fdupes的静态编译版本丢进机器里跑，要么用Docker起个Linux容器把共享目录挂进去扫，Docker这套流程不熟的话翻我之前写的飞牛Docker入门，目录挂载那节一模一样的思路。
想找「相似」的照片：dupeGuru得在电脑上跑
fdupes有个天然盲区：连拍的照片。同一个场景按了五下快门，五张照片字节不同，哈希不同，fdupes一个都认不出来。这种「长得像但不是同一个文件」的，得靠dupeGuru。
dupeGuru是装在电脑上的，Windows、Mac都有。用法是把NAS的共享目录在电脑上挂载出来——Windows映射网络驱动器，Mac直接访达连SMB——然后在dupeGuru里选这个目录扫。它有个专门的Picture模式，按画面内容比对，连拍、不同压缩率、不同分辨率基本都能归到一组，每组里帮你标出参考图，勾选其余的删掉就行。
代价是慢。走网络扫小文件，SMB协议的开销大得很，我扫一遍跑了大半个晚上。所以我的建议是分工：完全相同的重复交给fdupes在NAS本机清，清完还嫌乱的连拍再上dupeGuru慢慢磨。另外飞牛相册和群晖Photos的App里也有查重入口，能处理一部分一模一样的照片——机器算力够不够另说，我家那台的底子在人脸识别实测里交代过——但连拍这种它们基本无能为力，我拿自己库试过，识别率不如dupeGuru的Picture模式实在。
不想删文件还想省空间：硬链接是个偏方
再说个进阶玩法，怕删错文件的人可以看看。
jdupes（fdupes的一个优化分支，飞牛源里一般也有）有个-L参数，不做删除，而是把重复文件做成硬链接：每组重复只占一份空间，但每个路径都还在，你从任何目录点开都能看到这张照片。对相册类应用来说等于什么都没发生，容量却实打实降下来了。
听着完美，限制得知道：硬链接只能在同一个文件系统里做，你两块盘各一份是链不起来的；Btrfs的子卷之间、有快照参与的场景也各有各的别扭。我自己只在下载盘上小范围试过——那块盘的来历写过，SSD缓存退役下来当下载盘，里面游戏镜像、安装包重复得厉害，链完省了4个G，相册主库我是一点没敢动。没把握就别在生产数据上试偏方，这句放在这。
三种人对号入座，附我的完整顺序
按你的情况选路线就行：
| 你的情况 | 推荐做法 | 理由 |
| 照片为主，想稳当 | 电脑装dupeGuru扫共享目录 | 图形界面勾选，误删了回收站还能捞 |
| 库大杂，视频文档压缩包都有 | NAS本机fdupes | 不占电脑，跑得快，清单可存档 |
| 一点都不敢删 | jdupes -L硬链接，或先加盘 | 文件全保留，空间照样省 |
我这次的完整顺序，给你参考：先关硬盘休眠，fdupes干跑出清单；清单里视频和照片分开统计，先处理视频（11GB比照片那头划算）；照片组抽查二十来组确认没误判，再批量清；收尾把换机重复备份的病根治了——重新登录备份App的时候盯着第一遍同步，发现全量重推就停掉手动补差。那份dup.txt我也留着没删，打算过半年再跑一遍fdupes对比看看，重复是不是又在悄悄攒。18.9GB腾出来之后我那块4T盘压力小多了，不过说实话，NAS这东西的可用空间就像衣柜，清完只是舒服一阵，下次买盘的账早晚还是要算的。
发表评论