自建对象存储该不该用：先看它解决的问题是不是你的问题

单盘模式没有冗余，盘坏了数据直接没；纠删码 4 盘只能坏 2 盘

它擅长的是备份与归档目标；如果你只是图片附件存储，用现成的东西更省事。

先说结论

自建对象存储省的是流量费，赔的是「盘坏了有没有冗余」这件事

• 适合：备份与归档目标
• 不适合：内网 S3 兼容层
• 学习成本：纠删码的可用容量约为总容量的一半，不是四分之三
• 最大收益：mc mirror 做增量同步，比 rsync 更懂对象与分片上传
• 最大风险：单盘跑对象存储当唯一备份目标，盘坏了源和备份一起没

它到底解决什么

单盘模式没有冗余，盘坏了数据直接没；纠删码 4 盘只能坏 2 盘。

换句话说，它把「备份与归档目标」这件事从手工变成可重复的流程。这是它真正的价值，而不是功能列表的长度。

什么时候不该用

下面三种情况，用了反而更累：

单盘跑对象存储当唯一备份目标，盘坏了源和备份一起没

用 ETag 校验分片上传的文件，永远对不上

把 20 万个小文件塞进一个前缀，控制台列表直接卡死

和替代方案比

分片上传的 ETag 不是文件 MD5，校验要用 x-amz-checksum 头。

这台工具的关键细节

几个决定长期体验的点：

• 纠删码的可用容量约为总容量的一半，不是四分之三
• mc mirror 做增量同步，比 rsync 更懂对象与分片上传
• 大量小对象会拖慢列举，10 万个对象 ls 一次要几十秒

我的建议

自建对象存储省的是流量费，赔的是「盘坏了有没有冗余」这件事。

先用两周，跑一个真实的小任务；两周后你还想用它，再谈长期。

还有几处容易忽略的

都是小地方，但出问题时往往就卡在这里。

• 生命周期规则是后台异步扫描，配完不会立刻删除对象

工具是解法，不是身份。