这台云服务器的数据已经沿用一年多了，期间每次删除前都会备份，然后从镜像新建。大概一个月前，网络经常出现问题，期间操作的时候发现……一共 50G 的可用备份空间，一个镜像就已经 20G 以上了，备份、恢复时间很长。

最近倒还算太平，所以时不时会登上去写一点东西（不在家时最顺手的环境）。前几日心血来潮，登上去 df 了一下，感觉不太妙：

/dev/vda2 51470972 45795920 3037436 94% /

首先回想自己做错了哪些事，产生了哪些大文件……

  • 软件包
  • (Rust) target
  • node_modules
  • ……

Arch Wiki 上提到，“按大小排序安装的软件包，安装 expac 并运行 expac -H M '%m\t%n' | sort -h”。原以为是依赖了 Qt 或者 KDE 全家桶之类的，结果体积最大的包也就只有 476.27 MiB go。有点奇怪，那就找文件吧。

ls 列出来的目录文件大小统一 4096 bytes，这里需要用 du 命令。首先在 ~ 目录下 du -sh * | sort -h，没想到最大的文件是之前编译的 hhvm，足足 9.7G ……由于当时编译最终文件 hhvm 只有 84M，而没在意过这里。

解决了一个大头，接下来就是清理各处 cache 等等。顺便，Rust target 目录大小和 node_modules 大概不是一个数量级的，总量千行的项目，加上依赖，整个 target 500M 左右……

又腾出不少空间，再看，用量 50% 左右。不知道死角在哪，于是各处查看，发现 /var 目录占用了 10G 以上。/var 会比 /usr 大这么多吗……进去后发现，大部分都在 /var/log 里。

由于不是生产服务器，不太需要查看日志，也没这样的习惯，也就一直忽略了这里。里面也主要是两个文件，一个是某网络相关的程序的日志，约 1G ，另一个是 systemd 的日志 journal ，大约 10G 。

据说 journal 默认大小限制为文件系统容量 10% ，不太知道这里 10G 原因是什么。总之，先清理。 truncate 清空某个网络相关的程序的日志，接着再 journalctl --vacuum-size=? 清理 journal 日志。

/dev/vda2 51470972 14155048 34678308 29% /

大概清理完毕，流水账记录完成。一个经验教训：日志文件可以很大……当然，Rust target 也很大……