备份桶分层：自己的地随便改，程序的地一个字母别动

备份桶的第一原则：分清哪块地是谁的

一个对象存储桶乱不乱，不看文件多不多，看有没有一条统一的规则回答一个问题：这个目录是谁在写。

• 人管的：任务处理备份、迁移包、项目与应用备份。写入路径由我自己的脚本决定，改一行代码就生效，所以可以按中文、按编号随便排。
• 程序管的：面板快照、容器的应用备份、推送服务的目录。路径写死在程序自己的配置里，动一个字都可能出事。

这条线不划清，后面所有整理都是白干。程序不看你的目录结构，它只按自己记着的前缀往上写：你把它的前缀包进中文目录，它下次会安静地另起一套，旧的晾在中文目录里当孤儿。半年后桶里躺着两份都像最新的备份，那才是最贵的乱。

所以整理只在第一类里做，第二类原样保留、只加说明。

树怎么分：三层，不多

00_说明              总目录、命名规则、恢复方法
01_任务处理备份      两端整包，各留最新一份
02_迁移包            Hermes 环境导出
03_项目与应用备份
  ├─ 01_AI快剪
  ├─ 02_自由记录
  ├─ 03_企业管理平台
  └─ 04_Gotify推送
1panel/ 等程序目录   不改名、不编号、只放 README

两级就够：一级是「这是哪一类东西」，二级是「这一类里的哪个项目」。同一类收进一个大的，不要让一级目录里挂七个平级门牌。

编号规则两条：连续、不留空号；程序管的目录不占号。空号在做的人眼里有来龙去脉，在看的人眼里只是「这系统没收拾干净」。

每层一份 README，四个字段

文档写在桶里，不写在脑子里。六个目录各一份，内容只有四行：

1. 这个文件夹放什么；
2. 谁在写、多久写一次；
3. 现在多大；
4. 坏了怎么拿回去。

比如 01_任务处理备份/：两端整包各留一份，服务器每月 1 日 03:30、手机每月 1 日 03:40；包内只有记忆、技能、手册、脚本，附件和影音不进；恢复即解压回对应根目录。

1panel/ 那份第一行是警告：此目录不许改名，改名面板推不上来。

总目录放桶顶层，各分类放各自的。理由很朴素：人打开桶，眼睛先落到目录名，所以文档必须出现在他会点进去的那个位置。

容量：做减法比做分类更有效

• 双端备份各留一份。整包一份近 500MB，留两三份就是一两个 G 躺着；真实风险是「最近这份坏了」，不是「三天前的也想要」。新包传完自动删旧包。
• 成片视频不进桶。成片在手机本地留着，桶不承担这个。
• 改频率要连带改告警。每周转每月之后，「超过 7 天没备份就报警」的阈值得跟着放到 40 天，否则第二天早上就是一堆假警报。

一轮下来桶从 4.7GB 到 3.1GB，最大的一块仍是面板自己的快照 1.59GB —— 它自己管，不碰。

落到规矩上的六条

1. 桶名不改；程序写的目录，前缀一个字母都不改。
2. 人管的目录用中文加连续编号，不留空号。
3. 成片视频不进备份桶。
4. 双端备份各留最新一份，改份数要两端一起改 —— 只改一端，另一端的自动同步会把它覆盖回去。
5. 重组前缀的顺序永远是：复制、校验字节、再删旧。四十六个对象全部校验通过才动手删。
6. 私密桶里的东西，不要往公开图床搬。

说到底

整理备份结构，技术含量接近零，全是 copy 和 delete。

值钱的是那条边界：自己的地随便改，别人的地只贴标签。分层不是为了好看，是为了让三个月后打开控制台的人，一眼知道哪块能动手、哪块只能读。