XDA Developers 撰稿人 Yash Patel 在自己的服务器上跑了 File Browser 好几年，一直没有换掉的理由。得知归档消息后，他没等真出问题才动手，而是提前挑替代品，最后选定了 Filestash。他给出的评价是：日常够用，速度比原来还快。

一、Filestash 适合什么样的需求

1. 它是网页版文件管理器，用浏览器就能管理服务器上的文件
2. 能对接多种存储，按官方说明包括 FTP、SFTP、WebDAV、S3、Git 以及各类云盘，不局限于服务器本地目录
3. 它不是网盘全家桶，没有日历、联系人、在线文档协作那一整套
4. 如果诉求只是「打开浏览器找文件、上传、下载、挪动位置」，这类精简工具反而更省心

二、按官方步骤用 Docker 部署

1. 准备一台 Linux 服务器，装好 docker、docker-compose 和 curl。官方给的硬件门槛很低：只要不做密集视频转码、不同时服务上千用户，128MB 内存加 1 核就够
2. 新建目录并拉取官方编排文件：先执行 mkdir filestash && cd filestash，再执行 curl -O https://downloads.filestash.app/latest/docker-compose.yml
3. 启动服务：docker-compose up -d
4. 浏览器访问 http://服务器地址:8334，首次进入的第一件事是设置管理员密码
5. 进管理后台勾选需要的存储后端，例如只保留 FTP 和 S3，保存后即可开始使用

部署过程中不需要搬动原有文件，把 Filestash 指向已有目录即可。该撰稿人也是这么做的：存储位置一动没动，接上要访问的文件夹就用起来了。

三、日常真正用得上的几处

1. 界面清爽不拥挤，文件操作按钮都在预期的位置，文件夹层级容易跟
2. 支持文件预览，图片等受支持的格式可以直接看，不必先下载一遍再确认是不是要找的那个
3. 附带文件分享、搜索、书签、用户账号和访问控制
4. 内置工作流自动化引擎，可以给文件相关任务配简单流程，比如批量移动、处理，或在某个事件发生时触发动作
5. 支持插件机制，缺什么功能装插件补，不用把整套配置改复杂

注意事项

Filestash 的实际速度取决于它连接的存储，底层服务器或链路本身慢、不稳定，它救不回来。该撰稿人还遇到过缩略图突然不显示的情况，原因没查清，服务器重启几次后自行恢复了。想加在线文档编辑之类的进阶能力，需要额外配置。

如果要放到公网使用，官方建议前面加一层反向代理负责 SSL 终止。后续升级也很简单：重新拉一次 docker-compose.yml，再依次执行 docker-compose pull 和 docker-compose up -d。

来源：XDA Developers

机械硬盘主要有两种写入技术。一种是 CMR（传统磁记录），磁头在盘片上把数据一条条并排写下去，磁道互不重叠，写入和重写都干脆利落。另一种是 SMR（叠瓦式磁记录），它像屋顶瓦片一样让磁道相互交叠，能在同样面积塞下更多数据、成本也更低，但也埋下隐患：一旦要改写某条磁道，就得连带重写后面一整片交叠的磁道，持续写入性能因此明显下滑。

大约在 2013 年前后，厂商悄悄引入 SMR，且长期不在包装上标注，直到多年后用户才察觉。对普通场景——冷备份、影音仓库、单人存档——SMR 完全够用。但 NAS 是另一回事：多用户同时读写、频繁的随机写入、还有阵列重建时的高强度写入，都会把 SMR 的重叠重写代价放大到难以忍受，重建一块盘甚至可能拖垮整台设备。

给 NAS 选盘，建议按下面三步来：

一、买之前先查清楚。到厂商官网或规格页确认型号采用 CMR 还是 SMR，别只看容量和价格，也别被「监控盘」「桌面盘」这类模糊叫法带偏，关键看磁记录类型到底是哪一种。

二、优先认准标注「NAS 专用」「CMR」的型号，这类盘为 7×24 小时持续运行和阵列环境做了优化，故障率与重写表现更稳。拿不准时，NAS 厂商官网通常有一份硬盘兼容列表，照着买最省心。

三、已经买了 SMR 盘也别慌，把它挪到冷备份、单机归档这类轻写入场景，NAS 主阵列仍留给 CMR。

一句话：NAS 主存储认准 CMR，SMR 留给不常改写的备份盘，别让便宜坑了你的阵列。

