写这篇文章一方面是因为这两天有谈论全闪 NAS 的热度，另一方面也是希望抛砖引玉，看看能不能集思广益找到更好的方案。
0x10 使用情况概述
我大概从十几年前 m2 ssd 普及开始，笔记本一定都选双 ssd 的型号，原因是我会组软 raid 来保证可用性。目前经手了六七台电脑，因为扩容前后大概用过十几块 m2 ssd ，坏过一块，原因是主控坏了。
因为我是用在笔记本上的，所以挑选的都是中等价位的非高性能产品，目的是控制功耗和发热，同时我会刻意挑选有颗粒生产能力的原厂品牌。由于有组 raid 的需求，我实际上会倾向同样的型号直接买两个。台式机也有一些 ssd ，加上笔记本替换下来的，多数都是通过拆分卡上了 nas ，总体上应该经手过三十块左右，nas 里出现过一个盘写锁定变只读，其他都是因为盘位不够被替换掉了。
前两年入手了一个摩方 m6, 这是个双 ssd 的小机器，便携性很好。我把它当作网络移动硬盘用来存储临时快照（备份）。机器散热很差，里面的 ssd 温度经常有 50+，因为没坏过所以我也没管它，反正就是出差或者旅行的临时中转。
0x20 SSD 的安全性
我个人感觉 ssd 挂了基本不用挣扎，但理论上只是主控坏了是可以移花接木来修复的，只是我从来没有实践过。而且我的使用策略上来说，备份是足够的，所以不会真的考虑去维修。
过去十多年里，我有过多个的机械硬盘 NAS ，经手过大概二三十块硬盘，前几年陆陆续续处理掉了，数据要么上云冷存，要么进了 ssd 里面。
可能是我运气比较好，机械硬盘也就坏过两三块。所以从我个人的经验来说，hdd 怎么用大概 ssd 就怎么用，没有区别。本质上不能指望单一副本的可靠性，3-2-1 原则一视同仁。
0x30 存储方案进化
这部分是这篇文章的重点，以我的经验来说，机械和全闪 NAS 在技术路线和使用方式上还是差别挺大的。
0x31 ~2015
时间大概写的，记忆不一定准确。大致就是 m2 ssd 刚开始流行的时候，当时的企业级产品主要还是 u2 接口。
由于我比较神经质加偏执，非要在笔记本上搞 raid1 ，还是吃了点苦头的。当时能选的方案主要就是 mdadm 和 lvm+mdadm 。nvme 协议的 ssd 相对于 sata 时期在写平衡、trim 方面好了很多，但实践证明，它仍旧不太适合基于块镜像的 raid1 场景。
最主要的问题是 scrubbing ，毕竟块层面上是不带校验信息的，而 ssd 的块又不具有 hdd 块的物理映射，所以最大的感受就是机器经常在做 scrubbing ，那时候容量又小，读写量非常大。好在 ssd 本身比较坚挺……
同一个时期，我组了一个架构比较特殊的 NAS 。由于工作原因，我这边参与了一个分布式的存储项目，每个节点都是全志 arm 的单板机，只带一块机械硬盘，然后通过大量节点组建高可靠性的分布式存储。软件层面上使用的是 glusterfs 。我在自己家里复刻了一个八盘位的系统。
笔记本和 NAS 的架构差异让我理解到，传统 raid 已经过时了。
0x32 ~2020
之后我的笔记本存储方案过渡到了 btrfs raid1 ，由于它是基于 file extent 的，所以就省去了 scrubbing 这个行为。事实证明我没有看走眼，多年之后 fedora 将 btrfs 作为默认的文件系统。
这里最大的优势实际上是笔记本 ssd 的迁移升级。当我换新的笔记本的时候，我会拆下旧机器的一条 ssd ，与新机器上一条空 ssd 一起装机，在新 ssd 上重建 raid1 之后，旧机器 ssd 归位，新机器再上一条空 ssd 再重建一次就完成了迁移。由于 ssd 本身性能够高，加上又是文件系统级别的复制，这个重建比起机械盘上基于块的重建快太多了。
同时期我也重新组了机械 NAS ，从两盘位到四盘位一路折腾到八盘位十六盘位。主要的软件方案是 FreeNAS/TruNAS 也就是 zfs 。之所以盘位一加再加，核心问题就是存储池的规划缺乏前瞻性，扩容是个很麻烦的事情。简单说就是 zfs 鼓励你一开始就组建好 4Tx8 阵列，而不是隔一段时间加一块硬盘这样。
这个阶段的对我来说比较重大的影响是，我开始大量使用基于 CoW 的快照。由于我 3-2-1 的原则坚持比较到位，实际上的数据损失风险已经不是副本丢失，而是由于备份间隔不够导致的历史版本被覆盖。
快照极大简化了备份这件事的心智负担，我也花了比较大精力人工对我的数据进行去重。结果是我的存储空间需求大大降低了，这也为后期过渡到全闪存储提供了可能。
0x33 ~2025
这个阶段笔记本上方案没有太大变化，验证过 opal sed 都是坑，所以又回到 luks 方案了。有一点小区别就是我增加了摩方 m6 这个中转设备，因为基于 CoW 的快照本质上不是完整的副本，所以外置存储作为独立副本还是有必要的，出差或者移动办公作用很大。
我的 NAS 也在处理掉机械盘后逐渐变成纯闪方案，机器还是之前为机械方案组建的机器。保留的原因是它用的服务器主板，cpu 通道多，而且主板支持 bifurcation 拆分，立创打两张 retimer 卡就能搞出八个盘位来。
软件方面 NAS 我直接替换成了 fedora+btrfs ，即我的所有物理机器，包括 m6 那个移动设备，都用了一样的系统。这个改动主要是方便数据同步，用 send/receive 就可以通过网络完成快照的传递，支持增量同步而且是二进制流效率很高。
这里最大的转变其实是存算分离的需求没有了，主要是我被 aws 和阿里云的抢占式实例惯坏了，自己家里已经没有了算的需求，那么高性能的存储需求也就不存在了。可能未来我会将存储系统降级到低功耗的全闪设备上。算力需求上云这个话题可以再开帖子另说。
0x40 总结
这里只是我的一点经历和体验，我非常想听到大家对于个人存储的看法，很多时候可能就是一个想法最重要。
还有很多使用细节，比如 ipv6 公网访问，或者在存储池之上建立其他服务什么的，因为与全闪关系不大就不多说了。
我说的内容只是建立在我的经验和需求之上的，可能未必适合每个人，思路仅供参考。

