事件报告：因存储空间已满导致的服务故障

2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家 

昨天，我的家庭实验室服务器突然变得无响应。起初是一连串的 Discord 通知，这是出现严重问题的普遍信号。

我发现所有服务都离线了。日志指向一个主要罪魁祸首：Redis 故障，具体是服务器内存不足错误。

核心错误是：RedisClient::CommandError: MISCONF Errors writing to the AOF file: No space left on device
我的第一反应是：为什么甚至启用了 AOF？我为了测试打开了它，然后忘记了。我的根分区容量已达 99%，24GB 中仅剩 270MB。

进一步调查揭示了“浪费”的空间藏在哪里：

• PM2 日志（约 3.8GB）：进程管理器存储了大量未轮转的文本日志。
• 隐藏缓存（约 1.5GB）：积累了来自多次构建和部署的 ~/.cache、~/.npm 和 ~/.rvm 源文件。

为了让系统恢复运行，我进行了一次快速的“手术式”清理：

1. PM2 刷新：使用 pm2 flush 立即清除了巨大的日志文件。
2. 日志截断：使用 truncate -s 0 log/*.log 清空应用程序日志（这会清除内容而不删除文件句柄）。
3. 缓存修剪：删除了 ~/.npm 和 ~/.cache 中的隐藏构建缓存。
4. 日志真空清理：使用 journalctl --vacuum-size=500M 清理系统日志。

现在我有了足够的空间来重新启动所有进程，但我需要恢复 Redis，因为它为了保护数据完整性而进入了只读模式。

1. 修复 AOF 清单：由于磁盘在 Redis 写入期间被填满，appendonly.aof.manifest 已损坏。我使用 sudo redis-check-aof --fix 修复了 /var/lib/redis/appendonlydir/ 内部的清单文件。
2. 清除 MISCONF 锁：即使有空闲空间，Redis 仍处于“保护”状态。我使用 redis-cli config set stop-writes-on-bgsave-error no 手动覆盖了此设置。
3. 服务重启：使用 systemctl reset-failed redis-server 重置 systemd 失败计数器，并重启服务。

之后，我可以成功重启所有服务并使一切正常运行。Redis 内部的所有数据都不关键，所以我不在乎丢失它们。

经验教训

这次故障是一个典型的忽视“无聊”基础设施的案例：日志轮转和磁盘监控。为了防止重蹈覆辙，我实施了以下措施：

• 日志管理：安装了 pm2-logrotate，将 PM2 日志限制为每个文件 10MB，并将 journald 全局限制为 500MB。
• 后续步骤：
  • 扩展虚拟机磁盘大小（24GB 对于这个技术栈来说太紧张了）。
  • 设置一个 cron 任务，每周执行 apt autoremove 和缓存清理。
  • 实施自动磁盘使用率警报（可能通过 Grafana 或一个简单的发送到 Discord 的 Shell 脚本）。