企业官网建设流程全解析

1. 从一台群晖说起：为什么存储这件事值得重新聊一遍

手里这台群晖 DS223j 是去年双十一入的，两盘位，配了两块 4TB 红盘，组了 SHR。当时想法很简单，就是给家里的照片和文档找个安稳的地方放着，顺便把手机相册自动备份关掉那些烦人的云盘会员续费。结果用了不到三个月，这台小机器的角色就彻底变了——它成了我家里的下载中心、影音库、代码仓库、数据库测试机，甚至跑过一段时间轻量级的深度学习推理任务。

我猜很多人的路径跟我差不多。一开始只是想买个 NAS 存东西，用着用着发现这玩意儿本质上就是一台低功耗的小型服务器，能折腾的事情远比想象中多。而这两年存储领域的变化也很有意思：一边是群晖、威联通这些传统 NAS 厂商在软件生态上越做越深，另一边是飞牛 NAS、各种盒子刷机方案把入门门槛拉得越来越低，再加上 MinIO 这类分布式对象存储在下沉到个人和小团队场景，整个“存储”的概念已经从“找个地方放文件”演变成了“数据底座加算力入口”。

这篇内容我想聊的不是某个单一产品的开箱或者教程，而是把群晖作为切入点，把 NAS、存储、人工智能、深度学习这几个关键词串起来，讲讲我实际踩过的路。适合谁看？如果你手里已经有一台 NAS 或者正打算入一台，想知道它除了存文件还能干什么，那这篇应该对你有用。如果你对分布式存储、对象存储、AI 训练数据管理这些稍微偏专业的方向感兴趣，我也会把我在小规模环境里验证过的方案和参数选择逻辑写清楚。

先给一个整体判断：家用 NAS 完全可以当小型服务器用，但前提是你得想清楚它的性能边界在哪里，以及你愿意为稳定性付出多少折腾成本。下面我按几个层面来拆。

2. 群晖的核心价值到底在哪：硬件之外的软件护城河

2.1 为什么同价位下群晖的硬件看起来总是“不划算”

先摆一个事实：DS223j 用的是 Realtek RTD1619B 四核 ARM 处理器，2GB 内存不可扩展，千兆网口只有一个。同样一千多块的价格，你要是去买二手 x86 小主机，能拿到 N100 加 8GB 内存加双盘位甚至四盘位的配置。单看纸面参数，群晖确实没什么性价比可言。

但实际用下来，硬件只是入场券，真正让你留下来的是 DSM 这套系统。我举几个具体的点：

• 存储池和卷的管理逻辑足够傻瓜化。SHR 这种混合 RAID 方案对小白极其友好，你插不同容量的盘进去，它会自动帮你算出可用的冗余方案，不用去记 RAID 0/1/5/6 的区别。我试过在 PVE 里手动组 ZFS 池，光是 ashift 和 recordsize 这两个参数就查了半天资料。
• 套件生态的完整性。Synology Photos 的人脸识别和场景分类、Drive 的增量同步、Hyper Backup 的多版本备份、Container Manager 的 Docker 管理界面，这些东西你单独拿出来都能找到替代品，但整合在一个界面里、互相之间能打通的体验，自己搭全套至少要花一个周末。
• 系统更新的持续性。我有一台 2016 年的 DS216j 到现在还能收到安全更新，虽然功能上已经停更了，但基础的文件服务和备份功能一直稳定运行。这一点在自组方案里很难保证，Debian 大版本升级一次你可能就要重装一遍。

所以我的看法是：群晖的溢价买的是软件成熟度和时间成本。如果你愿意花时间折腾，自组方案确实更划算；如果你更看重“装好就不管了”，那群晖的定价逻辑是成立的。

2.2 DSM 7.x 之后值得关注的几个变化

DSM 7 刚出来的时候骂声不少，主要是对第三方硬盘的兼容性限制和对 root 权限的收紧。但用到现在，有几个变化我觉得是正向的：

Container Manager 取代了原来的 Docker 套件，界面更清晰，支持 docker-compose 导入，项目化的管理方式比之前一个个容器手动配置要舒服得多。我现在跑 MinIO、MySQL、Redis 这些服务都是通过 Container Manager 管理，配合 Watchtower 做自动更新，基本不用管。