"理论上只是主控坏了是可以移花接木来修复的"，以前是，现在不是了。一线品牌的固态硬盘，主控和颗粒之间都做了一对一绑定，移花接木这招已经没用了 。只有杂牌固态厂商，没能力定制固件，用的是公版固件，才可以实现同型号主控随便更换。

高端局。。。
我就只想组个 mini 小主机，万兆网口，双盘位固态 PICE 4.0 就够了
飞牛 OS ，存存照片和影视
静音，静音，静音

zfs 不用 raidz 的话并不会对硬盘增减有限制，可以直接从池子里移除或者添加 raid1 的 vdev ，而且现在的话 raidz 也支持扩容了。考虑到 btrfs 的 raid5/6 几乎还处于不可用的状态，这一点上我觉得其实没多大差别，要不然就是更不稳定的 mdadm+btrfs 的方案

这不是巧了，刚配置的全闪机器，用的捡垃圾的 del sff 机型，装百元级 i3 8100 处理器 +32G ECC HP 服务器拆机内存，X4 插槽插 X550 万兆电卡，X16 插槽上 4xM2 卡，机器自带一个 M2 ，机器自带 3 个 SATA 但是只有一个 3.5 位置，改造成 3 个 2.5 位置，这样有 5 个 M2+3 个 2.5+双 10G 网口，还有 ECC 内存保障安全，跑 win 待机下整机 30W 功耗（品牌机自带白金电源还有 CPU 能到 C7 ），M2 硬盘用 ti7100 4T 和 ARES 4T ，2.5 硬盘用垃圾版的镁光 1100 2TB ，存储 WINSRV 开 SMB 共享，阵列用 snapraid ，用硬链接聚合各硬盘文件夹 SMB 出去，效果美滋滋，可惜 X550 没有 ASPM ，X16 拆分卡也没 ASPM ，30w 勉强能打住

和我的一样，我是用 nuc7 ，U 盘装了个 FNOS ，让 nvme 和 sata 的两个固态组了 raid1.基本就是用来存储照片备份的。加上 icloud

还有 i3 8100 的核显可以开 gvt-g 装 PVE 后一个核显拆成 2 个可以给飞牛做硬解同时给 windows 的 rdp 提升流畅

全闪 NAS 受限于体积、速度、性能、散热、价格的多重考虑
我使用的全闪 NAS 方案是：
A. 单条 m2 搭配高性能 CPU+外置风扇散热
B. m2+sata ssd 搭配低性能 CPU+被动散热
后续可以考虑 m2 PCIe3.0x1 的 NAS 方案，如 零刻 me mini

