香港AMD EPYC 4585PX服务器上线前，怎样检查磁盘容量与备份恢复能力
面向准备上线香港AMD EPYC 4585PX服务器的运维与项目人员，说明如何核对磁盘拓扑、RAID、挂载、容量及inode余量，并通过隔离恢复验证备份可用性、RPO与RTO，同时给出异常分界、留证和复测方法。
服务器上线前，不能只看控制面板显示的“磁盘容量”。真正需要验收的是：操作系统识别到多少可用空间、存储拓扑是否符合交付信息、业务增长后会不会迅速占满，以及备份能否在约定时间内恢复。
AMD EPYC 4585PX代表计算平台，并不能证明磁盘数量、RAID状态或备份能力。验收香港服务器时，应把容量检查与恢复演练分开：前者确认“装得下并能持续运行”，后者确认“故障后拿得回来”。
先确定可执行的验收标准
检查前应向交付方或内部项目负责人确认以下信息：
- 磁盘数量、单盘容量、介质类型及存储控制方式。
- RAID级别，以及标称容量与RAID后预计可用容量。
- 系统盘、数据盘、日志盘和备份缓存目录的规划。
- 初始数据量、每日净增长量、业务峰值产生的临时文件量。
- 备份对象、执行频率、保留周期和存放位置。
- 可接受的数据丢失窗口RPO，以及恢复所需时间RTO。
- 恢复范围是单文件、数据库、应用目录，还是整机。
容量不能用统一的“剩余百分比”判断。更合理的计算方式是：
所需可用容量 = 初始数据量
+ 日净增长量 × 规划周期
+ 日志、缓存和上传临时文件峰值
+ 本地快照或备份缓存占用
+ 运维预留空间
如果增长量暂时未知，应先导入接近正式规模的数据，连续记录一段有代表性的业务周期，再据此计算。不要把RAID冗余、磁盘快照视为独立备份；误删除、文件系统损坏或账号失陷可能同时影响这些副本。
从物理磁盘检查到文件系统容量
以下命令适用于常见Linux环境，均为只读检查。执行前仍应确认系统类型和权限；硬件RAID通常还需要控制器厂商提供的管理工具，不能只依赖操作系统输出。
uname -a
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL
findmnt
df -hT
df -i
cat /proc/mdstat
重点核对四个层次：
lsblk显示的磁盘数量和容量是否与交付信息一致。- RAID或逻辑卷形成的可用容量是否符合预期。
- 数据目录是否确实挂载到规划的数据盘，而不是落在系统盘根目录。
df -hT与df -i是否都留有增长空间。
磁盘有空间但inode耗尽时，系统仍会无法创建文件。日志、小图片、缓存分片等大量小文件场景尤其要检查df -i。如果某个业务目录没有独立挂载，findmnt可以帮助确认它实际属于哪个文件系统。
采用LVM的服务器还可执行：
sudo pvs
sudo vgs
sudo lvs -a -o +devices
这可以区分“卷组仍有未分配空间”和“文件系统已经扩展可用”。两者并不等价，不能只看卷组剩余量。
Windows Server可使用只读PowerShell命令核对磁盘与卷：
Get-Disk
Get-Partition
Get-Volume | Select-Object DriveLetter, FileSystem, HealthStatus, Size, SizeRemaining
Get-PhysicalDisk | Select-Object FriendlyName, MediaType, HealthStatus, OperationalStatus, Size
如果服务器使用硬件RAID，Windows可能只能看到控制器提供的虚拟磁盘，物理盘健康状态仍应通过对应管理工具确认。
正常与异常怎样区分
验收时不宜只写“正常”，应把判断依据记录下来。
| 验收项目 | 可接受状态 | 需要暂停上线的异常 |
|---|---|---|
| 磁盘与存储拓扑 | 数量、容量、RAID或卷组结构与交付信息一致 | 少盘、容量不符、阵列降级或状态不明 |
| 挂载关系 | 数据、日志写入规划文件系统 | 数据目录实际落在系统盘或临时挂载点 |
| 容量余量 | 能覆盖增长周期、峰值和运维预留 | 仅能容纳初始数据，没有增长空间 |
| inode | 当前使用量合理，增长可预测 | inode接近耗尽或小文件增长无法解释 |
| 磁盘健康 | 控制器、系统日志未显示故障或降级 | 介质错误持续增加、磁盘离线、阵列重建异常 |
| 备份任务 | 有成功记录，备份文件可读取 | 只有任务配置，没有可验证的备份副本 |
| 恢复演练 | 数据完整，权限正确，耗时满足RTO | 无法恢复、恢复后应用不可用或超出RTO |
SMART显示健康并不代表磁盘一定不会故障；它只能作为辅助信号。硬件RAID还应查看控制器事件、缓存保护状态和阵列重建情况。
备份验收必须做到“实际恢复”
备份软件显示任务成功，只能证明任务流程没有报告致命错误，不能证明数据可用。正式上线前至少进行一次隔离恢复：
- 选择有代表性的文件、配置和业务数据，记录备份时间及源路径。
- 对普通文件生成校验值，并保存文件数量、权限和所有者信息。
- 使用正式备份流程执行一次完整备份及后续增量备份。
- 恢复到独立目录、测试实例或隔离环境，禁止直接覆盖生产路径。
- 比较文件校验值，并启动应用执行登录、读取、写入或查询验证。
- 记录从提出恢复请求到业务可用的完整耗时，与RTO比较。
Linux普通文件可使用以下方式生成和核对校验值：
sha256sum /path/to/sample-file
stat /path/to/sample-file
恢复后，在恢复目录对同一文件再次执行命令。如果校验值一致但应用仍不能使用，还要继续检查文件权限、符号链接、配置中的绝对路径以及外部依赖。
数据库不能仅靠复制正在运行的数据目录完成可靠备份。应使用数据库自身支持的一致性备份或快照协同机制，并通过测试实例执行恢复、启动和业务查询。数据库能启动也不等于恢复合格，还应核对关键表、记录时间点及应用连接。
远程备份还要验证传输与凭据
如果香港服务器的备份存放在远程存储，实际恢复速度会受到备份文件规模、并发限制、网络路径和存储端读取能力影响。不要根据标称带宽直接推算RTO，应在与正式环境相同的备份位置、账号权限和恢复流程下计时。
同时确认：
- 备份账号是否与服务器日常管理账号隔离。
- 加密密钥、恢复口令和多因素认证是否有应急保管方式。
- 服务器被入侵或磁盘损坏后，备份副本是否仍可访问。
- 保留策略是否可能让错误数据覆盖全部可用恢复点。
- 备份失败、容量不足和副本过期是否配置告警。
留证、复测与交付确认
建议保存命令输出、控制器状态截图、备份任务编号、恢复日志、校验值和恢复耗时。证据中如包含磁盘序列号、账号、目录结构或业务数据，对外传递前应脱敏。
发现异常后，应在相同数据规模、备份位置、权限和网络条件下复测，避免通过缩小恢复范围得到表面合格的结果。正式确认交付前，再逐项核对：实际磁盘与交付信息一致、容量覆盖预定增长周期、阵列无降级、数据目录挂载正确、备份副本独立可用，并且至少一次恢复演练满足既定RPO与RTO。