直接答案：硬盘大小要覆盖当前有效数据、保留期内增长、日志、数据库临时空间、发布与备份峰值，再保留扩容和故障余量；硬盘性能则要看真实块大小、读写比例、队列深度和同步写延迟。容量够不代表 IOPS 够，标称 IOPS 高也不代表应用尾延迟稳定。
本文于 2026 年 9 月按公开技术文档重新核对。文中的公式用于建立可复测预算，不是厂商性能或价格承诺；实例代际、线路、计费和功能会变化，最终应以当前产品页、合同、控制台和自己的原始测试为准。
先把问题变成一张证据表
| 对象/信号 | 含义或适用场景 | 应核对的证据 | 决策边界 |
|---|---|---|---|
| 系统盘 | 系统、运行时、配置、少量日志 | 便于重装与镜像 | 不要混入唯一业务数据 |
| 数据盘 | 数据库、上传、持久化卷 | 可独立扩容与备份 | 挂载和启动顺序要验证 |
| IOPS | 小块随机操作次数 | 数据库/大量小文件敏感 | 不能替代延迟指标 |
| 吞吐 | 连续读写每秒字节 | 备份/大文件敏感 | 小块业务未必受益 |
| p99延迟 | 最慢一小部分IO | 影响尾部请求 | 平均值正常仍可能卡顿 |
这张表的作用是把“感觉够用”“听说更快”改成可以复核的条件。同一规格在不同镜像、地区、底层代际和业务模型中可能得到不同结果。对比时必须固定应用版本、数据集、测试点和时间窗口；缺少这些条件的跑分或报价，只能当线索，不能直接用于采购。
核心计算与判断模型
12个月容量 = 当前有效数据 + 月净增长×12 + 日志日增量×保留天数 + 本地备份峰值 + 临时/发布峰值 + 安全余量。若备份已可靠异地保存，本地保留仍应按恢复窗口计算，不能重复把同一份数据既忽略又算两次。
计算后还要做反向校验：如果预算推导出的配置与真实监控差异很大，先检查单位、采样周期、缓存命中、突发任务和统计口径。不要为了让公式符合预期而删掉异常样本；异常样本往往正是容量、计费或故障风险所在。
建议同时保留“正常日、业务高峰、发布/备份日”三条基线。平均值用于成本预测，峰值和尾延迟用于稳定性判断，故障演练用于恢复能力判断。三类证据回答不同问题，不能互相替代。
可执行的六步流程
第1步：先留证据，再作决定
用 df 看文件系统，用 du 按目录核对可解释数据，再检查 inode。删除前先找增长来源；数据库文件、活跃日志和未知目录不得按大小直接清理。
这一步要保留时间、测试条件、原始结果和操作者。若结果与预期不同，先回到上一项确认变量，不要同时改规格、系统、缓存和网络，否则即使现象消失，也无法知道真正起效的是哪一项。
第2步：先留证据，再作决定
连续记录至少两周的日净增长，把业务数据、上传、缓存、日志、临时文件和备份分开。用趋势而不是单日快照计算保留期。
这一步要保留时间、测试条件、原始结果和操作者。若结果与预期不同，先回到上一项确认变量，不要同时改规格、系统、缓存和网络，否则即使现象消失，也无法知道真正起效的是哪一项。
第3步：先留证据，再作决定
确认系统盘和数据盘故障域、快照能力、扩容限制与文件系统上限。扩容前后都要校验分区、文件系统和挂载，云控制台容量变化不等于系统已可用。
这一步要保留时间、测试条件、原始结果和操作者。若结果与预期不同，先回到上一项确认变量，不要同时改规格、系统、缓存和网络，否则即使现象消失，也无法知道真正起效的是哪一项。
第4步：先留证据，再作决定
fio 测试必须在隔离盘或测试文件上，声明块大小、读写比例、iodepth、直接IO与运行时长；不要对生产数据库裸设备执行破坏性写测试。
这一步要保留时间、测试条件、原始结果和操作者。若结果与预期不同，先回到上一项确认变量，不要同时改规格、系统、缓存和网络，否则即使现象消失，也无法知道真正起效的是哪一项。
第5步：先留证据，再作决定
把fio结果与应用指标对应：数据库提交延迟、Nginx上游时间、队列处理速度和备份耗时比单个峰值数字更重要。
这一步要保留时间、测试条件、原始结果和操作者。若结果与预期不同，先回到上一项确认变量，不要同时改规格、系统、缓存和网络，否则即使现象消失，也无法知道真正起效的是哪一项。
第6步：先留证据，再作决定
为容量、增长率、inode、IO延迟和队列同时设告警，并做扩容演练。已经满盘时先停止继续增长的任务并保留证据，再清理或扩容。
这一步要保留时间、测试条件、原始结果和操作者。若结果与预期不同，先回到上一项确认变量，不要同时改规格、系统、缓存和网络，否则即使现象消失，也无法知道真正起效的是哪一项。
五个最容易造成误判的做法
- 只按网站文件大小买盘
- 把快照长期保留成本遗漏
- 对生产盘直接跑写入压测
- 删除日志但进程仍持有文件
- 控制台扩容后忘记扩文件系统
这些做法共同的问题是缺少可比较条件。正确的纠偏方式不是再换一个“推荐配置”，而是把输入、阈值、失败现象和回滚条件写进记录。涉及删除数据、改防火墙、重装、扩缩容或切换 DNS 时，必须先有备份和可用的回滚入口。
上线、变更与回滚边界
先在隔离环境或小流量上验证，再逐步扩大。变更前保存配置、账单截图、监控基线和关键数据备份；变更中只改一个主要变量；变更后使用相同测试重跑。若核心业务写入失败、错误率持续上升、尾延迟越过停止阈值、数据校验不一致或管理员入口失效，应立即停止扩量并按预案回滚。
回滚不是简单恢复一个控制台选项。还要检查期间产生的新订单、表单、上传或数据库写入，明确如何合并，避免回到旧环境后丢失新数据。只读站与持续交易站的回滚难度完全不同，方案必须按业务写入特征设计。
验收清单
- [ ] 12个月增长表完整
- [ ] 块空间和inode均有余量
- [ ] 日志保留可解释
- [ ] 备份不与生产争满盘
- [ ] 真实模式IO延迟达标
- [ ] 挂载可在重启后恢复
- [ ] 扩容步骤演练过
- [ ] 监控含增长率
至少跨过一次真实高峰或等价的受控测试，并由另一位维护者按记录复现关键结果。只完成“页面能打开”不算验收；必须能解释资源、网络、费用、恢复和安全边界。验收失败时，把具体指标和时间写入问题单，而不是用“偶尔慢”“可能线路问题”结束调查。
相关站内资料与产品入口
可结合磁盘满清理顺序、数据备份与恢复、监控告警指南继续核对。需要建立隔离测试环境时，可查看美国轻量云和美国弹性云服务器的实时规格、库存及计费；本文不写死价格，也不把某个当前套餐描述成对所有业务都合适。
常见问题
50G系统盘够建站吗？
是否够取决于数据库、上传、日志、备份和增长。一个初始很小但每天增长1G的站点，50G很快耗尽；必须按保留周期算。
云盘越大性能越高吗？
有些产品会把性能与容量或等级关联，有些不会。必须核对当前产品规则并实测，不能把其他厂商经验套用。
数据库一定要单独数据盘吗？
小型业务可以共盘，但独立数据盘更便于容量、快照和重装隔离。是否拆分还要看备份、性能与故障域，而不是形式。
磁盘使用率到多少告警？
固定阈值要结合增长速率。90%但每天不增长可能可控，70%但每天增长10%更紧急；建议容量和预计耗尽时间双告警。
删文件后空间为什么没回来？
进程可能仍打开已删除文件。先用 lsof 等工具确认持有者，按业务窗口安全重载或重启对应服务，不能盲目重启整机。