我使用的笔记本没有使用 raid1 方案，但是塞了两个 2T m2 ，定时备份主硬盘数据到备份盘
本地定时备份有 2 份，restic 带版本控制备份，snapraid 镜像备份
实时云备份有 3 份，带版本控制

遇到的 SSD 故障：3 次数据丢失，2 次是 SSD 温度过高丢数据，1 次是三星 0E 事件
个人总结就是 SSD 丢数据能抢救多少数据是多少，整个硬盘低级格式化后依旧完好如初
没遇到过掉固件、主控之类的故障

由于主力系统是 Windows ，系统自带的备份（文件历史记录）格外难用，卷影复制没有好用的备份方案，新版的动态磁盘、存储池在机制上有点落伍，故而使用了第三方程序 restic+snapraid

机械 NAS 使用了 16T*4 RaidZ2 方案，强行上了 ZFS /t/979429

疑问：
1 、OP 的 btrfs 是否启用了重复数据删除
2 、摩方 m6 这个中转设备上的独立备份最终会跟家里的 NAS 同步数据吗？
我也有一段时间折腾随身 NAS ，后来受限于繁琐的线缆放弃了，直接将笔记本的数据同步到家里的 NAS 上了
3 、OP 会关注家里 NAS 的功耗吗？服务器主板会不会比较费电？
4 、数据零碎存储在不同的机器上，数据检索是怎么做的，比如临时需要某个文件，但是记不得存储在什么位置了，如何进行搜索？
我目前是把 NAS 数据挂载到笔记本，通过 everything 搜索

我看现在给新 macmini 扩容的，就是把 mac 的存储小版上的颗粒直接吹下来焊个新的上去

＃8
苹果稍微有点不同，可以认为是强制开启 FDE 全盘加密，而主控在 SoC 里面，所以扩容是可以的，但主控和存储颗粒分离就会因为无法解密而丢失数据。

＃3
现在 zfs 扩容也方便了很多，在我开始用的时候还没学习到，走了不少弯路。

btrfs 的 raid 5/6 我没用过，因为几乎所有文档都说不稳定。

除了笔记本上因为盘位限制只能 raid1 ，一般 NAS 多盘位的情况下，只需要决定冗余程度（数据和 meta 副本数量），或者说能承受几个盘数据损失就够了。从数据恢复的角度上说，多条带不是很友好，多副本更灵活一些。

我没用 zfs 主要是它不在内核主线里。

＃4
如果电源瓦数低，可以直接限制 ssd 本身的功率。一般 ssd 有几个功率等级，高的话能到 8w 左右，限制到 2~4 档位就比较稳了。

＃7

1. 我在 zfs/btrfs 上都不用 dedup 功能。有过一次人工去重，前后花了大概一个月吧……
2. 笔记本->m6->NAS 或者 笔记本->NAS 的数据流是单向的，严格来说不能叫同步，如果是双向的脑子就不够用了。我大概五六年前就不再使用类似 dropbox 的多节点双向同步盘方案，作为人来说很容易确认哪个设备上的副本是权威副本，但机器处理这种分布式同步问题是比较无力的。
3. 我用过退役的机架服务器，待机功耗就有 100w 左右，主要还是工艺太落后了吧，但也没到不能接受的程度。只是这个设备在家不好放，也没有好用的散热和静音方案。后面改用超微标准板型的，用主流设备就好很多。这个平台上主要是 hba 卡，网卡虽然也会增加基础待机功耗，功耗的大头已经转移到十多块盘本身上面了。所以我不再关心功耗问题，更关心长期维护的事情。

检索方案有点复杂，我单独开个回复来说。

＃7
物理上如果数据不能存在于单一存储池中，就必须要用物理手段对存储设备打标签。比如我之前只有六个盘位但有二十块盘的时候，只能把冷备盘打个 tree 结构用来检索了。后面就只说软件层面的检索问题。

Linux 有个 fsearch 和 everything 的原理比较接近，但它只能做元数据实际上也就是文件名的检索。我研究过 Spotlight 之类的系统级索引工具，提供内容检索的方式手段有两个，一个是增加特定数据格式的解析，比如 office 系列用的 xml 格式，二是应用程序主动适配系统的检索接口。

所以我缺少的只是基于内容的检索，涉及到元信息的检索可以用这些已有的工具。

我解决内容检索的思路是：首先明确我需要快速检索的内容有哪些（多数非我自己产生的内容可以不需要检索），然后确定我需要用什么方式来检索（就是建立哪些索引），最终就是构建我自己的索引数据库并开发配套的后台索引和检索工具。

