dy-dashboard/vault/知识库/工作指南/训练记录/2026-09-21-云端磁盘满导致登录卡死修复.md

2026-09-21 云端磁盘满导致登录卡死排查与修复

1. 排查云端系统无法打开并解决

旭东 → OpenClaw：

云端系统现在又异常了，无法打开，检查一下什么原因并解决

OpenClaw 响应：

已完成排查并修复，云端（gyl.dieya.net.cn）访问恢复正常。

现象与时间线

• 09:27 报障时外网探针：静态首页可返回 200，但 POST /api/login 会卡住不返回，即页面能打开、点登录没反应。
• 08:30 每日备份 cron 执行，导出 698M 数据库 SQL 后打包时磁盘写满，日志出现 gzip: stdout: No space left on device，tar 只写入 2048/10240 字节后失败，本次备份中断失败。
• 因为脚本是 set -euo pipefail 且中断在第 2 步，末尾的 rm -f ${DB_DUMP} 没执行到，那 698M 临时 SQL 文件滞留在项目目录，磁盘继续维持 100%。
• 09:05 gunicorn 出现 Autorestarting worker after current request，09:07 报 WORKER TIMEOUT (pid:968880)，中断栈正好停在 POST /api/login → services/db.py 的 conn.commit()，即 MySQL 因磁盘满无法提交写入，登录请求被拖到 60 秒超时。
• 排查时服务已部分自愈（gunicorn 自动重启，登录接口 0.4 秒返回 401），但磁盘仍是 100%、可用 0，随时会再挂。

根因

• 磁盘 100% 满：40G 用了 38G，可用 0（2 核 2G 的云端小机）。
• 占空间主要是历次累积的备份：/opt/dy-dashboard-backups 12G、/opt/dy-dashboard_backups 4.5G、/opt/dy-dashboard/backups 3.4G、/home/ubuntu/dy-dashboard-backups 3.9G、/opt/backups 0.65G、/home/ubuntu/backups 0.71G，合计约 25G。
• 现有自动保留策略只覆盖每日备份目录里的 dy_platform_backup_*（30 天），new_products_images_* 与各次手工/部署备份目录都没有清理机制。
• 本次不是代码或数据库问题：MySQL、nginx 日志均无报错，恢复写入后登录、备份全部正常。

处理（清理范围先经旭东确认，选「清理 9/10 之前的旧备份 + 失败残留」）

• 删除各备份目录中 2026-09-10 之前的备份（/opt/dy-dashboard-backups、/opt/dy-dashboard_backups、/opt/backups、/home/ubuntu/backups、/home/ubuntu/dy-dashboard-backups、/opt/dy-dashboard/backups），保留 09-10 以后全部备份。
• 删除失败残留：698M 临时 SQL dy_data_20260921_0830.sql、截断损坏的 dy_platform_backup_20260921_0830.tar.gz（仅 85M，不可用）。
• 未动范围外内容：/opt/dy-dashboard.old-20260808_101255（278M）、/opt/dy-dashboard-before-20260807_092207（254M）保留；两份 full-cloud 全量备份（09-20、09-21）保留。

结果与验证

• 磁盘：38G 已用 / 0 可用（100%）→ 23G 已用 / 16G 可用（59%），释放约 15G。
• 服务：dy-dashboard.service active（gunicorn 主进程未重启过）；本机 127.0.0.1:18888 → 200（0.004s）；公网首页 200（0.34s）、登录接口 200（0.68s）。
• 补做备份：重跑 backup.sh 成功，生成 dy_platform_backup_20260921_0930.tar.gz（177M）+ new_products_images_20260921_0930.tar.gz（59M），临时 SQL 由脚本正常清理，磁盘保持 60%。

后续建议（待旭东决定，未擅自改）

• 给手工/部署备份目录加保留策略（例如只留最近 7~14 天），并让 backup.sh 的清理覆盖 new_products_images_*，否则磁盘还会再次被慢慢填满。
• backup.sh 建议做失败兜底：tar 失败时也要把临时 SQL 删掉（当前 set -e 会让 698M 文件残留），并可考虑磁盘水位预检。

2. 磁盘占用治理建议与每日备份保留策略

旭东 → OpenClaw：

查一下现在云服务里面的40g用了多少了？

关于这个磁盘状态占用情况，有没有什么好的建议处理方法？

OpenClaw 响应：

现状：40G 用 23G、可用 16G（59%）。占用分布：/opt/dy-dashboard-backups 7.0G（两份 full-cloud）、/var/lib/mysql 3.0G、/opt/dy-dashboard 2.8G、/var/log 580M、/opt/dy-dashboard_backups 245M。

定位到真正的"水龙头"：自动化任务「云端每日完整备份」（每天 08:00 跑 backup_cloud_daily.py）每天向 /opt/dy-dashboard-backups 写一份 3.5G 全量包，没有任何保留策略；今天 08:00 那次吃掉最后约 4G（manifest 记录创建时 disk_free=785M），08:30 每日备份就写不进去了。按此节奏每日增量约 3.7G，20G 可用只够约 5 天。该全量包 3.4G 中水分极大：脚本 tar -czf ... -C /opt dy-dashboard 无任何排除项，把 venv、uploads、vault、logs 连同 /opt/dy-dashboard/backups 里的每日备份包又打了一遍包（套娃）。

给出的建议：① 全量备份瘦身（排除 venv/backups/logs 等，3.4G→约 250M）+ 只留最近 2 份 + 降为每周一次；② 每日备份目录加保留策略；③ backup.sh 加失败兜底（trap 删临时 SQL）与磁盘水位预检；④ 全量包定期外移到 11.79 或对象存储，云端只留最近 1 份；⑤ journald 设 SystemMaxUse=200M、MySQL 加 binlog_expire_logs_seconds、inventory_detail（1.1G）历史明细归档；⑥ 加磁盘水位告警（>80% 主动通知）。

旭东选定执行：仅第 ② 项「每日备份目录加保留策略」。

已执行（云端生产）：

• 先备份原脚本到 ~/dy-backups/backup-sh-pre-retention-20260921_094541/backup.sh。
• 修改 /opt/dy-dashboard/backup.sh 第 4 步清理段：dy_platform_backup_*.tar.gz 保留期 30 天 → 14 天；新增 new_products_images_*.tar.gz 保留 7 天（此前该文件从未被清理，每天约 59M）。bash -n 语法检查通过。
• 立刻按新策略清理一次：图片包删除 09-10/09-11/09-12/09-13 共 4 份（约 230M），09-14 起 7 份保留；项目包无超过 14 天的，未删除。
• 目录由 2.8G 降到 2.5G，文件数 21；磁盘 59%（23G 用 / 16G 可用）不变（本次释放量在四舍五入内）；服务 active、本机 200。
• 未执行其余各项：全量备份瘦身/保留/降频、backup.sh 失败兜底、备份外移、系统层优化、磁盘告警，均等旭东后续指令。