来源：XDA Developers

TrueNAS 的底子是 ZFS。它 2005 年起源于一位名叫 Olivier 的开发者想把旧家用电脑改成 NAS，做出了 FreeNAS；2009 年 iXsystems 接手，以 TrueNAS 的名义推出企业级产品，FreeNAS 则作为社区版继续开放；2019 年两者被统一为 TrueNAS Community Edition 与 TrueNAS Enterprise。

一、先清点硬盘：数量、容量、能接受几盘故障

1. 数盘位：TrueNAS 理论上能管数百块任意容量的硬盘，只要主机插得下；Unraid 单个阵列最多 30 块盘，且每台服务器只允许一个阵列。
2. 列容量：把每块盘的容量抄下来，尤其注意杂牌旧盘——容量越杂，两套系统的可用空间差距越大。
3. 定冗余底线：Unraid 最多提供两盘冗余；TrueNAS 可以按 vdev（ZFS 里由若干硬盘组成的冗余单元）分组，各组冗余等级不同却汇入同一个存储池。

二、要稳：TrueNAS 按 vdev 规划

1. 选冗余级别：RAIDZ1 容许一块盘故障，相当于 RAID 5；RAIDZ2 容许两块，相当于 RAID 6；RAIDZ3 能同时扛住三块盘故障。
2. 按容量分组建 vdev：假设有 6 块盘，其中 3 块 4TB、3 块 8TB。普通 RAID 会把它们统一按 4TB 计算；ZFS 则可以把 3 块 4TB 组成一个 RAIDZ1 vdev、3 块 8TB 组成另一个，再合并成一个 24TB 的存储池。
3. 注意 RAIDZ1 至少需要 3 块盘才能成组，凑不满的零散盘只能单独使用。

三、要容量自由：Unraid 按阵列加校验盘

1. 阵列里可以混插任意容量的硬盘，容量直接相加，只把最大的一到两块留作校验盘（parity，专门存放校验数据、用于重建故障盘）。
2. 扩容不用重组：拔掉一块 2TB 换上 12TB，直接多出 10TB 可用空间。
3. 阵列之外还能另建多个存储池，用 ZFS、Btrfs 或 XFS 组建都行，但这些池不享受阵列的校验保护。

四、同一批杂盘的两种算法

1. 一批盘为 1 块 12TB、3 块 8TB、2 块 6TB、4 块 4TB 再加 2 块 2TB。按 TrueNAS 的 RAIDZ1 分组，12TB 与 3 块 8TB 一组、2 块 6TB 与 4 块 4TB 一组，6TB 会被按 4TB 计算，2 块 2TB 基本用不上，最终大约 44TB。
2. 同样这批盘交给 Unraid，可得 56TB，其中 12TB 那块充当校验盘。差距就是这么来的。

注意事项

1. Unraid 的校验机制与 RAID 相似但不相同：各盘彼此独立，校验盘只保存计算出的校验块。撰稿人自己那台 12 盘、单校验盘的服务器可扛一块盘故障，但若在重建期间第二块盘也倒下，只有这两块盘上的数据丢失，其余硬盘依然可读。
2. TrueNAS 已支持 Docker，近几年现代化程度提升明显，不必再把它当成只会存文件的老古董。
3. 结论很直接：需要极致冗余和可靠性就上 TrueNAS；喜欢折腾、盘型杂、能接受一到两盘冗余就选 Unraid。别被网上的口水战带走，花几分钟盘清自己的需求更实在。

来源：How-To Geek

一、别手动调低播放画质

1. 播放质量默认保持「Original / 最高」即可。
2. 这个档位代表画质上限，当网络变差时，Plex 会自动下调码率，不需要你手动压低。
3. 一旦把画质写死成某个低值，反而强迫服务器实时转码，白白消耗硬件资源。

对策：局域网内带宽通常够用，不用纠结画质档位；真遇到播放问题，先查网络和线路，而不是降画质。

二、别关掉硬件加速

1. 如果已开通 Plex Pass、服务器又支持硬件加速，请保持开启。
2. 4K 或高清 1080p 要实时转码时，老旧的 CPU 很难扛住，硬件加速靠核显或独立显卡顶上。
3. 只有在转码后画质明显异常时，才考虑关闭，或先调整转码器相关设置；也可以加一张便宜的独显（如 Intel Arc 系列）专门负责转码。

