★ FEATURED ARTICLE 每个月账单邮件来的那天我的心情都差不多先扫一眼总额再安慰自己下个月应该不会涨了。这个下个月我已经安慰了自己两年。数据量涨上去之后云存储的账单几乎是一条只升不降的曲线存储费跟着数据量走流量费跟着访问走请求费跟着工具链走。我存的东西大多是冷数据一年摸不到几次却一直在为它们付全额的仓库保管费。某天深夜复盘账单的时候我意识到一件事我的业务在哪里和我的数据在哪里其实是两个问题。业务离开云没法活数据不是。于是我把数据回家当成一个正经课题花了几周时间把能想到的路线都过了一遍。这篇是我的研究笔记不是结论宣言。我把问题拆成了四个方案先说清楚前提。我的场景是个人加几个小项目的数据备份、照片库、一部分开发产物的归档加起来不算巨量但也不小。访问模式很简单写入频繁、读取稀少读取大多来自脚本而不是人。这个前提下任何方案的出账方式比它的功能列表更值得看。把需求摊开后路只有四条继续用云但想办法省钱买台 NAS用闲置硬件自建对象存储或者云和家各管一半。还有一个背景值得交代这段时间数据没出过什么大事故所以我的风险评估偏保守宁可方案笨一点也不要半夜起来救火。下面逐个说我的观察。方案一留在云上用分层和生命周期跟账单讨价还价云厂商自己其实给过台阶。对象存储普遍有存储分层热层、低频层、归档层价格逐层递减再配上生命周期规则可以让对象在没人访问之后自动沉到更便宜的层。听起来很美我认真配了一版。问题是冷数据的特性让省钱空间打折。归档层确实便宜但取回对象本身要付费有些还要排队等解冻一旦访问模式的判断出错取回的花销可能把省下来的存储费吃回去。低频层相对温和可对读得少但不为零的数据账单只是涨得慢一点。更麻烦的是我发现自己根本说不清哪些数据三个月没被碰过全靠规则去猜猜错的成本要过几个月才会在账单上显形。另一个容易低估的项是请求费和流量费。对象存储的计费维度不止存储一个读写请求按次算出站流量按 GB 计费量大了之后这两项很容易追上存储那一项各家费率不同方向却大体如此。归档分层省的是存储那一项取回的动作反而会推高流量和请求两项。分层策略到底省不省钱得把这几项都摆到桌面上才算得清。这条路没有错适合对自家访问模式心里有数的人我不属于那一类。它的好处也真实不用迁移不用运维数据的可移植性完全不受影响随时还能反悔。方案二NAS 盒子花钱买省心NAS 是数据回家的成品形态。群晖、威联通这类盒子把 RAID、快照、相册、同步服务都打包好了插电、建存储池、装套件一个周末就能用起来。对不想碰命令行的人来说这是摩擦最小的回家方式。我看中的点是它的确定性一次硬件投入之后每月账单归零电费除外。但我盘算下来有三个犹豫。一是机器本身不便宜几盘位的型号加上硬盘投入不小而它的硬件性能是为文件服务设计的不是我想要的存储系统。二是它对外的接口大多是 SMB、NFS 或者厂商自己的同步服务我的备份脚本走的是 S3 接口换过去等于把工具链重写一遍这笔隐形成本账单上看不见。成品 NAS 原生的优先接口确实还是 SMB/NFS少数系统支持加装 S3 网关比如 TrueNAS 上跑个 MinIO但那属于额外折腾和买盒子图省心的初衷是拧着的。三是容灾靠自己机器和盘都在家里断电、被盗、进水数据跟着一起走除非再配一台异地。NAS 适合文件加家人照片形态的回家和我的 S3 依赖有点错位。顺带一提配置好的快照和异地同步套件确实好用但整套生态是围绕厂商硬件搭的哪天想绕开它直接拿数据还得用它的导出工具走一遍。方案三闲置硬件加对象存储S3 接口是底线第三条路是用闲置硬件跑一套对象存储把 S3 接口留在原地。逻辑很简单我的工具链全都说 S3 方言那只要家里有个会讲 S3 的服务迁移就只是换个 endpoint。前提是脚本没踩在兼容矩阵的排除项上ACL 授权官方明确排除桶访问日志、桶所有权控制还在计划支持里依赖这几样的脚本就不是改 endpoint 能救的。选软件的时候我看了几个选项最后花时间最多的是 RustFS。它是一个用 Rust 写的分布式对象存储Apache 2.0 许可证文档定位写明面向兼容 S3 的工作负载。官方还有一份 S3 兼容性矩阵原话是实现了经过测试的 Amazon S3 API 子集哪些操作验证过、哪些还没实现、哪些明确排除都列在明面上。对我这种要把数据搬回家、又不想回头修脚本的人来说这种承认自己不是百分之百兼容的诚实反而比含糊地宣称完全兼容更让我放心。部署比我想的简单。Docker 方式在官方文档里就三步拉镜像、建卷、跑容器docker pull rustfs/rustfs:latest docker volume create rustfs-data docker run -d \ --name rustfs \ --restart unless-stopped \ -p 9000:9000 \ -p 9001:9001 \ -v rustfs-data:/data \ -e RUSTFS_ACCESS_KEYyour-access-key \ -e RUSTFS_SECRET_KEYyour-secret-key \ -e RUSTFS_ADDRESS:9000 \ -e RUSTFS_CONSOLE_ADDRESS:9001 \ -e RUSTFS_CONSOLE_ENABLEtrue \ -e RUSTFS_OBS_LOGGER_LEVELerror \ -e RUSTFS_OBS_LOG_DIRECTORY/var/log/rustfs/ \ rustfs/rustfs:latest \ /data9000 端口是 S3 API9001 是控制台。文档反复强调一件事把服务接入网络之前先把凭证换成自己的唯一值不要沿用初始的那组默认凭证。这一点我照做了暴露在家宽上的存储服务凭证就是大门。硬件这一环我用的是一台吃灰的小主机加两块机械盘。选它不是因为它强而是因为它闲着功耗低噪音小塞在角落里没有任何存在感。功耗低在这笔账里也是正经的一项这样一台小主机常年通电按 20 瓦上下估算一年电费百元上下这才是自建方案真正的月租至于把数据搬回家那一次云端的出站流量费往往比一年电费还显眼好在它是一次性的。对冷备份场景来说瓶颈从来不是 CPU是网线和盘。数据搬家比想象中顺。RustFS 官方提供了 rclone 集成指南配置里 provider 选 Other再把端点指向家里的地址。RustFS 默认就走路径式寻址rclone 这边保持默认配置就能对上[rustfs] type s3 provider Other access_key_id your-access-key secret_access_key your-secret-key endpoint http://localhost:9000 region us-east-1然后建桶、拷对象rclone mkdir rustfs:my-bucket rclone copy /path/to/hello.txt rustfs:my-bucket真实迁移就是把这两条命令里的桶名换掉一个桶一个桶地做对象拷贝。带宽决定搬运时长这一点没有魔法。顺带说一句rclone 的拷贝是增量的跑完第一轮全量之后后续维护只是定期补差量。当然这条路的代价要说清楚。自建意味着可用性兜底的人从云厂商变成我磁盘坏了怎么办、机器重启之后服务没起来谁发现这些以前不存在的问题现在都在我的待办里。官方文档给的路线图也很实在单机单盘模式没有容错能力要靠备份兜底生产环境要多节点多磁盘用纠删码扛磁盘和节点级别的故障正式上线前还有一份覆盖硬件、网络、软件和安全的检查清单要过。我这点数据量接受单机加异地备份的取舍再往上就得掂量了。方案四热数据在云上冷数据回家最后一条路是把前面几条组合起来热数据留在云上冷数据回家。写入仍在云上完成到了设定的时间就把不再访问的对象同步回家里的存储云上只留最近的东西。这是纸面上最优的形态。云的弹性保住了冷数据的成本沉到了家里的电费线上两边各取所需。冷热的判定我借用了云上的访问记录哪些前缀半年没被读过记录里一目了然比生命周期规则那种自动沉浮多一层人工确认。但它也是四个方案里运维负担最重的一个要维护两套存储、一条可靠的同步链路还要保证规则足够聪明别把下个月可能还要读的对象搬走了。对象万一要重新上云入站出站的流量两头都要算账这笔钱平时躲在选择方案的兴奋感后面。它适合数据量已经大到单边方案都难受、并且有精力长期维护同步链路的人。研究做完我的取舍是这样的一部分确凿的冷数据已经用方案三搬回了家跑在闲置的小主机上rclone 定期从云端的归档桶往下同步活跃的部分留在云上不动。NAS 我没有买S3 接口这个底线挡住了它。方案一里的生命周期规则我依然在用只是角色变了管的是云上剩下那一小部分。回头看这次研究里对我决策影响最大的一个判断是数据可移植性值钱。S3 接口让我的工具链在云和自建之间自由移动搬家成本从重写一遍降到改一行 endpoint。也是因为这样我评估存储方案的标准从功能列表换成了三个问题数据搬进来容易吗搬出去容易吗出问题的时候兜底的是谁。云存储没有错它收的是弹性和省心的钱。只是当数据长到一定程度这份省心的账单会超过很多人愿意为兜底付出的耐心。数据回家的路不止一条重要的不是选哪条而是想清楚自己最不愿意为什么东西买单。
阅读完成 · 觉得有帮助？