我这样做的底层逻辑是，数据索引一定要在数据产生时就同时构建，类似于数据库，想要查得快，就一定要提前花时间写索引。我又是长期的 Linux 用户，生态上来说只能自己造轮子了。

数据库方面有三个选择，csv/sqlite/嵌入式 kv ，最终选择了 csv 。因为我想了一下，这个方式用 grep 之类的工具检索最简单，存储结构比 sql 灵活，也不需要额外依赖。同时 csv 基本只有追加和按行检索，数据量几十 MB 放内存也没什么性能问题。一条典型的数据大概是这样的：

XXXX.pdf, /path/to/pool/location, keyword1, keyword2, keyword3, ...

第一栏固定为文件名，用于检索到之后再去使用元信息定位文件本身。第二栏是我自己习惯的存储路径，人能看懂就行。后面全是关键词，有关键词就能匹配到。

基于这个数据结构，所谓的建索引就是根据文件内容手动或者尽可能自动生成关键词。后台索引就是基于 inotify 监听我关心的数据文件夹，每当有文件变动时，后台索引模块就根据文件格式去匹配我的索引规则脚本，执行脚本更新索引数据库。

例如项目代码之类的我就忽略掉了。纯文本类文档的处理脚本就是做个分词，去掉无意义的，然后保留五到十个高频关键词。pdf 类的不太好处理，我一般手动标记一下。

之前视频和图片类也不太好处理，大概从前年开始，我给图片加入了处理逻辑。原理就是用文生图的反向 CLIP 模型，通过图片来生成文字描述，同时 ocr 过一下提取一些文本。本身这个检索就是为我自己服务的，如果需要类似于人脸识别归类，这些放到 NAS 上面用专门的工具去做。

检索前端就是 dmenu 配合 fzf 去检索这个 csv 数据库，基本上任何一个 launcher 类应用都能胜任，也能用于命令行。通过串联脚本可以实现类似实时预览的高级功能。

总体来说这是个非常原生态、专注吃狗粮的做法。思路不难，实现难度也不高，只是实践起来有比较高的初次迁移成本。还是那句话，每个人的需求不同，没有标准化的普适方案。

非常专业，进来学习。好奇问一下，楼主应该是在实践中将数据完全本地化管理，在一些需要算力的时候使用云服务，那么楼主本地的公网环境是怎么样？拉了几条宽带？有没有使用什么聚合路由的硬件设备经验呀？

＃14
数据并没有完全本地化，有一部分冷备用的是公有云最便宜的一档，按目录价来说大概 100 元/TB/年，协议价会少一半吧，总体并不便宜。

公网环境就是普通的 300Mbps ，没有上到千兆。之前有因为移动合约拉过第二条，仅仅是作为备份用，没有真正做过双接入或者负载平衡的设计。

主要原因是我的大部分数据并非来源于 pt ，而是日常工作、生活的私有数据，所以不太依赖公网。

我的算力需求主要是编译 Android 系统（自己刷机用）和一些个人应用，另外是编译 linux 内核和一些 rust 工程。这类 cpu/ram 需求用抢占式实例非常便宜，大概几毛钱一小时。但是类似服务器转码 h264 h265 就不太合适，因为流量费用并没有折扣。

op 没有碰到 ssd 固件问题导致 btrfs 撂挑子的情况么？我这边可是看到不少断电之后出问题的。

＃16
btrfs 文件系统损坏的话题我特意没有在正文里提，因为我这里无论笔记本还是 NAS 都是 raid1 配置，没有遇到过无法恢复的情况。实际上大部分单副本配置的 btrfs 在底层设备损坏的情况下是无法恢复的，我如果说 btrfs 很稳定会造成误导。

从原理上说，btrfs 和 ext4 这类的区别是：btrfs 不关心也不管理底层块设备的坏块映射，ext4 会有坏块列表。btrfs 认为底层 hdd/ssd 会自己管理坏块的重映射。但这并不能说明 ext4 的处理机制就更完善，实际上 ext4 只有在创建的时候才会初始化坏块列表，日后的使用过程中，只有出现 io 错误且用户主动标记才会更新这个坏块列表。而 btrfs （包括 zfs ）这类都是根据数据校验信息来间接判定底层设备出现了问题。

上面这段话的推论是，在使用过程中如果底层存储设备发生了块损坏，btrfs/zfs/ext4 都能发现 IO 类损坏，同时 btrfs/zfs 还可以发现静默类（ bit rot ）损坏。但是在没有额外副本的情况下，btrfs/zfs/ext4 都没有修复能力。

