海外站群服务器硬盘满了怎么办?

上个月，一个做海外站群的朋友老赵半夜十二点多给我打来电话，声音里带着明显的焦躁。他说他的一台服务器突然连不上了，网站全部打不开，SSH也登不上去，连FTP都报错。他以为是服务器被攻击了，或者机房出了故障。折腾了大半个小时，好不容易通过管理后台的应急控制台登录进去，敲了几条命令才发现原因简单得让他想撞墙 硬盘满了。

“我就说最近怎么数据库老是报错，新文章发不出去，图片上传也失败。”老赵在电话那头懊恼地说，“可我一直觉得那台服务器硬盘挺大的，怎么莫名其妙就满了呢?”

我相信老赵的遭遇不是个例。很多人做海外站群，一开始觉得硬盘空间绰绰有余，各种日志、备份、临时文件都没怎么管。等到某一天服务器突然罢工，才发现原来是硬盘被塞得严严实实。那种叫天天不应叫地地不灵的感觉，经历过的人都懂。

今天我就借着老赵的这个案例，好好聊一聊海外站群服务器硬盘满了之后，到底应该怎么办。从发现征兆到紧急处理，从清理空间到长远规划，每一步我都会讲得明明白白。

先确认一下，真的是硬盘满了吗?

当你发现网站打开缓慢、无法上传文件、数据库报错“No space left on device”、SSH登录进去敲命令提示“Disk quota exceeded”的时候，第一反应不应该是慌张，而是先确认一下硬盘的使用情况。

用一条最简单的命令就能看明白。登录服务器的终端，输入 df -h，这个命令会把所有挂载点的硬盘使用情况用人类看得懂的方式列出来。你会看到类似“/dev/sda1用了95%”或者“/用了100%”这样的信息。如果使用率达到了百分之九十五以上，那就非常危险了，随时可能触发系统保护机制，拒绝任何新的写入操作。如果已经是百分之百，你就得抓紧时间处理，因为这时候不仅网站写不了日志，连系统本身的某些临时操作都可能失败。

老赵当时的情况就是 / 分区用了百分之百，看起来什么都没有做就满了。

有一个容易踩的坑，就是 inode 用满了。硬盘空间还剩下不少，但文件数量太多了，导致文件索引节点不够用。这时候 df -h 看空间正常，但是 df -i 会发现 inode 使用率百分之百。这种情况通常是因为某个目录里堆满了成千上万个极其小的文件，比如会话文件或者缓存碎片。如果你用 df -h 看到空间还有，但系统依然报错说硬盘满了，一定要用 df -i 检查一下 inode。

硬盘满了会发生什么?千万别等到彻底动不了

很多人觉得硬盘满了无非就是存不了新东西，旧的还能读。这个想法很危险。

当服务器硬盘使用率达到百分之九十五以上的时候，操作系统会开始变得不太稳定。网站访问可能会出现间歇性的500错误，数据库因为无法写入临时表而报错，邮件服务无法接收新邮件，甚至连系统日志都无法记录。这些问题往往是零星的、偶发的，让你觉得是不是哪里配置错了，而不会立刻想到硬盘。

等到百分之一百的时候，很多服务就直接挂掉了。最要命的是，有些服务器在硬盘满的时候，SSH虽然还能登录，但你敲命令可能会因为无法写入日志而卡住。如果连根目录下的关键配置文件都被破坏，重启之后可能再也起不来了。老赵当时就是SSH登录后很多操作都提示失败，差点以为系统崩溃了。

所以排查硬盘问题一定要趁早，不要等到彻底动不了再动手。

紧急情况下的第一步：先找到占用空间的大户

当你确认硬盘确实满了之后

第一步不是盲目去删东西，而是先找到到底是什么在占空间。