Synology Photos 的 AI 能力在逐步增强。人物识别、场景分类、地点聚类这些功能在本地完成，不需要上传到云端。对于我这种有大量家庭照片又不想传到第三方平台的人来说，这是刚需。识别准确率嘛，说实话一般，尤其是小孩的照片经常认错，但作为初筛工具够用了。

SSH 权限的管理更严格了。DSM 7 默认禁用 root 登录，需要用 admin 账户 sudo 提权。这个变化一开始很不习惯，但客观上提升了安全性。我现在的做法是创建一个专用的管理账户，配置 SSH 密钥登录，禁用密码认证，日常操作全部通过这个账户 sudo 执行。

注意：DSM 7 之后很多第三方套件需要手动信任发布者才能安装，这是 Synology 收紧生态控制的信号。如果你依赖某些社区套件，升级前先确认兼容性。

3. NAS 当小型服务器用：性能边界和实际能跑什么

3.1 ARM 机型和 x86 机型的实际差距

“家用 NAS 可以当成小型服务器用吗”这个问题，答案取决于你买的是什么机型。我用 DS223j（ARM）和朋友的 DS923+（AMD Ryzen）做过一些对比测试，差距比想象中大：

结论很明确：ARM 机型适合文件服务加少量轻量容器，x86 机型才有资格谈“小型服务器”。如果你有跑数据库、做开发测试、跑 AI 推理的需求，直接上 x86 机型，别在 ARM 上浪费时间。

3.2 我在群晖上实际跑过的服务清单

说说我目前在这台 DS223j 上稳定运行的服务，以及一些踩过的坑：

MinIO 对象存储。这是我最推荐在 NAS 上跑的服务之一。MinIO 兼容 S3 API，可以用来做本地对象存储，配合各种备份工具和开发框架都很方便。在群晖上通过 Container Manager 部署很简单，关键是存储路径要映射到 NAS 的卷上，不要放在容器内部。我一开始把数据放在容器卷里，结果一次容器重建数据全丢了，血的教训。

MySQL 数据库。群晖套件中心有 MariaDB 可以装，但我更推荐用 Docker 跑 MySQL 8。原因是套件版的版本更新慢，而且和系统耦合太深。Docker 版可以自由选择版本，配置也灵活。不过 ARM 机型上 MySQL 的性能确实一般，简单查询没问题，复杂 JOIN 会明显卡顿。

Synology Drive 做同步中心。这个算是群晖的杀手级应用了。我在几台设备之间同步代码和文档，Drive 的增量同步做得不错，冲突处理也比想象中好。配合 Cloud Sync 可以把重要数据再备份一份到对象存储，形成 3-2-1 备份策略的雏形。

Lucky 做自动更新证书和反向代理。Lucky 是一个国产的开源工具，支持自动申请和续期证书、反向代理、端口转发等功能。在群晖上通过 Docker 部署，配合 DDNS 可以实现外网访问时的 HTTPS 加密。配置逻辑比 Nginx Proxy Manager 更符合国内用户习惯，证书自动续期这块做得很省心。

实操心得：在群晖上跑 Docker 服务，一定要把数据目录映射到 NAS 的存储卷上，不要用 Docker 的匿名卷。群晖的系统分区容量有限，容器数据写多了会撑爆系统盘，到时候只能重装。

3.3 存储池的创建和扩容：SSH 下的一些操作

群晖的图形界面创建存储池很简单，但有些操作在界面上做不了，需要 SSH 进去。比如查看存储池的详细状态、手动触发 scrub、调整某些参数。

查看存储池状态：

# 查看所有存储池 cat /proc/mdstat # 查看 btrfs 文件系统使用情况 btrfs filesystem usage /volume1 # 查看存储池详细信息 synostorage --info

扩容存储池的时候有个坑：如果你用的是 SHR，替换硬盘后需要手动触发重建。图形界面会提示你，但重建过程中不要断电，也不要同时替换多块盘。我试过一次同时换两块盘，结果重建了整整两天，期间 NAS 性能下降明显。