三、别强制 Direct Play / Direct Stream

1. Plex 的播放顺序是 Direct Play → Direct Stream → 转码，自动择优。
2. 如果把转码关掉、强行 Direct Play，结果只会让那些本就需要转码的文件无法播放，并不会变快。

四、别动高级网络与安全设置

1. Plex 通常会自动适配你的局域网，正常情况下跑着就别碰。
2. 真要改，常见的也只有两处：开启离线模式、为远程访问做端口转发。
3. 其余高级网络项，没出问题就别动，改错可能导致媒体库暂时无法串流，还得一项项回退。

注意事项

界面类的个性化（海报、排序、列表样式）随便改都不影响，本文说的是技术、转码、网络这一类。对新手来说，记住一句就够：官方已经调好的默认项，多半比你拍脑袋改的更稳。

来源：How-To Geek

一、适合放在 NAS 上的：数据密集型服务

判断标准很简单：这个服务大部分时间都在读、写、整理或保护 NAS 上的文件。

1. 媒体服务器：Jellyfin、Plex 本就常读 NAS 里的影音，跑在 NAS 上省掉一台机器和一道网络挂载。只要 NAS 的算力够转码，比另起一台更合理。
2. 照片管理、文档归档、下载工具（如 qBittorrent、Transmission）：它们几乎只跟 NAS 里的文件打交道，放在别处徒增网络往返。
3. 备份软件：NAS 本就是集中存重要副本的地方，让它接收、排程、整理或复制备份，是顺理成章的延伸——当然这不意味着 NAS 就是全部备份策略，尤其当原始数据也在上面时。

二、整合能省下的维护成本

家里每多一台常年开机的设备，就多一份更新、监控、备份和「它啥时候挂了」的心智负担。把媒体服务器、几个下载工具和存储类工具并到 NAS 上，既能减负，又把独立硬件留给真正需要的活儿。排错也更省事：应用主要跟 NAS 数据打交道时，出问题只需在 NAS 一台机器上理清应用、权限、存储，不必先跨三台设备追同一处故障。

三、必须留在 NAS 之外的：需要独立存活的服务

诱惑往往从这开始：媒体服务器装完，又加一个容器，再加一个，NAS 眼看要吞下半个数家庭实验室。硬件能跑，不等于该跑。划线的标准是：NAS 宕机时，你还需不需要它。

1. 基础设施类：比如 DNS。若全屋 DNS 只跑在 NAS 上，一次例行维护就会从「存储问题」升级成「网络问题」。管理、监控类工具同理——你正排查 NAS 故障时，恰恰需要它们还在线。
2. 重计算类：大型虚拟机、开发环境、数据库等会和存储服务抢 CPU、内存与磁盘 I/O；当不得不为这些不相关的程序让路、绕着排期做存储维护时，整合就已经过头了。

四、一条好用的判断口诀

问一句：NAS 要是掉线，这项服务会不会也把「排查网络／恢复系统」所需的能力一起带走？会，就挪到别处；不会，就留下。对多数家庭用户，一台 NAS 配一台小型辅助机，就足以在「存储相关应用」和「基础设施／实验／重计算」之间划出边界——既保留整合的便利，又不让所有鸡蛋落在同一个篮子里。

注意事项

群晖 DSM、威联通或绿联等主流 NAS 都提供容器管理器（套件中心／Container Station／Container Manager），上述思路与具体品牌无关。整合的甜头是省机器、省电、易维护；底线是别让 NAS 变成「牵一发而动全身」的单一依赖。让 NAS 做好它擅长的事，比把它塞成全能服务器更稳妥。

来源：XDA Developers

这位作者的家庭服务器最早围绕一台联想 RD440 机架式服务器搭建，Unraid 一肩挑起存储、虚拟机与 Docker 三件事。在 2021 年那个时间点，TrueNAS 的稳定版还没有今天这样完善的 Docker 支持，原有的 jail 机制也远不如 Unraid 上的 Docker 好用，于是 Unraid 成了「什么都让一套系统搞定」的自然选择。

Unraid 曾是全能选手

客观地说，Unraid 作为存储平台表现相当出色，把存储、Docker 和虚拟机整合在一起，对刚接触容器的新手也很友好。作者坦言，正是在 Unraid 的图形界面里第一次用上了 Docker，比直接扑进 Docker Compose 或命令行要平缓得多。