在Linux服务器上，有一个经典的组合命令能帮你快速定位大胃王。从根目录开始 du -sh /* 可以把根目录下每个文件夹的大小列出来。但这个命令有时候跑起来比较慢，尤其是在大硬盘上。更快的办法是深入到可疑的目录里逐层查找。

以我这些年的经验，海外站群服务器硬盘满了，百分之八十的情况都出在下面几个位置。

第一个是日志文件。系统的日志通常放在 /var/log/ 目录下。有些服务器跑了好几年，从来没有做过日志轮转，单个日志文件能膨胀到几十个G。特别是当你开启了详细的访问日志或者错误日志，流量稍微大一点，几天就能写出几个G。

第二个是数据库的二进制日志或者慢查询日志。MySQL和MariaDB的二进制日志(binlog)如果开启了，会一直增长。很多人在搭建数据库的时候默认打开了binlog，后来忘记关掉或者定期清理，两年下来binlog能吃掉上百G的空间。

第三个是网站自身的附件和缓存。站群服务器往往运行着多个网站，每个网站产生的图片、压缩包、临时文件堆在一起，时间长了就是一个惊人的数字。尤其是那些做了自动备份插件的CMS系统，每次备份都会在本地生成一个压缩包，如果没有设置自动删除旧的备份，几十次备份下来能把硬盘撑爆。

第四个是系统更新残留的内核文件和旧软件包。Ubuntu或者CentOS每次更新内核，旧内核文件还会留在/boot分区里。更新了几十次之后/boot就满了。用包管理器的自动清理不彻底，也会留下一堆没用的软件包缓存。

老赵的服务器我帮他看了之后，发现罪魁祸首是两个地方。一个是他的Nginx访问日志，一个文件就占了四十多个G，因为他从来没有配置过日志切割。另一个是他运行的一个采集脚本，每次采集失败都把错误信息写入同一个日志文件，那个文件也占了将近三十个G。两个加起来，一块一百多G的系统盘基本就没了。

第二步：安全地清理日志文件和临时文件

找到大户之后，清理的时候要留个心眼，不要用rm命令直接删了就完事。因为有些程序还在往日志文件里写内容，你这边rm删了，但文件句柄还没有释放，空间并不会立刻腾出来。你需要使用类似于 cat /dev/null > logfile.log 的重定向方式把日志文件清空，或者重启对应的服务。

对于系统的日志文件，标准的做法是配置logrotate。大部分Linux发行版默认已经安装了logrotate，你只需要修改一下配置文件 /etc/logrotate.conf 或者在 /etc/logrotate.d/ 目录下添加对特定日志文件的轮转策略。比如你可以设置每天轮转一次，保留七天的日志，超过七天的自动压缩删除。这样一来，日志就不会无限增长。

对于数据库的二进制日志，如果你不需要做主从复制，完全可以在my.cnf配置文件中禁用它，然后重启数据库并手动清除已有的binlog文件。如果你确实需要binlog，那也要设置过期时间，比如expire_logs_days=7，让它自动清理七天前的日志。

另外，系统的临时目录 /tmp 和 /var/tmp 里也会累积很多临时文件。这些文件在服务器重启后通常会被清空，但如果你的服务器几个月甚至一年不重启，/tmp 里面可能会留下大量没用的东西。可以用 rm -rf /tmp/* 清理，但要确保没有正在用的临时文件。保守一点的方法是只删除三天前修改过的临时文件。

清理完之后，再用 df -h 看一下，你会发现空间回来了不少。老赵按照这个方法，把访问日志和错误日志都清空，再用logrotate配置好自动轮转，一下子就释放了六十多G的空间，网站立刻恢复了正常。

第三步：处理那些藏在角落里的备份文件和旧网站数据

站群服务器还有一个特殊的地方，就是你会经常手动备份网站文件和数据库。很多人习惯在服务器本地执行 mysqldump，生成的SQL文件就放在 /root 或者 /home 目录下，每次备份都起一个带日期的新名字，比如 backup_20250101.sql。一年下来可能积累了五六十个备份文件，每个几个G甚至十几个G，加起来就是一个庞大的数字。

我的建议是，本地只保留最近两到三次的完整备份。更早的备份要么删除，要么搬到另外的存储设备或者云存储服务上去。千万不要把服务器本身当作永久备份的归宿。

还有一种情况，就是你曾经迁移过网站或者更换过域名，老的网站根目录还保留在服务器上，但已经没有在对外服务了。这些老文件放在那里一年两年，可能你自己都忘了。翻出来看看，该删的就删了，或者打包下载到本地存档之后再从服务器上删除。

老赵在清理的时候还发现了一个意外收获。他有一个网站之前用了某个缓存插件，插件在缓存目录里生成了几百万个图片大小的零碎文件。这些文件单个很小，但数量极其庞大，占用了大量的inode。他用 ls 命令进去的时候直接报错，因为文件太多了。后来他用 find 命令配合 xargs 批量删除了这些缓存文件，inode使用率瞬间从百分之九十八降到了百分之十几。

第四步：如果清理完还不够，怎么给服务器扩容?

有时候你已经把能清的地方都清了，但还是发现硬盘空间紧张。或者你的业务正在高速增长，每天新增的数据量就有几十G，光靠清理已经解决不了根本问题。这个时候就需要考虑给服务器扩容了。

海外站群服务器的扩容方式，取决于你的服务器是物理机还是云服务器。

如果是云服务器，事情就简单得多。大部分云服务商都支持在线扩容硬盘，也就是在你的控制面板里把系统盘或者数据盘的大小改大，然后在服务器里执行几条命令让文件系统识别到新增加的空间。这个过程通常不需要重启服务器，也不需要停止服务，非常方便。唯一的注意事项是，在扩容之前最好做一次快照或者备份，防止操作失误导致数据丢失。

如果是物理机，那就没有在线扩容这么方便了。你需要找机房的管理人员或者远程技术，往服务器里加一块新的物理硬盘。加完之后，对新硬盘进行分区、格式化，然后挂载到一个合适的目录下面。比如你原来的网站数据都放在 /var/www 里面，你可以把新硬盘挂载到 /var/www 下面的某个子目录，或者干脆把整个 /var/www 的数据迁移到新硬盘上，然后用软链接指过去。

还有一种折中的办法，不扩容系统盘，而是买一个独立的网络存储块设备，或者对象存储服务，然后把不经常访问的冷数据比如老的日志文件、旧的备份、历史存档，迁移到这些低成本存储上去。服务器本地只保留热数据，这样既解决了空间问题，又不需要对服务器本身做大的改动。

第五步：建立监控和自动清理机制，别等到下次又翻车

经过上面的一番操作，你的服务器硬盘应该已经恢复了比较健康的状态。但如果你就此不管，过几个月同样的悲剧还会重演。真正有效的做法是建立一套长效机制，让硬盘不会再次悄无声息地满掉。

监控是第一步。你可以用简单的shell脚本配合crontab定时任务，每天检查一次硬盘使用率。如果使用率超过百分之八十，就给自己的邮箱或者手机发一个警告消息。如果超过百分之九十，那就提高告警级别。早发现早处理，不要等到百分之百了才手忙脚乱。

自动清理是第二步。除了之前说的logrotate定期轮转日志之外，你还可以写一些清理脚本放在cron里。比如每天凌晨两点执行一次 find /var/log -name "*.log" -mtime +30 -delete，删除三十天前修改的日志文件。对于网站的缓存目录，也可以用类似的命令删除过期的临时文件。对于数据库的备份，可以设置只保留最近七天的备份文件。

老赵吃过一次亏之后，现在每周都手动检查一次硬盘使用情况，还写了一个简单的监控脚本，用钉钉机器人推送告警。他说现在心里踏实多了，至少不会再出现半夜服务器崩溃的惨状。

一个更复杂的案例：站群服务器的数据分层迁移

我还遇到过另一个案例，是一个做海外内容站群的团队，他们每台服务器上跑了大约两百个小网站，每个网站的数据库都不大，但加起来就有好几十个G。服务器的硬盘是五百G的普通SSD，用了一年多之后，可用空间只剩下不到百分之十。

他们试过清理日志，试过删备份，还试过压缩旧的图片，都只是杯水车薪。因为真正的瓶颈是那些不断增长的数据库文件和网站上传的图片。这些数据每天都在增加，光靠清理已经无法逆转。

后来我们商量了一个方案，把冷数据从主服务器上迁移到单独的对象存储里。具体做法是，把两年以前的文章附带的图片全部转移到对象存储，然后在网站程序里做一个重定向，让访问旧图片的时候自动从对象存储拉取。这样一来，服务器本地的图片数据量减少了将近百分之七十。同时，他们把一些不经常被访问的旧网站数据库导出归档，从主数据库里删除，只保留最近活跃的数据。

数据的迁移工作持续了一个星期，整个过程很繁琐，但最终的效果很不错。主服务器的硬盘使用率从百分之九十降到了百分之四十，而且因为数据库体积变小了，网站的整体响应速度反而比以前更快了。

这个案例告诉我们，当数据量真的增长到本地硬盘无法承载的时候，不要死守着“所有东西放在一台服务器上”的想法。把数据分层，把热数据和冷数据分开，把本地存储和远端存储结合，才是站群服务器长期健康运行的出路。

总结：硬盘满了不可怕，怕的是你毫无准备

回到老赵的故事，那次半夜的求救让他记住了两个教训。第一，不要以为硬盘空间永远够用，一定要主动维护。第二，出了问题别慌，按部就班地排查和清理，百分之八十的情况都能自己解决。

海外站群服务器硬盘满了怎么办?我把它总结成一套可以照着做的流程。

首先，确认硬盘是真的满了，还是inode满了。用df -h和df -i两个命令看清楚。其次，找到占用空间的大户，重点关注几个常见区域：日志文件、数据库binlog、网站缓存和附件、旧的备份文件、系统残留包。然后，安全地清理这些文件，注意用重定向而不是直接rm删除还在写入的日志，配置logrotate让它自动轮转。之后，如果清理完还不够，就考虑扩容，云服务器可以在线扩容硬盘，物理机需要加挂新硬盘并迁移数据。最后，也是最重要的一步，建立监控和自动清理机制，让硬盘使用率始终保持在健康范围内。

有人说，一个合格的站群运维人员，最重要的能力不是出问题的时候能搞定，而是让问题根本不会发生。硬盘满了这件事，其实就是一场完全可以预防的火灾。一个监控脚本、一个定时清理任务、一个容量预警，花一个小时配置好，就能避免无数次半夜惊醒打电话求助的窘境。