UIS +/var/log/日志增长快,磁盘空间不足

一般来说是可以删除的，但最好还是问下400吧

log文件都是可以删除的

：/var/log/storage/backup/ceph是 UIS 平台存储组件产生的ceph 历史归档压缩日志 (*.gz)，属于历史备份日志，不是 ceph 实时运行日志、不是业务数据、不是配置文件。

核心结论

1. 已经压缩完毕的 *.gz 历史归档文件可以安全手动删除，不会影响 ONEStor 存储集群、虚拟机业务运行。
2. ⚠️不要删除该目录下还在写入的未压缩.log原始日志文件，只删.gz后缀归档包。
3. 该目录日志是平台日志轮转备份产物；该版本存在缺陷：旧归档 gz 文件自动清理策略不生效，日积月累持续占用系统盘 /var/log 分区，最终磁盘告警。

紧急释放空间操作（生产现场）

1. 先确认目录内容，区分 log 原始文件和 gz 归档：

只删除后缀.gz，保留.log实时日志。

2. 删除全部 gz 归档（可先拷贝少量 gz 日志到外部备份，用于后续排错，确认不需要后再清理）

⚠️不要执行rm -rf /var/log/storage/backup/ceph整个目录删除，目录本身不能删掉，平台会持续往该路径输出归档。

3. 释放后查看磁盘占用

根因排查：为什么会疯狂生成大量归档日志

情况 A：ceph debug 调试日志级别被人为调高没有复原（最高概率）

之前排查存储故障时调高 ceph debug 日志等级，处理完故障忘记调回默认级别，会产生巨量日志，轮转后不断生成 gz 归档包。

生产默认一般为 0/5；数值越高日志量越大，如果出现 20/20 这类高数值，就是问题源头。

恢复为生产默认级别示例：

情况 B：E0802P01H08 版本日志轮转脚本缺陷，归档的 gz 没有自动老化清理

logrotate 配置只处理实时 log 文件，对/var/log/storage/backup/ceph下已经生成的 gz 归档没有做保留数量限制，旧归档不会自动删除，持续堆积占满 /var/log 分区。

根治方案，避免后续再次占满磁盘

方案 1：增加定时清理脚本（推荐，临时规避版本缺陷）

写定时任务，只清理 30 天以前的 gz 归档日志，不碰实时 log 文件。

方案 2：版本升级根治

E0802P01H08 该归档日志无自动清理属于已知问题，升级到后续修复补丁版本，平台内置轮转策略会自动限制归档保留份数，不再无限堆积。升级前备份全套 CVM 配置。

重要区分，不要混淆目录

表格

收集信息提交 400（如需提单）

1. df -h磁盘占用输出
2. ceph config get global debug_osd;ceph config get global debug_mon
3. ls -lh /var/log/storage/backup/ceph
4. UIS 版本 display version

避坑提醒

1. 删除 gz 归档只丢失历史排错日志，不影响虚拟机、ONEStor 存储池业务，存储数据完全不受影响。
2. 禁止直接删除整个 ceph 备份目录，平台会报日志输出异常。
3. 优先检查 ceph debug 日志等级，若调试级别过高不恢复，就算清理完 gz，短时间又会大批量生成新归档。
4. 多节点集群：所有 CVM/CVK 节点都需要检查该目录，每个节点独立生成归档日志，需要逐个节点处理。

补充：系统盘 /var/log 分区占满会引发 CVM 管理服务异常、任务执行失败、告警无法生成，但是不会直接影响 CVK 上虚拟机运行。