但「能做某事」不代表「适合做每件事」。随着使用深入，作者想要的容器功能越来越多，Unraid 在不少地方把简单任务变得不必要地麻烦，尤其是当需求超出它预设的模板时。

卡在「应用模板」上

Unraid 的「应用模板」需要由社区或容器维护者手动提交，并非自动生成。作者开始遇到想用的容器却没有对应模板，只能手工凑配置，过程相当痛苦。模板本身虽好用，但修改起来往往比帮忙更添堵。

更烦人的是查找成本：在社区仓库里搜一个容器，可能冒出十几个看似相同的模板，有时标「官方」有时又不标，挑出最合适的一个成了日常消耗。相比之下，直接从维护者的 GitHub 仓库拿官方的 Compose 文件或镜像，定位反而清晰得多。

换回 Ubuntu 后打开了门

作者使用 Ubuntu Server 已超过十五年，命令行环境最为熟悉，迁移到 Ubuntu 跑 Docker 是顺理成章的决定。Ubuntu 原生支持 Docker，几乎每个主流容器都自带 Compose 文件，没有就用手写或 Portainer 补全，不必再受模板有无的制约。

迁移带来的直接好处是「几乎任何容器都能跑」，而且运行更稳定。对需要精细控制网络、存储卷和依赖关系的服务来说，直接用维护者提供的清单部署，比在模板系统里反复试错省心得多。

把家庭服务器拆开管

这篇文章给出的核心经验，是把家庭服务器按职责拆开：存储这件 Unraid 擅长的事继续交给它，Docker 编排这件 Ubuntu 擅长的事交给 Ubuntu。作者表示，正是因为 2025 年初把 Docker 从 Unraid 迁到 Ubuntu Server，家庭服务器才真正「起飞」，这是他为整套系统做过最对的一个决定。

对正在权衡家庭服务器架构的玩家，这未必是「Unraid 不如 Ubuntu」的结论，而是一次关于职责分离的提醒：当一套全能系统开始拖慢特定需求时，把最吃力的那块拆出去，往往比硬扛更划算。

来源：How-To Geek，作者 Patrick Campanale

网络没问题，问题在盘。

两块盘做镜像，读速不会翻倍

他的阵列是两块 20TB 硬盘组 SHR，效果等同 RAID 1。写入时每份数据要同时落到两块盘，上限被压在 290 MB/s 左右，只有万兆链路的两成。

反直觉的是读取。很多人以为两份数据在手，读就该翻倍——并不会。Linux 内核开发者二十年前就说清楚了：单个顺序读只从一个镜像成员取数据，读均衡只在多个客户端同时拉数据时才生效。一个人拷大文件，就是一块盘在干活。

他用 SSH 跑了 64GB 直接 I/O 实测，绕开缓存和网络开销：持续写 259 MB/s，持续读 274 MB/s。而且这是硬盘只用了 6% 时的成绩，走的是最快的外圈，盘越满只会越慢。

协议和 CPU 也在拖后腿

SMB 复制单个文件走的是单条 TCP 流、单个 CPU 核心，SMB Multichannel 要 DSM 7.2 之后才有，而这台机器只有一个万兆口，其余都是千兆。他改用 2.5GbE 主板网口测，iperf3 能跑到 296 MB/s，CrystalDiskMark 单队列读却只有 277 MB/s——连 2.5G 都没吃满。随机 4K 读更是只剩 4.5 MB/s。

常被推荐的巨型帧他早试过：现代硬件几乎无感，MTU 9000 只配一半反而搞坏一堆东西，最后退回 1500。

便宜 NAS 还有一堵墙立在 CPU。这台用四核至强 D-1527 加 32GB 内存，CPU 不是瓶颈；而多数消费级 NAS 用 Arm、N100、N150、赛扬或嵌入式 Ryzen，论坛普遍反馈 300 到 700 MB/s。一旦为静态数据开加密、启用 AES-CMAC 签名，读吞吐能掉到 100 MB/s 以下。

想吃满万兆，先看盘

六个盘位塞满做 RAID5 或 SHR，顺序读能到 700–900 MB/s，只是校验写入慢一截；真要跑满链路，得整套上 SATA 固态。先算硬盘能给多少，再决定网口买多快。

来源：XDA Developers

先看盘数，别看盘位

