云主机扩容加数据盘，先做哪些检查更稳妥

业务一上量，很多团队最先碰到的是磁盘先告警。日志涨得快，图片和附件越积越多，数据库备份也没地方放。这时候常见处理办法就是云主机扩容加入数据盘。看着像一项基础操作，实际牵扯到目录规划、数据迁移、权限设置和回退安排，做得急，后面很容易出问题。

对中小企业、创业团队，或者刚把业务搬到云上的公司来说，加数据盘本身不算难，难的是在影响尽量小的前提下把这件事做稳。尤其是线上机器已经跑着订单、上传、后台管理这类服务时，很多问题会出在加完之后怎么挂、怎么迁、怎么保留回退路径。

为什么会走到加入数据盘这一步

云上业务增长通常不太均匀。前期一台机器既跑应用，也顺手存图片、日志、备份，空间看起来还够；等活动期、内容增长期或者订单高峰来了，系统盘很快就吃紧。相比直接迁移整台服务器，云主机扩容加入数据盘通常更快，也更容易控制变更范围。

• 系统盘已经放了系统和应用，不适合继续堆大量业务数据
• 想把上传文件、日志、备份拆开，后面查问题和清理都方便
• 数据库或缓存周边文件需要单独路径，便于后续做性能和容量管理
• 预期后面还会继续扩容，先把存储层次理顺
• 当前只是空间不足，没必要直接把整机规格一起拉高

很多时候，这不只是“多挂一块硬盘”，也是顺手把存储结构理清楚的机会。

先分清：扩原有磁盘，还是新增数据盘

不少人会把“磁盘扩容”和“新增数据盘”当成一回事。两种方式都能解决容量不够的问题，但适合的场景不一样。

直接扩容原有磁盘

如果原有分区结构比较清楚，应用写入路径也已经固定，而且当前这块盘的性能没有明显短板，直接扩原盘会省事一些。路径不用改，业务配置变动少，风险点主要集中在分区和文件系统扩展。

问题也很明显：如果系统盘本来就塞了太多数据，继续往上加，只是把空间问题往后推。后面做日志清理、目录拆分、数据迁移，还是会麻烦。

新增并挂载数据盘

这就是常说的云主机扩容加入数据盘。新加一块盘，格式化后挂到指定目录，比如 /data、/backup、/www/uploads。这样做的好处很直接：目录职责清楚，后面继续加盘、迁移到对象存储，或者把不同类型的数据分开管理，都更顺手。

如果你现在已经意识到系统盘里什么都在放，新增数据盘通常比继续把原盘做大更合适。

动手前，先把这几项检查做完

先查清楚是谁把空间吃掉了

看到磁盘满，不要立刻下判断。有的机器是日志失控，有的是数据库二进制日志长期没清，有的是临时文件和历史备份堆满了系统盘。还有一种情况，业务目录本身没多大，结果容器镜像、缓存目录、构建文件把盘占光了。

这一步决定你是在解决问题，还是只是在延后问题。根因没处理，加了盘以后，告警大概率还会回来。

先定好新盘到底放什么

新增数据盘之前，先把用途写明白。图片、附件、静态资源，适合独立目录；日志最好和业务数据分开，免得一个暴涨把另一个挤掉；数据库文件对 IO 和一致性更敏感，迁移前要确认应用和服务是否支持；备份文件如果长期堆在同一台机器上，意义本来就有限。

常见做法是把新盘只承担一类或两类明确数据，不要今天放上传，明天放日志，后天又塞数据库备份。目录用途一旦混乱，后面清理、备份、迁移都会跟着乱。

评估是否要安排停机窗口

如果只是新增盘并挂到一个全新的空目录，风险通常不高。但只要涉及历史数据迁移、应用路径切换、软链接替换，最好别在业务高峰时直接上。数据库、订单系统、上传服务这类场景，在线搬迁很容易出现文件仍在写入、迁移前后数据不一致、权限变化后应用报错这些问题。

实际操作里，低峰期做切换会稳很多。哪怕不完全停机，也应该留出观察时间。

备份要做在变更前面

这条听起来老，但经常被省掉。加盘本身不太会造成数据损坏，风险更多出在后面的分区、格式化、挂载、迁移和权限修改。快照、数据库备份、关键目录打包，至少保留一份能恢复的副本。否则一旦目录挂错、迁移不完整或者配置改坏了，只能硬着头皮在线修。

云主机扩容加入数据盘，一般按这个顺序做

不同云平台控制台叫法会有差异，但流程基本差不多，顺序不要乱：

