先说结论：数据不是在"重启"时丢的，而是在"容器被重建"时丢的。Docker 容器 = 只读镜像 + 一个可写层，docker restart/start 不会动可写层，数据不会丢；只有容器被删除后重新 run（例如 docker rm 后重建、compose up --force-recreate、K8s 重建 Pod、脚本里 stop+rm+run 的组合），旧可写层才会被清理，写在容器内路径的数据随之消失。一、还能不能救回来，分三种情况1. 容器还活着（只是 stop 了）：数据都还在。直接启动即可：docker start 容器>想保底的话，先把数据拷出来或者固化成镜像：docker cp 容器>:/数据路径 ./backupdocker commit 容器> rescue:tag2. 容器已 docker rm，但宿主机 overlay2 写层还没被清理：有概率手工找回。到 /var/lib/docker/overlay2/ 下按修改时间找最近的可写层目录（upperdir 特征是目录里多为刚写入的增量文件）：ls -lt /var/lib/docker/overlay2/ | head逐个翻最近的目录，找你的数据文件（可以 grep 文件名或按内容特征）：find /var/lib/docker/overlay2/候选目录>/ -name "*.db" -o -name "你的文件名"找到后直接 cp 出来。动作要快，写层目录随时可能被清理；找到先复制出来再慢慢验证。3. 写层已被彻底清理：基本无法恢复。这时只能从备份、日志、上游数据源重新同步。二、为什么"挂了卷还是丢"也会发生排查顺序：1. 确认应用真正写入的路径：docker exec 容器> ls -l /实际数据路径，再看 docker inspect 容器> 的 Mounts 段，确认该路径确实落在某个 volume 或 bind mount 里，而不是容器可写层。2. 常见误区是应用配置的数据目录和实际挂载的目录不一致（比如挂了 /data 但应用写在 /var/lib/data），挂了等于没挂。3. 数据库类容器还要确认初始化脚本是否把数据写到了镜像内默认路径之外。三、正确的持久化做法1. 单机 docker：启动时挂卷，数据库必须挂数据目录：docker run -v /data/mysql:/var/lib/mysql -v /data/app/uploads:/app/uploads ...2. compose 用 named volume 声明，容器随便重建，卷不删数据就一直在：volumes:dbdata:services:db:volumes:- dbdata:/var/lib/mysql注意：docker compose down 默认保留 named volume，加 -v 才会删，别误加。3. 华为云上的容器：CCE 集群用 PVC（底层可绑 EVS 云硬盘或 SFS Turbo），Pod 重建数据不丢；ECS 上自建 docker 的，把宿主机挂载数据盘后的目录（如 /mnt/sdc）作为 bind mount 源，配合云硬盘快照做周期备份。4. 真正重要的数据不要只依赖挂载，还要有备份：数据库定时 dump 到 OBS，或给云硬盘配快照策略。四、验证清单（做完挂载后花一分钟确认）1. 容器内往挂载路径写个测试文件，docker rm 掉容器重新 run，确认宿主机文件还在。2. docker inspect 容器> | grep -A 10 Mounts，路径对得上。3. 模拟一次故障演练：主动删容器重建，看数据是否完好，别等生产事故来检验。一句话总结：先分清 restart 和重建；容器还在就 start/commit 抢救，删了就去 overlay2 碰运气；之后把有状态数据一律挂卷 + 备份，容器当牲口养，随时可杀可重建。

OBS 生命周期规则用于自动管理对象的生命周期：按设定天数自动转换存储类别（降冷省钱）或过期删除（自动清理），避免人工干预和持续计费。下面按"能配什么 → 怎么配 → 配的时候注意什么"来讲。一、生命周期规则能做哪些事1. 转换存储类别：对象存入桶后满 N 天，自动从标准存储转为低频访问存储、归档存储或深度归档存储。比如"30 天后转低频、90 天后转归档"，冷数据成本能降一个数量级。2. 过期删除：对象存入满 N 天后自动删除。适合日志、临时文件、中间结果这类有明确保留期的数据。3. 历史版本管理：开启多版本后，对历史版本对象单独配置转换或删除，只保留最近几个版本，老版本自动清理。4. 清理未完成的多段上传：多段上传中断后会残留碎片继续占空间，可配置"碎片上传后 N 天自动删除"，避免隐性浪费。二、控制台配置步骤1. 登录 OBS 管理控制台，进入"桶列表"，单击目标桶。2. 左侧导航栏选择"基础配置" → "生命周期规则"，单击"创建"。3. 填写规则配置：- 规则名称：自定义，便于识别（如 log-auto-archive）。- 前缀：按对象名前缀过滤，只对匹配的对象生效。留空表示对全桶生效；填 logs/ 表示只管 logs 目录下的对象。这是做多套规则的关键——不同前缀走不同策略。- 当前版本对象转换：勾选后设置"对象存入 N 天后转为 XX 存储"，可配多档（如 30 天→低频，90 天→归档）。- 当前版本对象过期删除：勾选后设置"对象存入 N 天后删除"。- 历史版本对象：同样可配转换和过期删除，天数从该版本成为历史版本时起算。- 碎片过期删除：设置多段上传残留碎片的自动清理天数。4. 单击"确定"保存规则。三、用 obsutil 配置（适合批量/脚本化）obsutil config 命令可生成生命周期规则 JSON 模板，编辑后用 obsutil lifecycle obs://bucket 作用到桶上。适合把同一套规则批量应用到多个桶，或纳入运维脚本统一管理。四、几个典型的配置场景- 日志桶：30 天后转低频，90 天后转归档，180 天后删除。前缀留空或按日志子目录分规则。- 备份桶：只转冷不删除。如 60 天后转低频，180 天后转归档，不配过期删除，保留期由备份策略单独控制。- 临时文件/上传桶：7 天后直接删除，同时配碎片 1 天过期，防止上传残留。- 多版本桶：当前版本只转冷不删；历史版本 30 天后删除，避免版本膨胀。五、配置时容易踩的坑1. 规则是异步执行的，配置后通常在 24 小时内生效，不是立即执行，别配完就盯着看。2. 转换到归档/深度归档后，访问前需要先恢复（Restore），恢复有延迟且产生恢复费用，所以只对确定冷访问的数据转归档。3. 前缀区分大小写，且是前缀匹配不是通配。logs/ 只匹配 logs/ 开头的对象，不匹配 Logs/ 或 logs2。4. 同一对象如果同时命中多条规则（比如前缀有重叠），OBS 会按规则合并处理，转换取最早满足的天数，删除取最早满足的天数，不会重复执行。5. 过期删除不可恢复，配之前确认前缀和天数无误，尤其全桶规则（前缀留空）要格外小心。6. 生命周期操作本身不额外收费，但它触发的存储类别转换和删除会按对应存储类别的正常价格计费/结算。具体参数名和界面选项以当前版本 OBS 用户指南"生命周期管理"章节为准。