所谓的修复，仅限于数据和文件系统的信息不一致的情况下，通过假设文件数据本身没有问题，来重建文件系统元数据，使其匹配数据本身。这个假设在存储密度越来越大的今天已经很难成立了，所以新的文件系统都转向了 file extent 级别的校验，而非块级别的校验。

这是存在于大量用户认知中的误区，认为底层设备坏了，运行个命令就能修复，这是不可能的。这也是我坚持 raid1 的原因，本质上它不是备份而是可用性手段，基于两个 ssd 发生相同数据映射的块同时损坏概率非常低这个假设，可以快速（自动）判断数据正确的那个副本，而不是必须要立即去其他备份副本提取。

假设现在有一个不开启 raid 默认配置的 btrfs ，文件系统元数据（目录结构、权限属性这些）是双副本的，单个文件的元数据（ inode 和时间戳这些）因为是文件系统元数据的一部分，所以也是双副本的，只有文件数据本身是单副本的。

底层设备损坏有两种情况：

1. 主控坏掉了，多发生在 ssd 设备上
2. 部分物理块损坏，然后这个块可能对应着纯数据块，也可能对应着元数据，还可能同时对应着数据和元数据，甚至损坏量大的话，元数据的双副本也会损坏

前者的情况对于所有文件系统都一样，第二种情况这里可以简单分析一下。

• 如果只是数据块损坏了，它是系统文件可能就无法引导，普通文件的话就是坏掉了。这种情况下 btrfs 检测到，两份元数据是一致的，而数据校验信息和元数据对不上，就会非常明确地提示用户数据损坏，但是很显然 btrfs 是没有修复这个损坏数据的能力的
• 如果恰好只坏了某个文件的元数据一个副本，那文件系统是可以根据数据和它另一个元数据副本校验正确这个事实，来推断出前一个元数据副本损坏了，从而完成元数据副本的修复
• 如果大量物理块失效，数据和元数据都损坏了，就无从判断了

由于目前 ssd 的存储密度太高了，一旦发生损坏基本都是大量块同时，所以容易造成 btrfs 不稳定不安全的错觉。传统机械硬盘存储密度低，

我想表达的是，当出现明显的数据异常的时候，还假定数据本身没问题，想要文件系统去尝试修复，这个行为是错误的，在这个情况下 btrfs 之类的文件系统撂挑子反而是非常正确的行为。

由于我非常清楚这个底层的机制，同时坚持使用多硬盘的 raid ，所以即便 ssd 上有坏块，也被 btrfs 自动修复了。很可惜我没有遇到过主控好而颗粒坏的情况，没有相关的经验。在 NAS 的机械硬盘版本上，我是有遇到过硬盘损坏的，系统大量报错，然后因为硬盘自身坏了，btrfs 自动修复行为也反复失败导致降级。最终的结果就是我把坏的硬盘换掉，重新 balance 就好了，不会去尝试修复。我现在没有什么数据支撑，因为它没有坏过，所以我也确实不关心 btrfs raid1 在后台 scrub 的过程修复了多少错误。

文件索引可以在 wine 里跑 everything ，然后用 everything server 分享出去。
没有直接读 mtf 那么高效，但还是能即时跟踪的

＃18
Everything 快的原因是 ntfs 有个 USN Journal ，所有查询快的方法说到底都是提前写好了要查询的内容。

理论上可以把 Everything 用于非 ntfs 文件系统甚至是网络文件系统映射，那就就退化到了普通的索引再查询的机制上了，也就不会那么快。

当然作为一个 GUI 应用，Everything 在索引数据结构和 UI 架构上做得也很不错，你提到的场景我更推荐 linux 的 cboxdoerfer/fsearch 这个工具，文件系统无关，同时针对文件（条件）检索优化。

命令行的话需要持久化索引就用 locate 系列，不需要索引 fzf 也可以。

就算是 NTFS ，USN 只是加快了索引速度，everything 还是会自建索引的。文件系统的日志再怎么也比不上自建数据库的格式优势和效率啊。
而查询速度不是大问题吧，平时常用都是简单搜索又不是多复杂要写成 SQL 那种。

我看中的是实时跟踪变化。windows 上直接监控 samba 的网络共享是不起作用的，定时扫描不能增量重建，加上 samba 的效率问题，小文件一多就要扫描个几分钟。
但如果在 NAS 上用 wine 跑 everything ，监控的就是本地文件夹，会转译到用 fsnotify 之类 API ，就能即时增量跟踪变化，全量扫描也比网络共享要快一两倍。
然后用 everything server 分享索引（不过好像属性索引不会被同步过来）到 windows 主力机，目录映射填好就能本地搜索直接打开，不用再去 NAS 上敲命令或者 vnc 到 NAS 上了。