另外，Btrfs 的快照功能值得用起来。群晖的 Snapshot Replication 套件可以给共享文件夹做定时快照，配合 Btrfs 的写时复制机制，快照几乎不占额外空间。我设置了每天凌晨做一次快照，保留 30 天。有一次误删了重要文件，直接从快照里恢复，五分钟搞定。

4. 从存储到智能：NAS 在 AI 和深度学习场景中的角色

4.1 为什么 NAS 是 AI 训练数据管理的天然载体

搞深度学习的都知道，数据管理是个大问题。一个中等规模的数据集动辄几百 GB 到几 TB，放在本地 SSD 上成本太高，放在云上又贵又不方便。NAS 在这个环节里的定位很清晰：它是训练数据的集中存储和版本管理中心。

我目前的流程是这样的：原始数据先落到 NAS 上，用 Btrfs 快照做版本标记；预处理后的数据放在另一个共享文件夹里，通过 NFS 挂载到训练服务器上；训练过程中的 checkpoint 和日志实时写回 NAS。这样做的好处是：

• 数据集中管理，不会出现“这个数据集在哪台机器上”的问题
• 快照机制可以追溯数据版本，实验可复现
• NFS 挂载对训练框架透明，代码里直接写路径就行
• 训练完的模型文件自动备份，不怕本地磁盘挂掉

在群晖上配置 NFS 共享很简单，控制面板里开启 NFS 服务，然后给共享文件夹配置 NFS 权限就行。训练服务器上挂载：

# 挂载 NAS 上的数据集目录 sudo mount -t nfs 192.168.1.100:/volume1/datasets /mnt/datasets # 写入 /etc/fstab 实现开机自动挂载 192.168.1.100:/volume1/datasets /mnt/datasets nfs defaults 0 0

注意：NFS 的性能受网络影响很大。千兆网络下顺序读取大概 110 MB/s，对于小文件多的数据集（比如 ImageNet）会比较吃力。如果条件允许，上 2.5G 或万兆网卡，体验会好很多。

4.2 将计算成像的物理先验整合到深度学习流程：一个具体案例

热词里有一条“将计算成像系统的物理先验知识整合到深度学习流程的各个组成部分”，这个方向我恰好做过一些实验，可以展开说说。

计算成像的核心思路是用计算的方式替代部分光学元件，比如用编码孔径代替透镜、用算法重建代替直接成像。物理先验在这里的作用是约束解空间，让网络不至于学出违反物理规律的解。

我做的实验是基于压缩感知的单像素成像重建。物理模型很简单：测量值 y = Φx + n，其中 Φ 是测量矩阵，x 是原始图像。传统方法用 TV 正则化求解，深度学习方法直接学一个从 y 到 x 的映射。

把物理先验整合进去的方式有几种：

第一种是数据层面。训练数据不是随机生成的，而是根据物理模型仿真出来的。测量矩阵的选择、噪声模型、采样率都要和实际系统匹配。这一步看起来简单，但很多人忽略，导致训出来的模型在实际系统上表现很差。

第二种是网络结构层面。把物理模型展开成网络层，比如把 ISTA 算法展开成 LISTA 网络，每一层对应一次迭代。这样网络结构本身就编码了物理先验，泛化能力比黑盒网络强很多。

第三种是损失函数层面。除了重建误差，再加上物理一致性约束。比如重建结果经过同样的测量过程后，应该和原始测量值一致。

我的实验结论是：物理先验整合得越深，需要的训练数据越少，泛化能力越强。纯数据驱动的网络需要几万张训练图，整合了物理先验之后几千张就能达到类似效果。这个思路在数据获取成本高的场景下特别有价值。

4.3 在 NAS 上管理深度学习数据集的实操细节

具体到操作层面，我在 NAS 上管理数据集的做法是这样的：

目录结构设计。我习惯按项目分顶层目录，每个项目下面再分 raw、processed、checkpoints、logs 四个子目录。raw 存原始数据，只读；processed 存预处理后的数据，可以重新生成；checkpoints 存训练中间结果；logs 存训练日志。

/volume1/datasets/ ├── project_a/ │ ├── raw/ │ ├── processed/ │ ├── checkpoints/ │ └── logs/ └── project_b/ ├── raw/ ├── processed/ ├── checkpoints/ └── logs/

