你是不是也遇到云服务器磁盘满的窘境？在云端环境里，磁盘满不仅拖慢服务，还可能让自动扩容、备份策略失效。今天我们来一站式讲清楚云服务器清理磁盘的可执行步骤，从自查到执行再到自动化，确保清理后既省钱又稳妥。
第一步先做快速自检，掌握当前磁盘使用态势。登录云服务器后，先执行 df -h 查看各分区的已用/可用空间，以及分区挂载情况。然后用 du -sh /* 或 du -sh /home /var /opt 等路径，快速定位哪些目录消耗最大。若想更直观，可以用 lsblk 查看块设备信息，结合 findmnt 了解具体挂载点。系统层面还可以用 sar 或 iostat 监控 I/O 使用，帮助判断是否真是磁盘空间吃紧而非 I/O 阻塞导致的性能瓶颈。
在完成快速自检后，下一步是把磁盘分区与挂载情况理清楚。用命令 lsblk -o NAME,SIZE,TYPE,MOUNTPOINT 可以看到每个设备及其挂载点；df -Th 可以看到文件系统类型及挂载信息。确认你清理的目标是根分区还是数据分区，避免误删系统关键文件或删除了还在使用的目录。对云服务器而言，很多时候根分区满并不需要立刻动盘，只要把高占用目录与旧数据迁移或清理即可。
日志文件往往是云服务器磁盘快速膨胀的主要元凶之一。日志轮转（logrotate）通常已经做了基本清理，但长期运行的服务会积累大量日志。先检查 /var/log 下的日志文件，按大小和时间排序，优先清理最近不再需要的日志。可以启用或调整 logrotate 的配置，将大日志分卷压缩并定期删除；对于 systemd 系统，journal 日志也可能占用大量空间，可以通过 journalctl --disk-usage 查看并结合 journalctl --vacuum-size、--vacuum-time 进行容量控制，设定合适的保留策略，避免日志无限增长。
接下来是清理系统缓存与包缓存。不同发行版有不同的命令：Debian/Ubuntu 系列可执行 apt-get clean 与 apt-get autoclean、apt-get autoremove 来移除无用包与缓存；RHEL/CentOS/D redhat 系列可以用 yum clean all、dnf autoremove 以及清理多余内核镜像。清理缓存前，确保最近需要的安装包可以从缓存中重新获取，避免影响服务重启与升级。对于容器化环境中的镜像缓存，也要定期 prune 无用镜像与未使用的容器，以释放磁盘空间。
临时文件和缓存目录也不容忽视。/tmp、/var/tmp 下往往存放着大量临时文件，很多应用在重启后会清理，但有些临时文件可能长期存在。可以定期清理过期的临时文件，确保在执行删除前先做备份或移动，必要时设置自动清理策略。对运行中的服务，优先排查并清理不会再次被创建的临时数据，以避免误删造成服务端出错。
大文件与重复数据的清理，是快速释放空间的另一条主线。先用 find / -type f -size +100M 进行筛选，产出候选大文件清单，再逐一确认是否确实需要保留或可迁移到备份存储。对日志以外的大文件，可以考虑移动到冷数据存储、分区压缩或删减，然后再做跨分区的整理。对于数据库导出、缓存、备份文件等，尽量将它们移到专用数据分区或对象存储，避免占用根分区空间。
镜像、容器和快照管理在云环境中尤为关键。容器镜像、未使用的镜像层、已经停止的容器以及未使用的卷都可能占用大量磁盘。对于 Docker 用户，执行 docker system prune -a --volumes 可以清理无用镜像、已停止的容器以及未使用的卷，但在生产环境中请确保不会误删仍在使用的资源，必要时执行 dry-run 先确认再执行。对于 Kubernetes 场景，定期清理未使用的 PV/PVC、旧的限时快照和不再需要的配置，减少持久卷的占用。云平台层面的快照也别忘了检查——删除不再需要的快照与未挂载的磁盘快照，能快速腾出空间。
数据库日志与归档数据通常也是磁盘持续膨胀的隐形推手。对 MySQL、PostgreSQL 等数据库，要评估 binlog、归档日志、AWR/PG Statistics 等日志的大小与保存策略。MySQL 的 binary log 可以在达到一定大小或时间后清理，执行 mysqladmin flush-logs 或配置 expire_logs_days，避免未归档的数据堆积；PostgreSQL 则可以定期归档日志并清理过时的归档文件，必要时结合 WAL 归档策略进行容量控制。需要注意的是，这类操作应在保证数据可用性和备份策略的前提下执行，避免误删导致数据丢失。
文件系统层面的优化也不可忽略。针对 SSD/云盘，fstrim -av 可以对支持 discard 的文件系统进行空区回收，帮助底层云盘回收未使用块，提高写入性能和空间利用率。若云盘不支持 discard，请考虑定期的离线碎片整理与文件压缩策略，以及对热数据与冷数据的分层存放。对于需要高性能的场景，可以考虑开启合适的 I/O 调度策略（如 cfq、deadline、noop 等），并结合实际 workloads 调整调度和缓存策略。
自动化与计划任务是让清理变成日常、不是一次性猛冲的关键。可以通过 cron 定时执行清理脚本，或在 systemd 中建立 timer 来周期性执行日志轮换、缓存清理、临时文件清理等操作。将清理任务分成几个阶段执行，避免一次性清空导致服务短暂中断。为了安全，先做 dry-run、再逐步放开执行权，确保在圆满完成前不会影响生产流程。
在云平台层面，清理还要结合云提供商的特性与最佳实践。AWS 场景要关注未使用的 EBS 卷、快照以及实例的卷使用情况；Azure 环境要检查托管磁盘、快照和辅助存储的占用；GCP 用户应清理未使用的磁盘、快照与镜像，并利用持续监控优化磁盘分区与扩容策略。若你使用的是混合云或私有云系统，建立统一的磁盘使用监控与告警阈值，是避免容量突然告罄的有效手段。记住，容量管理不是一次性动作，而是持续的守护。
执行之前请务必做好备份与回滚计划。清理之前，尽量将重要数据迁移到备份存储或云对象存储，确保在误删或删错的情况下有可恢复的版本。清理策略要有分阶段的优先级：先处理最紧急、影响最大的区域（如根分区的日志和缓存），再处理次要区域；同时保持对关键服务的监控与恢复办法，避免清理过程对服务可用性造成冲击。顺便提一句，清理之余也别忘了提升存储质量——如果经常遇到容量瓶颈，可能是存储等级或性能不匹配导致的长期问题，需要从设计层面优化。
广告时间到了，玩游戏想要赚零花钱就上七评赏金榜，网站地址：bbs.77.ink
最后，脑力活儿也需要一点小聪明。如果你把云服务器的磁盘清理做到位，系统会不会突然学会自我管理、自己腾出空间？或者说，磁盘里到底住着一个会吃掉空间的妖怪，还是你自己不小心把数据变成了会跑的影子？当你以为已经把所有大文件都清理干净时，新的异常又出现了——你准备好迎接这个谜题了吗