美国云主机磁盘空间满了如何清理?

先讲一个我亲身经历过的场景。去年夏天，一位做跨境电商独立站的朋友给我发了条消息，语气很急，说他的美国云主机突然访问不了，后台打不开，连SSH都报错了。我远程上去一看，根目录使用率已经达到百分之九十九，系统直接拒绝所有写入操作，连最基本的日志都没地方记了。

当时这位朋友摸不着头脑，反复问我同一个问题：我就放了几个前端页面和一个小型数据库，怎么就把磁盘撑爆了?

其实这个问题并不复杂，我今天就想把这个案例掰开揉碎了讲一讲。美国云主机磁盘满肚的状况，可能很多人都会遇到，只是每次看到那个红色告警提示时，免不了心里咯噔一下。本文不搞那些花里胡哨的术语堆砌，就用最实在的步骤，把清理美国云主机磁盘空间的方法一件一件说明白。

先诊断再动手，着急出错的教训

回头说那次朋友的电商网站。他们团队本来已经有好几个人开始围着运维面板打转，有人说加钱扩容买磁盘，有人说重装系统重新部署，各种建议五花八门。

我劝他们先不要着急作出下一步决定，先把服务器登录上去。

磁盘满的第一反应不应该是直接删除文件，而是先搞清楚哪些目录、哪些文件在占空间，避免误删了关键数据。我见过不少新手直接从根目录用rm一顿扫射，把数据库文件或者系统配置都给误删掉了，到时候哭都来不及。

先看整体磁盘占用，用df -hT这个命令。它能列出所有分区的使用率，显示文件系统类型和挂载点。我帮那位朋友一看，根分区用了百分之九十九，而数据盘仍然有大量空闲。说明问题出在系统盘，而不是数据盘。