权限管理。raw 目录设为只读，防止误操作。processed 和 checkpoints 可读写。通过群晖的用户组功能，给不同的团队成员分配不同权限。

快照策略。raw 目录每天做一次快照，保留 7 天；processed 目录每周做一次，保留 4 周；checkpoints 不做快照，因为体积大且可重新生成。

传输优化。大文件传输用 rsync 而不是 SMB，支持断点续传和校验。小文件多的情况先打包成 tar 再传，到了之后再解压。

# 用 rsync 同步数据集到 NAS rsync -avz --progress --partial /local/datasets/ admin@192.168.1.100:/volume1/datasets/ # 打包小文件后传输 tar czf dataset.tar.gz /local/dataset/ scp dataset.tar.gz admin@192.168.1.100:/volume1/datasets/

5. 分布式存储和对象存储：什么时候需要，怎么选

5.1 MinIO 在单机 NAS 上的部署和调优

MinIO 是我在 NAS 上跑得最满意的服务之一。它提供 S3 兼容的对象存储接口，可以用来做备份目标、静态资源存储、甚至作为某些应用的存储后端。

在群晖上部署 MinIO 的 docker-compose 配置：

version: '3' services: minio: image: minio/minio:latest container_name: minio ports: - "9000:9000" - "9001:9001" environment: MINIO_ROOT_USER: your_admin_user MINIO_ROOT_PASSWORD: your_strong_password volumes: - /volume1/docker/minio/data:/data command: server /data --console-address ":9001" restart: unless-stopped

几个关键点：

数据目录必须映射到 NAS 卷上。我见过太多人把数据放在 Docker 的匿名卷里，结果容器一重建数据就没了。映射到/volume1/docker/minio/data这样的路径，数据持久化才有保障。

密码要足够强。MinIO 默认要求密码至少 8 位，但实际使用中建议 16 位以上，包含大小写和特殊字符。因为一旦暴露到公网，弱密码分分钟被爆破。

控制台端口单独暴露。9000 是 API 端口，9001 是控制台端口。控制台不要暴露到公网，只在内网访问，API 端口如果需要外网访问，一定要配 HTTPS。

性能调优。单机 MinIO 的性能瓶颈主要在磁盘 IO。如果 NAS 支持 SSD 缓存，把 MinIO 的元数据放在 SSD 上会明显提升小文件读写性能。另外，MinIO 的 erasure coding 在单机模式下意义不大，直接用默认配置就行。

5.2 分布式存储在小规模场景下的取舍

“分布式存储”这个词听起来很高大上，但实际落地的时候要考虑清楚：你真的需要分布式吗？

分布式存储解决的核心问题是：单点故障、容量扩展、性能聚合。但代价是复杂度上升、运维成本增加、一致性模型变复杂。

我的判断标准是这样的：

对于绝大多数家用和小团队场景，单机 NAS 加外部备份已经足够。分布式存储的复杂度在规模不够大的时候反而是负担。我见过有人在家里搭了三节点 Ceph 集群，结果每个月电费比云存储还贵，维护成本更是没法算。

5.3 PVE 共享存储的配置思路

如果你在用 Proxmox VE 做虚拟化，NAS 可以作为共享存储提供给 PVE 集群。这样虚拟机可以在不同节点之间迁移，提高可用性。

PVE 支持多种共享存储类型，NAS 常用的有 NFS 和 iSCSI：

NFS 方式适合存放 ISO 镜像、虚拟机磁盘文件、备份文件。配置简单，性能取决于网络。

iSCSI 方式适合需要块设备语义的场景，比如给虚拟机直接挂载 LUN。性能比 NFS 好，但配置复杂一些。

在 PVE 上添加 NFS 存储：

# 在 PVE 节点上挂载 NFS pvesm add nfs nas-storage --server 192.168.1.100 --export /volume1/pve --content iso,vztmpl,backup,images # 查看存储状态 pvesm status

注意：PVE 集群使用共享存储时，所有节点都必须能访问同一个存储路径。NFS 的挂载参数要一致，否则会出现锁竞争问题。另外，群晖的 NFS 实现和 Linux 内核的 NFS 客户端在某些参数上可能有兼容性问题，建议先用测试环境验证。

