清理服务器空间

内容纲要

一查看系统盘和数据盘结构

① final shell

下载final shell查看左侧菜单栏里面的“路径” 列表

系统盘（根目录 /）：
看第一行 /，查看它的“可用/大小”是 xxxK/xxxG。系统盘接近满了，这非常危险，可能会导致系统无法正常运行（比如无法写入日志、无法启动新服务）。
数据盘（挂载点 /data）：

往下看，有一个路径是 /data，它的“可用/大小”是 xxxT/xxxxT。其他：/dev、/run、/sys 等都是系统运行时的临时挂载点（如 tmpfs、devtmpfs），不用管它们，它们不占用真实的物理硬盘空间。

② 查询命令（在 FinalShell 终端中输入）

为了更准确地确认磁盘分区和挂载情况，你可以使用以下命令：

查看磁盘空间使用情况（最常用）

df -h

作用：以人类可读的格式（GB/TB）显示所有挂载点的磁盘使用情况。你可以清楚地看到 / 对应哪个分区（比如 /dev/vda1），/data 对应哪个分区（比如 /dev/vdb1）。

③ 查看物理硬盘及分区结构（推荐）

1、lsblk 会以树状图的形式，把物理硬盘（父设备）和它下面的分区（子设备）全都展示出来

lsblk

命令解读：
ls =list（列出）
blk = block （块）
列出块设备

2、查看纯粹的“物理硬盘 -> 最终挂载目录”的对应关系，过滤掉所有分区细节（vda1, vda2…）和系统自带的虚拟盘（tmpfs, loop 等）

lsblk -d -e 7 -o NAME,SIZE,TYPE,MOUNTPOINTS

-d：– no dependencies，意思是“不显示分区的从属关系”，只显示最顶层的物理磁盘（vda, vdb），隐藏掉 vda1, vda2, vda3 这些烦人的子项。
-e 7：–exclude 7，排除主设备号为 7 的设备（通常是 loop 设备，也就是系统自带的一些虚拟挂载块），防止它们干扰视线。
-o …：自定义你要的 4 列（名称、大小、类型、挂载点）。

作用：以树状图显示所有物理硬盘（如 vda, vdb）及其下的分区（如 vda1, vdb1）和挂载点。这能帮你直观地看出哪块物理盘是做系统盘的，哪块是做数据盘的。
它们分别是以下单词的缩写：
v = Virtual（虚拟的）
d = Disk（磁盘/硬盘）
a / b = 代表第一块盘、第二块盘（按英文字母顺序递增）
所以：
vda = Virtual Disk A （第一块虚拟磁盘）
vdb = Virtual Disk B （第二块虚拟磁盘）

云厂商的底层是一个庞大的分布式存储集群（比如阿里云的盘古、AWS 的 EBS 等）。购买云盘时，控制台会在底层存储池中划出对应的空间，然后通过虚拟化技术（通常是 KVM 或 Xen）将其模拟成一块标准的硬盘挂载给你的 ECS。因为是虚拟出来的，所以 Linux 内核识别到它们时，就命名为 Virtual Disk（vda, vdb…）。云服务器 (ECS)：你看到的是 vda、vdb。这是虚拟化层（Hypervisor）透传给你的“假”硬盘。对操作系统来说，它和真硬盘用起来一模一样，但底层其实是云厂商的分布式存储。
传统物理机：你插上一块 SATA 或 SAS 硬盘，Linux 识别为 sda（SCSI Disk）；插上 NVMe 固态，识别为 nvme0n1。这是直接和物理硬件对话。

举例，分析磁盘结构：

系统盘 (vda – 40G)：
vda1 (1M)：引导分区。
vda2 (200M)：EFI 引导分区，挂载在 /boot/efi。
vda3 (39.8G)：根分区，挂载在 /。（这就是你之前截图中显示只剩 20K 的那个盘）

数据盘 (vdb – 2T)：
vdb1 (16M)：可能是一个保留分区。
vdb2 (2T)：主数据分区，挂载在 /home。同时，你还在这个分区下划出了 /var/lib/docker 和 /data 的挂载点（这通常是通过 LVM 逻辑卷或者直接挂载目录实现的）。