小容量盘这轮涨得最难看。1TB、2TB 乃至 4TB 的每 TB 单价明显恶化，用一把小盘塞满机箱，如今比上一两块大盘贵得多。

代价是颗粒度。冗余由校验级别决定，不由盘数决定，换大盘不削弱冗余；但一块 20TB 盘挂掉，对阵列的冲击远大于 4TB，重建也慢得多，而重建从来不是零风险。这笔账仍划算，只是会把你推向 RAIDZ2，而非只容忍单盘故障的方案。

冗余成了新的税

盘价翻倍，冗余成本跟着翻倍。双盘镜像里冗余本就占入门成本一半，扩容还得成对买，每买一对只换来一块盘的可用容量——这是眼下每加一 TB 最贵的方式。

二手企业盘更实际

RAIDZ 扩容已随 OpenZFS 2.3 落地并进入 Proxmox 9，故意空着的盘位终于能用：单块盘可挂进现有 RAIDZ vdev。但扩容前写入的数据仍保留原校验比例，立刻拿到的可用空间比预想的少，要等数据重写才逐步收敛。

真正扛住涨价的是二手企业盘。新盘在零售端要和数据中心采购单抢产能，零售每次都输；翻新的 Ultrastar、Exos 走另一条供应链，卖家测试后重新质保、公开 SMART 数据，仍是大容量存储性价比最高的一档。配 HBA 卡还能同时看 SATA 和 SAS——多数人被主板或硬盘盒限死在 SATA，SAS 库存买家更少，更容易捡到合理价。

我的判断是这轮涨价短期不会回头。真要动手，先把冗余单独算一遍价，再决定五到十年后想要的容量值不值得现在买单。

来源：XDA Developers

问题核心在于一个听起来很枯燥的指标：不可恢复读错误率，英文缩写 URE。消费级 SATA 硬盘通常标称每读取 10^14 位（约 12.5TB）数据，就可能遇到一次读不出的坏扇区。企业级硬盘稍好，大约是 10^15 位，也就是 125TB。这个指标在过去二十年里几乎没怎么变，而硬盘容量却从几百 GB 一路涨到了几十 TB。

当年 RAID 5 重建一块 500GB 硬盘，控制器只需要从其他盘里读几百 GB 数据，几个小时就能跑完。重建窗口短，坏第二块盘的概率基本可以忽略。可如今坏了一块 16TB 硬盘，阵列进入降级状态后，控制器必须完整读取每一块幸存盘的全部表面数据——可能是 12 小时到数天不等，期间所有盘都在接近 100% 的负载下狂奔。只要在这期间任意一块幸存盘弹出一个 URE，对应条带就无法重建，严重时整个重建直接失败。

换句话说，RAID 5 的设计逻辑没变，但硬盘容量把它拖进了一个数学陷阱：重建所需读取的数据总量，已经远超消费级硬盘的 URE 规格。

这个观点并非今天才有。2007 年，存储分析师 Robin Harris 在 ZDNet 上发表了一篇后来被视为经典的文章，标题就叫《Why RAID 5 stops working in 2009》，核心论断正是：容量持续增长，URE 不变，RAID 5 迟早会在重建时翻车。

不过现实比最坏的概率模型要温和一些。微软曾经用廉价硬件刷过约 2PB 数据，实际遇到的读错误远低于厂商标称值。所以“RAID 5 已死”的说法有些夸大，但“RAID 5 变得很脆弱”却毫不夸张。

更隐蔽的风险是同批次老化。很多企业或家庭 NAS 里的硬盘是一次性采购、同一型号、同一批次，服役年限和磨损状态高度同步。当第一块盘因老化去世，剩下的盘本来就站在故障边缘，而重建过程的高强度读写，往往会把下一块“亚健康”的盘直接送走。这才是 RAID 5 在现实中屡屡翻车的真正原因。

那应该怎么选？如果数据重要，且用的是 8TB 以上的大容量机械硬盘，RAID 6、RAIDZ2 或 RAID-DP 这类双校验方案才是更稳妥的默认选择。双校验意味着重建时即便再碰到一个 URE，也能从另一个校验中恢复出来。RAID 5 并没有死透，但在大容量硬盘时代，它已经不适合作为关键数据的唯一防线。

来源：How-To Geek / Monica J. White

这个判断的前提是——那句被重复了很多年的建议，是十年前的技术条件下得出的。