6. 常见问题与排查技巧实录

6.1 群晖使用中的高频问题速查

6.2 几个我踩过的坑和解决方法

坑一：Docker 容器数据写满系统分区。群晖的系统分区只有 2GB 左右，Docker 的镜像和容器层默认写在系统分区。跑几个容器之后系统分区就满了，DSM 直接卡死。解决方法是在 Container Manager 的设置里把 Docker 的存储位置改到 NAS 卷上，或者用符号链接把/var/packages/ContainerManager/target指向大容量卷。

坑二：SHR 扩容时同时换两块盘。我以为同时换两块盘会更快，结果重建过程中两块盘同时参与重建，IO 压力翻倍，NAS 响应极慢，而且如果这时候再坏一块盘就全完了。正确做法是一次只换一块，等重建完成后再换下一块。

坑三：NFS 挂载后训练速度慢。一开始以为是网络问题，换了万兆网卡还是慢。后来发现是 NFS 的 rsize/wsize 参数默认值太小，调整到 1MB 之后速度提升明显。挂载参数改成rsize=1048576,wsize=1048576。

坑四：MinIO 密码泄露。有一次不小心把 MinIO 的 API 端口暴露到了公网，而且密码设得比较简单，第二天就发现被人扫到了，开始往里面传垃圾文件。幸好发现得早，没有造成数据损失。之后我把 API 端口也收回了内网，外网访问全部走反向代理加认证。

坑五：Btrfs 快照导致空间不足。快照本身不占空间，但如果原始数据变动频繁，快照会保留旧版本的数据块，导致实际占用空间增加。我设置了每天快照保留 30 天，结果一个月后存储池使用率从 60% 涨到了 85%。后来改成每天快照保留 7 天，每周快照保留 4 周，空间就稳定了。

6.3 性能优化的几个实用技巧

启用 SSD 缓存。如果 NAS 有空余的 M.2 插槽，加一块 NVMe SSD 做读写缓存，对小文件读写性能提升明显。注意读写缓存需要两块 SSD 做 RAID 1，否则缓存盘故障会导致数据丢失。

调整 SMB 协议版本。群晖默认启用 SMB 2 和 SMB 3，如果客户端都支持 SMB 3，可以禁用 SMB 1 和 SMB 2，减少协议协商开销。在控制面板的文件服务里可以设置。

启用 Jumbo Frame。如果整个网络链路都支持，把 MTU 调到 9000 可以减少大包传输时的 CPU 开销。但要注意，只要有一个设备不支持，就会出现丢包和性能下降。

定期做存储池 scrub。Btrfs 的 scrub 会校验所有数据块的校验和，发现并修复静默损坏。建议每月做一次，放在夜间执行，避免影响日常使用。

7. 一些个人体会和后续可以折腾的方向

写到这里，我想起最开始买 NAS 的时候，朋友跟我说“你就当买个硬盘盒，别折腾”。结果现在这台小机器承担了我家里几乎所有的数据服务，从照片备份到代码仓库，从影音库到 AI 训练数据管理。它确实不是性能最强的设备，但胜在稳定、省心、功耗低。

如果你问我下一步会折腾什么，我可能会试试把更多的 AI 推理任务放到 NAS 上。现在有一些轻量级的推理框架可以在 ARM 上跑小模型，比如图像分类、目标检测这些。虽然性能有限，但对于一些常驻的、低频率的推理任务，放在 NAS 上比单独开一台机器要省电得多。

另外，分布式存储这块我也在关注。等以后数据量再大一些，可能会考虑用两台 NAS 组一个简单的分布式存储，用 MinIO 的分布式模式或者 Synology 的 ShareSync 做节点间同步。不过目前来看，单机加外部备份的方案还能撑很久。

最后分享一个小技巧：群晖的定时任务可以执行自定义脚本。在控制面板的任务计划里添加一个触发的脚本，可以实现很多自动化操作，比如定时清理日志、定时同步数据、定时检查服务状态。我设置了一个每天凌晨执行的脚本，自动清理 7 天前的日志文件，检查所有 Docker 容器状态，如果有异常就发邮件通知。这个脚本帮我省了不少手动检查的时间。