这些分区，类似于windows系统的2块磁盘，分区，分成5个盘ABCDE（vda1、vda2、vda3、vdb1、vdb2），只是在linux中这些盘（分区）不是并列的，而是树状分布的文件结构。并且是通过挂载到文件夹目录实现了，类似于windows系统的分区分盘效果。

3、统计根目录下所有目录的归属（硬盘还是内存）
查看根目录/下，每一个目录都显示它属于哪块盘，并且不在乎它们其实是同一个物理盘（利用了 df 的底层查询）
可以明显看到112G的都是数据盘，40G的都是系统盘挂载的。

for dir in /*; do echo -e "$dir\t$(df -h "$dir" | tail -1 | awk '{print $1, $3}')"; done | column -t

其中的四个比较特殊，他们占存储空间，但是不占磁盘的空间，而是内存的空间。所以找占用元凶的时候，不要计算他们。从FinalShell的可视化界面可以看到，/run、/dev这两个目录写入的文件很少，可用空间/大小，很接近，说明划拨的上限很高，但是使用不多。
/dev devtmpfs
/proc proc
/run tmpfs
/sys sysfs

二清理空间

① 直接清理（直接有效，作用小）

第一步：清理系统日志（最安全，通常能释放几个 G）
查看 /var/log 下到底是谁占了空间

sudo du -sh /var/log/* 2>/dev/null | sort -rh | head -10

如果看到 messages、secure、cron 等文件很大，用 truncate 清空它们（不要用 rm）

sudo truncate -s 0 /var/log/messages
sudo truncate -s 0 /var/log/secure
sudo truncate -s 0 /var/log/cron

如果是 MySQL 的日志（如 /var/log/mysql/error.log），同样用 truncate 清空，然后重启 MySQL 释放句柄。

第二步：清理包管理器缓存（安全，能释放几百 M 到几个 G）
如果是 CentOS/RHEL 系统（看你提示符大概率是）

sudo yum clean all

如果是 Ubuntu/Debian 系统

sudo apt clean

第三步：处理 Docker 的“幽灵文件”（最可能的大头）
之前用 lsof +L1 可能已经发现了端倪。如果还没做，现在执行：

sudo lsof +L1 | grep "/dev/vda3"

如果看到某个进程（比如 mysqld 或 dockerd）打开了一个巨大的 (deleted) 文件，重启那个服务：
如果是 MySQL

sudo systemctl restart mysqld

如果是 Docker

sudo systemctl restart docker

重启后，被删除但没释放的 30G 空间会瞬间回到系统盘。

第四步：清理 Docker 无用数据（如果 Docker 数据还在系统盘）
清理所有停止的容器、无用的镜像和构建缓存

docker system prune -a

第五步：检查 MySQL 数据目录（长期方案）
如果 MySQL 的数据目录还在 /var/lib/mysql，那它会随着数据增长继续撑爆系统盘。建议：
停止 MySQL。
把 /var/lib/mysql 整个目录 mv 到 /data/mysql（2T 数据盘）。
修改 /etc/my.cnf，把 datadir 指向 /data/mysql。
启动 MySQL。

② 查看特定目录占用的空间

如果你的系统盘（/）已经满了，你需要找出是什么占满了空间：

sudo du -sh /* 2>/dev/null | sort -rh | head -10

或者

for dir in /*; do
    device=$(df -h "$dir" | tail -1 | awk '{print $1}')
    size=$(sudo du -shx "$dir" 2>/dev/null | awk '{print $1}')
    echo -e "$dir\t$device\t$size"
done | column -t

作用：统计根目录下各个一级文件夹的大小，并按从大到小排序，显示前 10 个。这能帮你快速定位是哪个文件夹（比如 /var/log 或 /var/lib/docker）把系统盘撑爆了。

从图中可以看出系统盘挂载的分区很多，但是只有6个是占了硬盘储存空间的，且加起来差不多是系统盘的40GB：448M + 74M + 210M + 24M + 5.5G + 34G = 756M + 5.5G + 34G=40G

③ 清理重灾空间

可以看到是mysql目录下的文件最多、最大。先关闭mysql应用，然后移走中继文件到数据盘挂载目录/data/mysql-relay。然后再重启

sudo systemctl stop mysqld

sudo mkdir -p /data/mysql_relay_backup && sudo mv /var/lib/mysql/mysql-relay-bin.* /data/mysql_relay_backup/

sudo systemctl start mysqld

df -h /

一 查看系统盘和数据盘结构