刚买的Linux云服务器，第一件事不是急着部署环境，而是先把磁盘看清楚。我见过太多用户，明明买了数据盘，在服务器上敲df -h却只看到几十G的根分区，然后一脸懵地来找我：“我20G数据盘哪儿去了？”或者更常见的版本——数据盘压根没挂载，网站图片全部写进了系统盘，最后系统盘满到服务直接挂掉。
这篇东西不聊虚的，就把系统磁盘和数据盘的区别、怎么识别文件到底存在哪块盘上、数据盘“消失”是什么原因、以及新盘到手怎么正确挂载，一次性讲透。内容基于阿里云、腾讯云、华为云以及各类国产Linux发行版上的通用实践，你拿到任何一台Linux云服务器都能照着操作。
1. 系统盘和数据盘，差的不是“名字”而是“命”
很多刚接触云服务器的人，把系统盘理解为电脑上的C盘，数据盘理解为D盘。这个类比方向没错，但云服务器上的逻辑差得远。搞懂它们的本质区别，后面所有排查和规划才有基础。
1.1 系统盘：承载生命线的盘
系统盘是实例的启动盘，装的就是操作系统本身——内核、系统库、启动引导、系统级的/etc、/usr、/var等等。云平台在创建实例的时候，会从你选的镜像（比如Ubuntu 22.04、CentOS 7.9、麒麟V10）把这个盘“克隆”出来，作为实例的根文件系统。它的设备名在绝大多数主流云厂商的KVM虚拟化环境下通常表现为/dev/vda，分区是/dev/vda1。
这块盘的生死和实例深度绑定。你用控制台重置系统、更换操作系统、或者直接释放实例的时候，系统盘上的所有数据会一并清空。这不是“小心格式化”的问题，而是平台层面的操作就直接重建这块盘。
1.2 数据盘：真正用来装家当的地方
数据盘是你额外购买并挂载给实例的块存储。它不承载任何系统运行必需的组件，就是一个被格式化成文件系统的空盘。典型设备名是/dev/vdb、/dev/vdc这样往后排，依此类推。
为什么要单独买数据盘而不是直接在系统盘里建目录？我讲三个理由，这三点也是你将来做存储规划的判断依据：
- 数据生命周期不同。系统盘跟着实例走，重装系统它就没；数据盘是可以解绑后挂到另一台实例上的。它相当于一块可以“拆下来带走”的硬盘，系统盘则相当于焊死在主板上的那块。
- 容量费率不同。同类型云盘，按块计费，系统盘往往容量受限（默认40G/50G），数据盘可以单块加到几TB，而且可以随时扩容。把大文件堆在系统盘里，扩容量不仅麻烦，日志一涨还可能把盘撑爆。
- 故障域隔离。独立的块存储设备在底层故障、I/O占用方面互不影响。系统盘I/O被打满，至少数据盘上的读写还能抢救一下。如果你把数据库文件放在系统盘上，日志一刷I/O爆掉，数据库跟着死。
基于这些差异，我自己的习惯是：系统盘只放操作系统和应用程序二进制，业务数据、日志文件、数据库数据文件、网站上传目录，一律挂数据盘。
1.3 一个必须破除的误解：“我买的50G怎么只剩30G？”
这是新手向客服提问频率最高的问题之一。你买云服务器时标注的“50G”通常指系统盘容量，但这50G不是全部可用的。操作系统、系统保留分区、初始化分区等会吃掉一部分，df -h看到的根分区可用量会小于标称值。更关键的是，这50G是系统盘，和你单独加购的“数据盘”是两码事。
所以判断一台实例的存储配置，不要只看购买页面的数字，而是用下面第二节的命令去看实际盘符和挂载情况。
2. 快速判定当前磁盘状态：哪块是系统盘、哪块是数据盘
我接到“帮我看下服务器磁盘”这样的活时，第一轮一定是敲下面三个命令。这三个命令分别解决“有几块盘”“盘长什么样”“分区和文件系统状态”三个问题，组合起来就能完整还原一台实例的存储拓扑。
2.1 lsblk：看清盘符与分区层次
lsblk是我的首选，因为它把磁盘、分区、挂载点之间的关系用树状结构一次呈现清楚。
lsblk输出示例：
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS vda 253:0 0 40G 0 disk ├─vda1 253:1 0 40G 0 part / vdb 253:16 0 100G 0 disk └─vdb1 253:17 0 100G 0 part /data这里一眼就能看出：vda是系统盘，40G，只有一个分区vda1挂载在根目录；vdb是数据盘，100G，分区vdb1挂载在/data。如果数据盘买回来但没人挂载，你会看到vdb存在，下面却没有分区、没有MOUNTPOINTS——这就是“数据盘不见了”的最常见形态。
lsblk还有一个加参数的版本：lsblk -f，会额外显示每个分区的文件系统类型和UUID。这个UUID在配置开机自动挂载时极其重要，后面第五节会专门讲。
2.2 df -hT：看文件系统可用空间与实际挂载
lsblk告诉你“有哪些盘”，df告诉你“这些盘用成什么样了”。
df -hT输出示例：
Filesystem Type Size Used Avail Use% Mounted on /dev/vda1 ext4 40G 15G 23G 40% / /dev/vdb1 ext4 100G 30G 66G 32% /data tmpfs tmpfs 1.6G 0 1.6G 0% /dev/shm-T参数显示文件系统类型（ext4、xfs、ntfs等），-h把容量转成人能看懂的单位。这个命令用来定位“哪个目录满了”最直接——比如你想知道网站根目录/var/www/html所在的分区还剩多少空间：
df -hT /var/www/html它会自动向上回溯，显示包含这个路径最近一级挂载点的磁盘空间使用情况。这是识别文件存储位置的常用手段。
2.3 fdisk -l：看底层磁盘与分区表的真实面貌
有些场景下lsblk还不够，比如云平台挂载的裸盘没分区，或分区表异常，需要用fdisk看底层识别状态：
sudo fdisk -l这个命令不需要文件系统参与，直接读取磁盘的分区表。注意：fdisk -l输出可能包含一些虚拟设备（如loop设备，那是snap/docker等用的回环设备，忽略即可），真正要关注的是Disk /dev/vda:和Disk /dev/vdb:这样的物理盘块。如果fdisk -l能看到/dev/vdb但lsblk里没有对应分区，说明这块数据盘是裸盘状态，需要走分区、格式化、挂载的流程（第五节）。
2.4 云控制台与实际盘符的对应
每个云厂商的控制台都会在实例详情里列出“系统盘”和“数据盘”两块云盘的容量、属性、挂载信息。但控制台显示的是云盘ID（如d-xxxx），Linux系统里显示的是vda、vdb，二者怎么对应？我习惯用容量来对，实在要精确确认，可以用来下面的命令：
sudo blockdev --getsize64 /dev/vdb返回的是字节数，除以1024的三次方就是GB，和控制台某块云盘的容量一致，就能对上了。绝大多数情况下，/dev/vda都是系统盘，这个顺序在KVM虚拟化下是固定的。但这不绝对，自己做实验时养成“按容量对盘”的习惯，能避免很多误操作。
3. 文件存储位置的识别：挂载点是门牌号
新手最容易绕晕的地方在于：Linux里的“文件在哪个盘上”不是看它在哪个目录，而是看这个目录落在哪个挂载点下面。挂载点就是“门牌号”，磁盘是“房子”，一个目录挂载了某块盘，那这个目录下的所有文件就存在这块盘上。
3.1 挂载的本质一句话
挂载（mount）就是把一块存储设备关联到目录树上的某个节点。关联完成后，你对这个目录的读写，实际上是读写那块设备。比如：
sudo mount /dev/vdb1 /data执行之后，/data目录就变成/dev/vdb1这100G数据盘的入口。原来/data里如果有文件，会被临时“遮住”，直到卸载后才重现。这解释了为什么挂载前一定要确认挂载点是空目录——否则文件“不见了”不是真没了，而是被新挂载点盖住了。
3.2 一个文件到底在哪块盘？用df追根溯源
识别任意路径的存储归属，df是标准答案：
df -h /var/lib/mysql/ibdata1如果输出显示Filesystem列是/dev/vdb1，那这个数据库文件就存在数据盘上；如果显示的是/dev/vda1，它就在系统盘里。
批量检查时，可以把find和df组合起来，比如找出站点根目录下所有文件所在的分区分布：
find /var/www -type f | xargs df -h --total 2>/dev/null | tail -1这只是看总量的方式。更实用的是判断某个目录树是否跨盘：如果在/data目录下执行df -h .，结果一直显示/dev/vdb1，那说明这块站点目录整体落在数据盘上。
3.3 别把空间占满才想起查位置：du与inode
识别存储位置的另一面，是搞清楚哪里的空间在被谁吃掉。这里有一个经典误区：du统计出来的“目录大小”和df显示的“分区已用量”不一致时，通常是有文件被删除但进程仍持有句柄，或者是inode被打满。inode问题在实际生产中比想象中常见得多。
df -i如果IUse%到了100%，即使空间还剩几个G，你也无法创建任何新文件，数据库会直接报“No space left on device”。排查这种问题时，别只盯df -h，df -i一定能帮到你。定位具体目录占用过大的方方向：
sudo du -h --max-depth=1 /data | sort -hr | head -20这条命令能快速列出/data下各子目录的体积排名。很多场景下，日志文件（比如/var/log/nginx/access.log）会比数据库文件更早撑爆磁盘。
3.4 国产系统上的特殊情况
近两年用国产Linux（麒麟、统信UOS）的服务器越来越多，这类系统的识别逻辑和标准Linux完全一致，lsblk、df、du照常可用。但确实有用户反馈“在桌面环境里看不到数据盘”，原因通常是：
- 数据盘没有分区表，系统桌面环境不会自动列出裸设备。
- 有分区但没有挂载，桌面文件管理器默认只显示已挂载的卷。
- 文件系统格式不被识别（比如Windows下初始化的NTFS分区，在国产系统上默认不自动挂载）。
解决办法就是走标准的fdisk/mkfs/mount流程，或者用发行版自带的“磁盘”工具（通常是GNOME Disks，即gnome-disk-utility）挂载并设置开机自动挂载。图形工具在设置里勾选“Mount at system startup”后，它写入的其实还是/etc/fstab，原理和命令行一样。
4. 数据盘“不见了”：从现象到根因的完整排查链路
“我明明买了数据盘，服务器上看不到”——这是云服务器场景下最常遇到的求助问题。我按实际发生频率排序，给你一条完整的排查链路。
4.1 怀疑点一：压根没挂载到这台实例上
登录云控制台，找到实例的“云盘”或“磁盘”列表，确认：
- 是否存在一块独立的数据盘。
- 状态是否是“使用中/已挂载”。
- 挂载的实例ID是不是当前这台的实例ID。
如果你买的是包年包月实例，但数据盘按量付费购买时选错了可用区，或者购买后没有点“挂载”按钮，它可能处于“待挂载”状态。这种情况下lsblk根本看不到对应的vdb，因为块设备还没挂到实例的总线上。
4.2 怀疑点二：挂载了，但系统里没有分区/文件系统
控制台显示“已挂载”，但实例里lsblk能看到vdb裸盘，没有vdb1分区。这种情况常见于两块场景：一是刚把数据盘从旧实例卸载后挂到新实例，旧盘上没有可识别的分区表或文件系统；二是按云厂商文档初始化数据盘时漏掉了分区步骤，只建了裸盘。
处理方式：在确认盘上无重要数据的前提下，对整个盘重新做分区、格式化、挂载。注意“确认无重要数据”是最高优先级前置条件。
4.3 怀疑点三：挂载了，但重启后“又不见了”
这是排障中极具迷惑性的现象，特征是：
- 刚mount完一切正常，文件也能写入。
- 一重启服务器，
df -h里就看不到/data了。 - 但
lsblk里vdb1还在。
根因几乎必然是：没有配置/etc/fstab开机自动挂载。内存中的挂载关系在重启后会全部丢失，Linux不会因为你“之前挂过”就替你记住。这也是为什么每次排查重启丢失问题时，我的标准动作是：
cat /etc/fstab看到/dev/vdb1不在里面，直接实锤。千万不要以为重启后挂载关系会保留——这是Linux新手最容易踩的坑。
4.4 怀疑点四：文件系统损坏或驱动问题
如果lsblk能看到分区，但mount时报错，比如：
mount: /data: wrong fs type, bad option, bad superblock on /dev/vdb1可能原因：
- 分区里没有文件系统（没格式化）。
- 文件系统类型和
mount -t指定的不一致。 - 文件系统有损坏，superblock异常。
先确认文件系统类型，再决定修复还是重建：
sudo blkid /dev/vdb1有TYPE="ext4"或TYPE="xfs"输出，且数据不重要，直接重新格式化最省事；数据重要，建议先镜像出来再处理，不要在损坏的文件系统上反复重试挂载。
4.5 排查顺序总结
我建议的排查顺序是“控制台确认存在性 → lsblk确认设备可见性 → blkid确认文件系统 → fstab确认开机持久化”。按这个顺序，90%的“数据盘不见了”问题能在五分钟内定位。我自己处理过的case里，占比最高的是4.3（没写fstab），其次是4.1（买错了没挂），4.4最少，但一旦出现，往往意味着数据盘本身或文件系统层有问题，需要更谨慎对待。
5. 新数据盘到手：分区、格式化、挂载、开机自动挂载全流程
抛开云厂商自带的一键初始化脚本，我建议每个人都手动完整走一遍流程。这不仅是为了学会操作，更是为了理解每一步在做什么。下面这些步骤基于常见Linux发行版和一块全新的/dev/vdb（100G）数据盘。
5.1 分区
对整块盘建一个分区，使用fdisk交互式命令：
sudo fdisk /dev/vdb按n新建分区，按p选主分区，分区编号默认1，起始扇区和结束扇区直接回车取默认值（即整块盘），最后按w写入并退出。
结束后检查：
sudo lsblk应当能看到vdb1了。这里刻意不提GPT和MBR的差异，因为2T以下的单盘，fdisk的默认MBR逻辑完全够用；超过2T建议用parted或gdisk做GPT分区表。实际操作中，对一块全新的数据盘，多数云厂商文档也直接建议只分区一次整盘为一个区。
5.2 格式化
sudo mkfs.ext4 /dev/vdb1文件系统选ext4还是xfs是个老问题。我的倾向：通用业务负载、需要兼容性，选ext4；高并发大文件顺序读写场景（比如大数据、视频流），选xfs。两者都是成熟稳定的文件系统，不用过度纠结。格式化的本质是向分区写入文件系统元数据，会清除整个分区上的数据，执行前务必确认盘符没搞错。
一个极其重要的提醒：确认盘符时要同时比对设备名和容量。我见过有人在实例中新挂了一块/dev/vdc，敲命令时习惯性复制了/dev/vdb的格式化指令，直接把旧数据盘洗掉了。所以我的习惯是格式化前先执行：
sudo lsblk -o NAME,SIZE,MODEL,MOUNTPOINT看清SIZE列与控制台数据盘容量一致后再动手。
5.3 创建挂载点并挂载
sudo mkdir -p /data sudo mount /dev/vdb1 /datamkdir -p即使目录已存在也不会报错。挂载后验证：
df -hT /data看到/dev/vdb1 ext4 98G之类的输出，说明挂载成功，现在已经可以往/data写入文件了。
5.4 配置开机自动挂载（fstab与UUID）
临时挂载重启即失，所以必须写入/etc/fstab。这里强烈建议用分区的UUID而非设备名，理由：设备名在部分场景下可能漂移（比如同时挂多块云盘时，重启后内核枚举顺序可能变化，/dev/vdb可能变成/dev/vdc），而UUID是文件系统创建时生成的唯一标识，只要文件系统没重建，UUID就不会变。
获取UUID：
sudo blkid /dev/vdb1输出类似：
/dev/vdb1: UUID="a1b2c3d4-...." TYPE="ext4"然后编辑/etc/fstab：
sudo vim /etc/fstab追加一行：
UUID=a1b2c3d4-.... /data ext4 defaults 0 2四列的含义分别是：设备标识、挂载点、文件系统类型、挂载选项；第五列0表示不用dump备份，第六列2表示非根文件系统，开机时在根文件系统之后做fsck检查。根分区在fstab里通常写0 1。
写完不要急着重启验证，先用mount -a模拟加载一遍：
sudo mount -a这条命令会读取fstab并挂载其中尚未挂载的设备。如果fstab写错（比如UUID串错），mount -a会立刻报错，趁现在改还来得及；如果直接重启，写错fstab可能导致系统无法正常启动，只能进救援模式修复。
5.5 另一种常见做法：整块盘不分区直接用
有些云厂商的一键挂载脚本会把整块裸盘直接格式化成文件系统挂载，不建分区。比如mkfs.ext4 /dev/vdb，然后mount /dev/vdb /data。这种做法技术上可行，但我不推荐在生产环境用。分区的意义在于：将来如果文件系统损坏，分区表还在，你能相对容易地找回数据；而且分区后还可以在同一块盘上规划不同用途的多个逻辑区域。多一层分区，多一份灵活和保险。
6. 存储规划与运维习惯：值得长期坚持的几个建议
最后这部分是我这些年做云服务器运维沉淀下来的一些经验，很多都是拿真金白银踩出来的教训。
6.1 业务目录和系统目录分开，这是底线
无论你是跑个人博客、小型电商、还是企业管理系统，都要把数据和程序分开目录。我的常用划分是：
/根目录：只放系统。/data或/srv：挂数据盘，统一存放业务数据。/data/mysql：数据库数据文件。/data/www：网站代码。/data/logs：所有业务日志。
这样划分的好处是：重装系统数据不丢，备份时单独对/data做快照即可，扩容时只需要扩数据盘。系统盘出问题，数据盘卸下来挂到新实例上，业务快速恢复。
6.2 定期巡检磁盘：别等服务挂掉才看监控
磁盘满、inode满、文件系统只读——这三个问题在云服务器上是导致服务异常的最高频存储类故障。我建议至少每周执行一次：
df -hT df -i看到Use%超过80%就开始清理，超过90%必须立即处理。日志轮转（logrotate）是“磁盘悄悄满掉”的隐形凶手和救星，确保你的nginx、mysql、应用日志都配置了合理的轮转策略。比如nginx日志：
/var/log/nginx/*.log { daily rotate 14 compress delaycompress missingok notifempty create 0640 www-data adm sharedscripts postrotate [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid` endscript }这个配置我几乎原样复制到了每台生产服务器上，配好之后，日志导致的磁盘满问题基本绝迹。
6.3 扩容前先备份，迁移时先停写
数据盘扩容是运维中的高危操作。云控制台支持在线扩容的前提是文件系统支持在线扩展（ext4和xfs都可以），但任何一次容量调整都伴随风险。我的标准流程是：
- 先打快照（云盘快照）或做文件级备份。
- 在业务低峰期操作。
- 扩容后执行
resize2fs /dev/vdb1（ext4）或xfs_growfs /data（xfs）让文件系统感知新容量。
迁移数据盘到新实例时，一定要先停掉相关服务，避免数据盘中文件在拷贝过程中被修改导致不一致。比较稳妥的做法是：停止应用 → 执行最后一次增量同步 → 卸载数据盘 → 挂到新实例 → 恢复应用。
6.4 一个关于系统盘的小建议
如果云厂商允许，系统盘容量往大的选（比如默认40G就选40G，别去省那20G差价）。系统盘空间紧张会直接导致/tmp满、日志写不进去、软件包装不上，而这些问题的排查成本远超省下的几块钱。应用和代码放系统盘没问题，但大体积文件、日志、数据库文件，请一律交给数据盘。
这块内容其实还可以接着聊细分区、LVM逻辑卷、云盘快照策略这些高级话题，但本质上，先把“系统盘和数据盘怎么区分、文件存在哪、盘找不到了怎么办”这三件事弄清楚，你在这个方向上的底子就算打扎实了。