NAS 的核心优势，多数人用不上

网络存储的价值就写在名字里：文件通过网络共享。这对办公室、创意团队，以及一家人整天都要访问同一批文件的场景确实成立。

但多数人不是这么用的。活跃项目在笔记本上，游戏、文档和应用装在台式机上。就算你手里有好几台设备，同一时间通常也只在用其中一台。”在每台设备上打开同一个文件夹”听着很美，直到你意识到自己几乎从不这么做。

更容易被忽略的是维护成本。NAS 不只是一个装硬盘的盒子，它是挂在你家网络上的另一台电脑：有自己的操作系统、安全更新、存储池、监控工具和维护周期。这些事单拎出来都不难，但每一件都要占用你一点注意力，日积月累就不轻松了。直连式存储把这些全省了——插到电脑上，格式化，开始用。

速度这个老论据，已经不成立了

反对外接存储最有力的理由曾经是慢。十年前，用移动硬盘剪照片、编译代码、处理大体积视频工程，确实是折磨，这个批评当时完全站得住脚。

今天不一样了。USB4 和雷雳接口提供的带宽足够高，一个好的固态硬盘盒在日常使用中的手感已经很接近内置硬盘。拷贝几百 GB 不再需要围着进度条安排一下午，大体量照片库能快速载入，软件工程构建没有明显延迟，虚拟机跑在外接硬盘上也不会让人觉得卡。

再加上固态硬盘本身还在变快、单价也比 NAS 专用机械盘更容易接受。把一个多盘位硬盘盒配上几块固态，对多数桌面工作负载来说，内外置的性能差距已经很小。反倒是不少入门级 NAS，处理器和网口性能有限，往往比固态硬盘更早成为瓶颈。

钱花在了哪里

买 NAS 时最少被讨论的一点，是预算的真实去向。一部分买的是机箱，但相当大的比例付给了处理器、内存、主板、散热、网络硬件、操作系统、软件生态，以及厂商多年的持续开发。这些部件都是必需的，因为 NAS 被设计成一台能独立运转的服务器。

如果目标只是尽可能快地存文件，这些开销并不会直接变成容量。同样的钱花在直连式存储上，更大比例可以投入到更大或更好的硬盘上，而不是那些主要用来”管理存储”的硬件。

低延迟比大容量更影响体验

机械硬盘每 TB 的价格仍然最低，这是它至今大量出现在 NAS 里的原因，用来存放不常访问的大体量归档依然合理。但日常使用完全是另一种感受。

打开上千张照片、索引代码仓库、浏览媒体库、启动虚拟机、在大文件夹里搜索——这些操作受益于低延迟的程度，远高于受益于顺序读写速度。而它们几乎覆盖了你和文件之间的每一次交互。

体验上还有个附带好处：固态硬盘没有寻道噪音，发热更低，功耗也更小。如果存储就摆在你办公的这张桌子上，用几周之后这些细节会比想象中更明显。

RAID 从来不是备份

很多人给自己买 NAS 找的理由是 RAID（磁盘冗余阵列）。RAID 的价值毋庸置疑，但它经常被误解：冗余保护的是硬件故障，它不保护你免于误删重要文件、恶意软件加密文档、数据损坏、失窃、火灾，以及生活时不时安排的其他意外。

不管文件放在 NAS 还是直连硬盘里，它们都需要一套像样的备份方案。与其因为相信”有 RAID 就安全”而买台 NAS，不如买个快速的固态直连存储，把剩下的预算投到一套靠谱的备份上。前一种做法给的往往只是心理安慰。

什么时候该买 NAS

原文并没有全盘否定。家庭共享存储、持续的媒体串流、多台电脑自动备份、远程访问、虚拟化、小型团队协作——这些需求交给集中式网络存储处理，效果都非常好，NAS 在这些场景里依然是最优解。

问题只在于，不该默认所有人都有这些需求。

我的判断是，这个反转的本质是接口带宽和固态硬盘价格这两件事同时发生了变化，把一条老经验的成立条件抽掉了。选存储之前先诚实回答一个问题：过去半年里，你真的有几次需要从另一台设备访问同一个文件夹？如果答案是个位数，那笔多出来的预算，放在硬盘和备份上更划算。

你家里那台 NAS，现在多久开机一次？

来源：How-To Geek（作者 Umair Khurshid）