黑群晖配置

阅读时间：4 分钟

之前的文件管理一直用 NextCloud ，虽然不好描述，但总感觉差点意思。 最近开了个新的 esxi 虚拟机测试群晖系统，体验确实要好上不少，这里记录一些问题。

安装

安装这块主要是跟随 GXNAS 上的这篇教程 完成的，这里的网盘也存了需要的文件。 简单概括一下流程：

  1. 准备安装包、引导镜像和镜像格式转换器
  2. 修改引导镜像 grub.cfg 里面的 mac 地址和 sn 码
  3. 将引导镜像从 img 转换成 esxi 支持的 vmdk 格式 - 要选择 non growable
  4. 创建空虚拟机，添加引导镜像的硬盘和一块空硬盘，配置网卡等
  5. 启动虚拟机，在 5000 端口执行安装操作，过程中需要上传安装包

流程中遇到的一些问题：

第三步如果用的是新版 V2V Converter 的话需要选择 non growable 的 vmdk ，否则会转换失败。

第五步两次遇到启动之后无法访问服务的现象。 第一次在 esxi 看到 CPU 利用率只起来一两分钟就又下去了，但是看不到日志，猜测是哪里出了问题。 在网上找了下，要允许修改网卡 mac 地址，在 esxi 的 网络->VM Network->编辑设置->安全 处打开对应的选项。 第二次启动之后 CPU 利用率一直有 30%但是等了四十多分钟还是没动静，试着在虚拟机配置里把网卡的适配器类型从 vmxnet3 改成 E1000e，之后再重启，两分钟就启动成功了。

之前还看到有坑说安装过程要断网，所以提前 ban 了对应 ip 的网络，不知道不这么做的话会不会有坑。

洗白

直接淘宝十来块买了个洗白码，包含一个 sn 和两个 mac 地址，在安装的第二步修改过了。 商家提醒对于需要登录群晖账号的应用，要用国际区账号，不然会被 ban 。 所以注册了美区账号，开机之后对应的应用都能正常使用。 只有 QuickConnect 不能用，不过可以用 DDNS 解决。

配置

目录共享

群晖自带了文件服务，在 控制面板->文件服务 可以看到，通常 SMB 服务就可以在 Windows 上面无缝使用了。

Synology Photos

Photos 应用的功能挺完善的，可以给图片单个或批量打标签加描述，可以按照元信息搜索，可以用不同的标签组合出虚拟相册，基本满足我的管理需求。 不过比较烦人的一点是不支持自定义相片的物理路径，只能使用预设的 /homes/user/photos 。 这对 Lightroom 等以前就维护过自己的目录结构的场景非常不友好。 这个问题在网上被讨论了无数次 （to name a few, Photos Station forces you to use a specific folder? Really? | Importing existing photo files into synology photos without copy on btrfs | Change default Photos folder? | 群晖更新 DSM7.0 后，synology photos 如何正确快速迁移好原有图片，方便使用？ | How to point Photo Station to existing folder），目前来看这个不支持是事实而且不能指望群晖支持了。 大家的方案主要有三个：

  1. 软链接，这个被证实不行，群晖的各类应用不认
  2. mount ，这个有一部分人不行，有一部分可以
  3. 借助 Btrfs 的特性，拷贝文件但是不额外占用空间，缺点是源文件夹的修改不会同步过来

只有方案 2 最靠谱，尝试了一下跑通了，首先在 控制面板->终端机和 SNMP 开启 SSH 访问，然后用群晖的用户名密码登录上去，把对应的目录给 mount 到 photos 下面：

sudo mount --bind /var/services/homes/<user>/<your-photos> /var/services/homes/<user>/Photos/<your-photos>

之后在群晖界面内检查是否成功。 如果没问题，就在添加一个任务计划，每次启动时以 root 身份执行上述指令进行 mount 。

备份

在本地做 raid 冗余或者定期离线备份都有一定的局限性，毕竟物理上还是在同一个屋子里，防不了物理灾害。 因此与其自购硬盘折腾各种备份，不如直接借助公有云。 通常对象存储服务都会提供冷存储，价格比较低，也比各类网盘稳定许多。 在国内考虑备份速度等问题，还是用阿里云比较方便，不公开的 bucket 预期不会涉及审查。

价格方面可以参考这个 价格表 和 最佳实践 。 建议就设置一个正常的 oss bucket ，然后配置生命周期规则，把多长时间没访问的对象自动转换为冷存储。 个人使用场景不涉及非常多的文件，数据丢失取回也是个小概率事件，可以用深度冷归档型，备份 1TB 的文件每月需要 7.68 元，数据取回需要 256-512 元，其它费用可以忽略不计。 大概算了下 AWS 价格会更高一些。 深度冷归档有一个缺点就是只有本地冗余，不支持同城冗余，如果要确保安全可以手动再开另一个可用区的桶做双保险。

在系统里安装 Cloud Sync 应用，阿里云创建一个 bucket ，在 数据管理->生命周期 配置一个 「最后一次修改时间 30 天后，转换为深度冷归档型」 ，然后创建一个带有 OSS 权限的 RAM 角色，把 AKSK 交给 Cloud Sync ，剩下的在 GUI 里配置就好了。 需要注意的是应该选择 「仅上传本地更改」 ，否则冷归档存储无法直接读取，不知道会导致什么问题。

恢复的时候直接手动用 ossutil 下载下来就好。