磁盘空间不足导致导入失败时，真实原因常是被删除但未释放的文件、systemd日志膨胀或临时文件堆积；应先用lsof +L1查占用文件，再truncate清空日志，而非直接rm；云扩容后须验证lsblk、分区类型及正确执行resize2fs或xfs_growfs。
磁盘空间不足导致导入失败，先别删文件
导入（比如数据库 restore、docker load、pip install 大包、或 ci 流水线解压镜像）报错 no space left on device，不代表真没空间了——更可能是日志、缓存或被删除但未释放的文件占着坑。直接 rm -rf 某个目录，很可能白忙活，甚至引发服务中断。
常见错误现象：df -h 显示根分区 98% 满，但 du -sh /* 加起来才 70G；重启服务后空间“突然”多出 10G；tail -f /var/log/syslog 卡住不动，但磁盘还在涨。
- 先用
lsof +L1查被删除但仍被进程打开的大文件（典型如轮转后没 reload 的/var/log/nginx/access.log） - 再用
journalctl --disk-usage看 systemd 日志是否失控（默认可能无限增长） - 检查
/tmp和/var/tmp下有无长期驻留的临时归档或调试 dump 文件
安全清空日志而不中断服务
很多服务（Nginx、MySQL、rsyslog）会持续写同一个日志文件，直接 rm 它，文件句柄还在，磁盘空间不释放，还可能让服务因写失败而异常。必须用“截断”而非“删除”。
-
truncate -s 0 /var/log/messages：清空内容，保留文件和 inode，服务无需重启 -
echo "" > /var/log/mysql/slow.log：效果同上，但注意权限（需用服务运行用户执行） - 对 systemd 日志，用
journalctl --vacuum-size=500M限制总大小，比--vacuum-time更可控
⚠️ 别对 /var/log/journal/ 目录本身 rm -rf——它受 systemd-journald 管理，删了可能触发重建并再次打满。
云服务器扩容前必须做的三件事
在线扩容（阿里云/腾讯云/AWS）虽快，但跳过验证步骤极易翻车：扩容成功但系统看不见新空间，或者扩展后文件系统损坏。
- 控制台扩容后，立刻在服务器里跑
lsblk，确认设备容量已变（如/dev/vda从 100G 变成 200G）；若没变，说明控制台操作未生效或需重启实例 - 查分区表类型：
sudo fdisk -l /dev/vda | head -5，看是dos（MBR）还是gpt；MBR 下用fdisk重建分区时，起始扇区必须和原来一致，否则数据丢失 - 扩展文件系统时注意命令对象：
resize2fs /dev/vda1（ext4，输设备名），xfs_growfs /（xfs，输挂载点路径），输错就报错且不提示
Ubuntu/Debian 上那些看不见的磁盘杀手
除了日志和缓存，Snap 包、旧内核、APT 缓存这三类在桌面或容器化环境中特别容易被忽略，加起来常占 5–15G。
-
du -sh /var/lib/snapd/snaps：Snap 应用每个版本都完整保留，snap list后用snap remove --purge <name></name>清旧版 -
dpkg --list | grep 'linux-image-' | grep -v $(uname -r)：列出非当前内核，挑老的sudo apt purge linux-image-5.15.0-xx-generic -
sudo apt clean清空/var/cache/apt/archives/，比autoclean更彻底（后者只删过期包）
真正麻烦的不是空间不够，而是清理后空间没释放——那基本就是 lsof +L1 没查，或者服务没 reload 日志配置。这点最容易被跳过。