1. 在云平台新增数据盘，确认容量、性能类型、可用区这些基础参数匹配当前主机。
2. 把数据盘挂载到目标云主机，别挂错实例，尤其是环境多的时候。
3. 登录服务器识别新磁盘，确认设备名称，先看清楚再动手。
4. 按需要创建分区，或者直接在整盘上创建文件系统。这里要确认你操作的是新盘，不是已有业务盘。
5. 格式化成合适的文件系统，和现有运维习惯保持一致，后面维护方便。
6. 创建挂载目录，尽量用清晰、固定的路径，比如 /data、/backup、/appdata。
7. 先手动挂载，做读写测试，确认没有报错、权限也正常。
8. 配置开机自动挂载。很多事故就出在这里，重启后业务目录直接丢挂载。
9. 确认挂载稳定后，再做业务数据迁移、权限调整和应用配置修改。

先验证挂载，再迁移数据，这一步不要省。新盘刚建好就直接覆盖原目录，回退会很难看。

一个常见场景：活动前临时发现磁盘不够

有些团队平时一台 4 核 8G 的云主机同时跑应用和后台，图片上传、活动海报也都放本机。平常看不出问题，一到节日前促销，运营集中上传素材，磁盘使用率从 68% 一路涨到 92%。这时候开发第一反应常常是删旧文件，但真查起来，历史订单截图、售后凭证、活动图片都还得留，根本删不动。

这种情况，云主机扩容加入数据盘通常比临时清理更靠谱。比如新增一块数据盘挂到 /data，专门放上传文件和图片缓存。真正能把风险压下来的，是处理顺序：

• 先做系统快照，迁移时目录错了还能回退。
• 先在测试环境验证上传路径修改是否生效，别直接在线上试。
• 旧上传目录先打包备份，再迁移，避免迁过去才发现少文件。
• 迁移完成后，原目录先保留一段时间，只读核对，别急着删。
• 顺手把日志目录整理出来，不让系统盘继续被慢慢吃满。

这样处理，活动期间空间压力能先缓下来，后面如果要再接对象存储，迁移路径也更清楚。

几个特别容易踩的坑

重启后挂载失效

手动挂载成功，只说明当前会话里能用，不代表服务器下次启动后还在。没有正确配置开机自动挂载，应用一重启就可能找不到数据目录。这个问题常见，而且往往发生在大家以为“已经弄好了”之后。

把新盘直接挂到有内容的目录上

比如 /data 里原本已经有文件，结果新盘直接挂上去，原来的内容立刻“看不见”。很多人会以为数据没了，其实只是被新的挂载点遮住了。更稳妥的做法是先挂到空目录，确认没问题，再迁移原有内容。

权限没跟着处理

Web 服务用户、应用进程用户、数据库用户可能都不同。新盘挂上以后，如果属主、属组或者目录权限没改对，常见结果就是上传失败、写日志报错、缓存目录不可写。这类问题不一定马上爆出来，有时业务还能打开，就是局部功能开始异常。

加了盘，却没顺手做治理

如果日志还是无限涨，备份还是长期堆本机，临时文件还是没人清，扩容只能救一时。很多机器会出问题，是因为存储一直没有规则。盘越加越多，问题越难查。

哪些情况不适合只靠加入数据盘

云主机扩容加入数据盘适合大多数容量告急的场景，但它不是万能方案。下面几类情况，要把视线放远一点：

• 单机数据库已经明显有性能瓶颈，问题不只是容量。
• 大量静态文件长期放本机，已经影响多机部署和扩缩容。
• 业务准备做容器化，本地盘依赖太重，后面迁起来会很别扭。
• 备份、归档、冷热数据分层一直没有规划，盘再多也只是继续堆。

这种时候，加数据盘可以先止血，但更长期的方向通常会转向对象存储、NAS、数据库分离、日志集中化，或者直接调整应用的存储架构。

加完数据盘后，还要补几件事

很多团队做完挂载和迁移就收工，过几个月又因为同样的问题报警。要避免反复折腾，最好把后续维护一起补上：

• 把磁盘使用率监控和告警阈值设好，别等到 90% 以上才发现。
• 记录挂载信息、目录用途和变更时间，避免后面接手的人看不懂。
• 给日志清理、备份保留、归档周期定规则，不靠临时人工处理。
• 检查应用配置，确认新写入的数据确实走到新盘，不要一部分还落回系统盘。
• 定期做恢复验证，不要只看到“备份成功”就当没问题。

云主机扩容加入数据盘并不难，麻烦的地方在于前面要检查，过程中要验证，后面还得继续维护。空间告急时先别急着加，先看谁在占、该放哪儿、要不要停机、能不能回退。这样做，扩容才是在解决问题。