但是光看整体还不够，得找到具体是哪个目录在吃空间。这时候需要用的命令是du。在根目录下面跑一条组合命令：du -sh /* 2>/dev/null | sort -rh | head -20。它可以列出根目录下各文件夹的大小，按从大到小排序。

当时结果摆出来，/var占了接近四十个G，其他的目录都只有一两G。很明显，/var下面的东西不对劲。接着进入/var继续查，du -sh /var/*发现/var/log占了将近三十个G。

真相就摆在面前了。朋友之前为了让网站运行更稳定，打开了Nginx的全量访问日志，却没有设置任何日志轮转，一年下来那个access.log文件涨到了二十多G。那个报错日志的大小也同样惊人，加起来差不多三十个G。

为什么磁盘会被占到百分之百

搞清楚了诊断的思路，接下来就说说哪些东西最容易成为美国云主机的“空间杀手”。我们结合真实案例来看，以下这几类占用源通常在磁盘告警中排在前列。

日志文件失控是最常见的。无论是Nginx还是Apache，运行时间长了，默认的访问日志和错误日志如果不清理，一个月都能长到几个G。更不用说应用自己的调试日志，只要配置里没有设置日志轮转，无限地向上累积空间被占满是迟早的事。我当时还帮另一个做媒体网站的客户排查过，他们的PHP错误日志竟然长到了将近六十个G，原因是有段代码反复报致命错误，分钟级地往硬盘写错。

软件包缓存也是个容易被忽略的大户。用apt或yum安装软件的时候，包管理器会把下载的安装包缓存到本地。在基于Debian和Ubuntu的系统上，/var/cache/apt/archives目录会保留大量deb包。时间久了，这些缓存的安装包可以占据好几个G的容量。

Docker镜像和容器的残留数据是另一个隐形杀手。一旦你在美国云主机上跑过Docker容器，即使后来停止再用，没有彻底清理干净，残留的镜像、停止状态的容器、未使用的网络和数据卷会堆积出几十个G的不可回收文件。我帮国内一个做AI应用部署的朋友清理过一次，他之前用Docker做过好几轮模型训练，光是旧镜像就占了整整二十多个G的空间。

此外，数据库的二进制日志也是不可忽视的占用源。MySQL默认生成的binlog二进制日志记录了所有数据变更语句，如果没有设置过期自动清理的机制，这些日志会无限增长，一分钟都不停歇地写下去。PostgreSQL的WAL日志也是同样的原理，倘若开启归档模式后不做清理，很快就会把磁盘占满-。

当然了，还有用户上传文件的堆积、网站备份文件遗留、临时文件目录等等。这些情况加起来，哪一个不注意，都可能随时把你的美国云主机推入崩溃边缘。

有人要问了，再碰到这种情况，总不能每次都把磁盘扩容吧?没错，扩容虽然最终能解决，但那只是治标不治本。下面我就把清理的实际操作方法细致地讲一遍。

日志清理：从手动救命到自动化维护

日志是大户，所以先从日志说起。

当你千辛万苦定位到那个巨大的日志文件后，该怎么清理它呢?很多人的直觉是直接用rm -rf删除那个文件。但这样做有问题。如果日志文件正在被进程写入，比如Nginx或者Tomcat还开着往文件里写内容，直接在文件系统层面把它删掉之后，Linux内核认为这个文件仍然被进程占用，实际的磁盘块并不会立即释放。这种现象让不少新手以为系统出了bug，明明删了几十G，df一看占用率还是原来的数值。

解决这个问题有三种常用方法。

第一种是最稳当的——清空文件内容，而不是删除。操作简单，echo > huge_log_file.log，把空内容重定向回去。这样文件大小瞬间变为零，且不需要担心进程句柄出乱子。这是比较安全的做法，推荐的也是这个。

第二种方式是让应用自身重新打开一个新的日志文件。比如对Nginx服务，执行kill -USR1命令，它就会重新加载日志文件句柄，旧的日志文件则可以放心删除了。这种方式更优雅也更稳妥，不过前提是你得熟悉你所运行的服务支持的信号量。

第三种方法是重启该服务。这个是最后的手段，因为重启可能导致短暂的业务中断，但在释放被进程占用的磁盘空间上确实有效。

刚才说的那都是我碰到紧急情况时的处理方法。真正要把这个问题从源头杜绝，就需要配置logrotate，让系统自动管理和清理日志。Logrotate是Linux自带的一个日志管理工具，市面上大多数服务在安装时都会在/etc/logrotate.d/目录下自动生成默认配置文件，通常不需要手动改动已经能工作-。你可以写一个自定义配置，比如把应用日志配成每天轮转一次，保留三十天的归档，并对旧日志进行压缩。Logrotate配合cron任务自动运行后，你管理磁盘的精力就解放出来了。

如果你的美国云主机用的是systemd这种启动系统，还有一类日志文件是systemd-journald管理的，存储在/var/log/journal目录里。可以用journalctl --disk-usage查看磁盘占用，用journalctl --vacuum-size=500M或journalctl --vacuum-time=7d按容量或时间来清理旧日志。

针对各种日志的清理工作，最好还是把自动化排在首位，免得日后再次出现故障。

软件包缓存咋清理

软件包缓存的清理就比较简单直接了。

如果是Ubuntu或Debian的系统，在命令行执行sudo apt clean，就能清理掉/var/cache/apt/archives目录里所有的软件包缓存。sudo apt autoclean更温和一些，只清理掉那些已经无法从仓库下载到的过时包。CentOS或Rocky Linux这类系统，yum clean all可以把缓存一次性清空。

另外，apt-get的autoremove参数很有用。它能自动删除那些在安装软件时被当作依赖带上、但现在已经不被任何软件包需要的孤立库和工具。这些依赖往往在系统中残留很久才被发现。

Docker的磁盘清理要仔细

如果你的美国云主机上面跑过Docker，磁盘清理就要更细致一些了。

Docker最方便的地方是一行命令搞掂一切：docker system prune -af --volumes。这条命令会把所有停止的容器、悬空的镜像、未使用的网络以及未被任何容器挂载的数据卷一次性清理干净。

如果想更精确一点，不妨先跑一下docker system df，看看Docker的整体占用情况。它会显示镜像、容器和卷各自占用了多少空间，以及其中有多少是可回收的。根据输出决定删除哪些特定镜像或容器，用docker image prune删除未使用的镜像，用docker container prune清理停止的容器。

对于单个容器的日志文件，要定位精确路径在/var/lib/docker/containers目录下面，逐个找到容器的json.log文件，用truncate -s 0命令把日志清空。或者调整容器的日志驱动参数，在运行时限制每个日志文件的大小，避免以后再次产生过多日志。

数据库日志清理别大意

数据库日志是需要认真处理的。如果不小心操作，可能导致主从复制中断或数据无法恢复。

拿MySQL举例，二进制日志文件默认存储在数据目录中。用SHOW BINARY LOGS命令可以查看现有的日志列表。清理时可以按文件名PURGE BINARY LOGS TO某个特定文件，或者按时间删除PURGE BINARY LOGS BEFORE某个日期。最好的解决方式是修改MySQL的配置文件my.cnf，加上expire_logs_days参数设置日志过期天数。设置了这个参数之后，数据库会自动删除超过设定天数的binlog，无须手动干预。

如果是SQL Server环境，处理前的第一步是先备份当前的事务日志。切换恢复模式为简单模式，再执行收缩命令将日志缩减至最小容量。清理完成后，如果需要恢复完整备份能力，再切回完整恢复模式。

不管是MySQL还是SQL Server，有一条铁律必须遵守——禁止在业务高峰时段执行日志清理操作，也不要在没有最新备份的情况下贸然大面积删除数据库日志。安全第一，备份优先，这个原则不能忘。

临时文件和缓存清理也得留意

系统里还有一些零散的临时文件目录和缓存文件，同样是不容忽视的占用源。

/tmp目录和/var/tmp目录是操作系统和应用程序存放临时数据的地方，系统重启后不会自动清空这些临时文件。你可以通过sudo rm -rf /tmp/和sudo rm -rf /var/tmp/将这些目录里边的文件清空。

对于没有使用systemd管理的老旧Linux发行版，日志和临时文件还可能散落在其他地方。建议配合find命令查找七天以上未曾修改过的.tmp文件或核心转储文件，在执行删除之前先用-exec echo参数测试一下命令的查找范围，确认查出来的是正确的文件再真正删除。

遇到已删除但空间没释放怎么办

有一种情况比较隐蔽，是运维新手最容易掉进去的坑。前面提到了，明明已经把大文件给rm掉了，再跑一遍df看磁盘使用率，仍然没有变化。

这是因为该文件正在被某个进程占用，虽然文件名被删除了，但内核认为该进程还没放掉文件句柄，磁盘块无法被系统回收。

怎么确认有没有这种状况?用lsof | grep deleted这个命令。它会列出所有实际已被删除但仍在被进程打开的残留文件。如果发现确实有残留，解决方案有两种：第一，找到对应的进程，把它重启一下，进程结束以后内核就会回收那些空间;第二，如果不方便重启业务，那就采用前面说过的清空文件内容的方法，在删除之前先把日志文件内容置空。

预防胜于救灾

前面讲了那么多清理的方法和具体步骤，但回过头去看，思路也可以倒过来——与其等磁盘满了再去清理，不如提前建立起一套预防机制。

配置logrotate是毫无疑问的第一推荐。只要花点时间把配置文件写好，以后再也不用忧心日志暴增。设置监测告警同样必要。用云平台自带的监控工具，在磁盘使用率达到百分之八十时就能收到告警通知，留出从容的时间去处理，而非等到百分之九十九手忙脚乱。

建立自动化清理脚本的话，根据磁盘和历史数据的情况，可以编写一个简单的cron定时任务，每周或每月自动执行一键清理无用缓存和临时文件。同时完善备份清理策略，在服务器上定期用脚本删除一个月前生成的备份压缩包，让全量备份文件不再无限积累。

还有一个小建议：条件允许的话，尽量把系统盘和数据盘分开。操作系统和日志放在系统盘，用户的业务数据和数据库文件放在独立的数据盘。这样即使系统盘挤爆了，业务数据也不会遭殃。

在这个思路上，存储架构优化也是值得长期规划的方向。热数据放SSD提高读写性能，冷数据迁移到标准型云盘或低频访问存储类型降低成本，一些不常调用的备份数据也可以考虑分级存储策略。当短期清理解决不了眼前问题时，通过云盘在线扩容也是一种可靠的规模解法。

总结

说回开头那位朋友。我们用了一下午的时间，把近三十个G的日志文件清空，把apt的包缓存扫了一遍，又用docker system prune清理了十几个旧镜像，最后总释放出来的磁盘空间达到了将近五十个G。他的那个美国云主机从九成九的濒死状态一路降到了四成左右的正常使用率，网站重新变得流畅了。

他后来很感慨地跟我说，以前以为磁盘扩容是唯一的出路，现在才明白，原来清理和维护比扩容更值钱。

美国云主机的硬盘满了，真不是什么绝症。服务器磁盘满并不是绝症，百分之八十的紧急情况都能通过诊断加日志清理快速缓解，剩下的才需要扩容。只要掌握正确的方法，写几条命令，花点时间排查真正的空间杀手，一步一步稳扎稳打地清理，绝大多数问题都能迎刃而解。