业务迁移到香港云服务器前，额外数据盘如何评估数据规模、停机窗口与回退条件？

先判断：能挂载，但不能把“额外数据盘”当成自动扩容

香港云服务器可以挂载额外数据盘吗？通常可以，但最终要以所选云服务器实例、控制台和当前存储产品支持的挂载规则为准。额外数据盘一般是独立的块存储：创建并附加到云服务器后，还需要在操作系统中识别设备、格式化或使用已有文件系统、挂载目录，最后再让应用读取该目录。

迁移前不要只看“原服务器磁盘用了多少空间”。至少要同时确认以下条件：

在没有业务数据实测结果时，不应直接承诺某个数据盘可以承载多少数据。较稳妥的最小方案是：准备一台目标香港云服务器，附加一块容量经过测算的空白数据盘，先在线完成初次复制，停写后再完成最终同步，验证通过后切换业务，并暂时保留原服务器作为回退对象。

先按实际占用量评估数据规模

1. 区分已分配空间、实际数据和迁移临时空间

系统盘显示的分区容量不等于业务数据量。评估时应重点关注：

• 业务文件实际占用空间；
• 数据库数据文件、日志文件和归档文件；
• 应用上传目录、静态文件和用户附件；
• 隐藏文件、软链接、硬链接、ACL 和扩展属性；
• 小文件数量以及 inode 使用情况；
• 初次同步期间新增的数据；
• 压缩、解压、索引重建或日志切换产生的临时空间；
• 是否需要在目标盘上保存临时备份。

在源服务器上可以先执行以下检查。下面命令以常见 Linux 环境为例，/SOURCE_DATA 需要替换为实际业务目录。

df -hT /SOURCE_DATA
df -ih /SOURCE_DATA
sudo du -xsh /SOURCE_DATA
sudo du -xhd1 /SOURCE_DATA | sort -h
sudo find /SOURCE_DATA -xdev -type f | wc -l

df -hT 用于查看文件系统整体使用量和文件系统类型，df -ih 用于查看 inode 使用情况，du 更接近目录实际占用量。若业务包含稀疏文件，还应分别查看逻辑大小和实际占用量：

sudo du -sxh /SOURCE_DATA
sudo du --apparent-size -sxh /SOURCE_DATA

两者差异较大时，复制工具和目标文件系统需要支持稀疏文件，否则迁移后实际占用可能明显增加。

2. 使用可解释的容量公式

可以将目标数据盘的最低容量按以下方式估算：

目标盘所需容量 = 当前实际数据量 + 迁移期间增长量 + 临时空间 + 预留空间

其中：

• 当前实际数据量：以 du、数据库统计或应用存储统计为准；
• 迁移期间增长量：从开始初次同步到最终切换期间产生的数据；
• 临时空间：压缩包、解压目录、索引、日志切换等所需空间；
• 预留空间：根据业务增长、文件碎片和维护操作确定，不应直接套用一个固定百分比。

如果备份文件也放在同一块数据盘上，还要将备份占用计入容量。若备份存放在独立的备份位置，则不能把“已经有备份”当成数据盘容量的替代品，仍需保证业务数据本身能够正常运行。

3. 不要忽略 inode 和目录结构

大量小文件可能在容量尚未用尽时先耗尽 inode，表现为无法创建新文件、上传失败或日志写入异常。因此，数据规模评估至少要同时记录：

• 已用容量和剩余容量；
• inode 已用量和剩余量；
• 文件总数；
• 最大目录和最大单文件；
• 是否存在大量临时文件、缓存文件或可排除目录。

缓存、构建产物和可重新生成的临时文件可以不迁移，但必须先确认应用不会把它们误当作业务数据。排除目录后，要在目标服务器上验证应用仍能正常启动。

用同步实测结果反推停机窗口

停机时间不是初次复制所有数据所需的时间。采用“先在线复制、再停写补差量”的方式时，停机窗口主要由下面几部分组成：

停机窗口 = 应用停写时间 + 最终差量同步时间 + 服务切换时间 + 验证时间 + 回退缓冲时间

初次同步可以在业务运行时完成，最终同步则必须在所有写入动作停止后进行。规划时应分别测量：

可以在不改变数据的情况下进行差量预演。以下命令中的源地址、目录和账号需要按实际环境替换：

sudo rsync -aHAXS --numeric-ids --dry-run --stats \
  -e ssh SOURCE_USER@SOURCE_HOST:/SOURCE_DATA/ /TARGET_DATA/

--dry-run 只模拟，不会复制或删除文件；--stats 可以帮助观察文件数量和差量规模。它不能直接代表真实传输耗时，因此正式初次同步仍应记录实际用时和目标端写入情况。

如果最终差量持续增长，或者每次同步还没有完成，新的写入量已经超过了已同步的数据量，说明单纯增加数据盘容量不能解决停机问题。此时需要降低迁移期间的写入量、延长同步阶段，或针对数据库采用原生备份恢复、复制或其他具备一致性保证的迁移方式。

迁移前必须核对兼容性

文件系统和挂载路径

目标数据盘不能只看容量，还要确认：

• 目标操作系统是否支持计划使用的文件系统；
• 应用是否依赖大小写敏感、ACL、扩展属性或特定挂载参数；
• 源目录是否包含软链接、硬链接或稀疏文件；
• 应用是否要求固定路径，例如 /var/lib/应用名；
• 目标挂载点是否为空，避免挂载后遮蔽原有目录内容。

如果应用原来使用固定目录，优先让数据盘挂载到相同路径，可以减少配置改动。但在执行挂载前，必须确认目标挂载点没有需要保留的文件。将数据盘直接挂到非空目录上，会让该目录原有内容暂时不可见，不能把这种现象误认为数据已经迁移。

用户、用户组和权限

迁移后应用进程使用的 UID、GID、目录权限和 ACL 必须一致。rsync 保留权限并不代表目标系统一定存在同名用户；如果用户编号不同，应用可能出现“文件存在但无权访问”的情况。

需要核对：

id APP_USER
namei -l /TARGET_DATA
sudo getfacl -p /TARGET_DATA

如果业务依赖扩展属性或 ACL，复制时应保留对应信息，并在目标端抽样检查。容器或独立服务使用固定 UID 时，也应将该 UID/GID 纳入迁移记录。

数据库一致性

不要把正在运行的数据库数据目录当作普通文件夹直接复制。数据库可能仍在写入数据页、日志或临时文件，文件级复制完成也不代表这些文件处于可恢复状态。

数据库迁移应优先采用其原生备份恢复、复制或停机冷备方案。额外数据盘可以作为目标数据存储，但不能替代数据库自身的一致性机制。对于“应用文件加数据库”混合目录，应将静态文件和数据库文件拆开评估，分别安排同步和验证。

最小可用迁移步骤

第一步：记录源环境并准备回退

迁移前记录以下信息：

• 源服务器业务数据目录；
• 应用服务名称和启动方式；
• 数据库连接及数据目录；
• 当前挂载点、文件系统类型和容量；
• 应用运行用户、用户组及权限；
• 当前备份是否可恢复；
• 发生异常时如何切回源服务器。

源服务器不要在目标验收前释放、重装或删除数据。回退依赖的是一份未被目标操作影响的源数据，而不是迁移日志。

第二步：确认额外数据盘能力并附加空白磁盘

在控制台或服务支持渠道确认：

• 当前香港云服务器实例是否支持附加数据盘；
• 数据盘支持的容量范围和挂载数量；
• 数据盘能否在目标实例上保持持久化；
• 是否支持目标操作系统；
• 数据盘、快照和备份的计费规则；
• 解绑、重新挂载和故障处理流程。

附加完成后，在 Linux 服务器中识别新设备：

lsblk -o NAME,SIZE,FSTYPE,UUID,MOUNTPOINTS
sudo blkid

不要根据设备名猜测哪一块是新盘。云服务器中的设备名可能因实例和系统环境不同而变化，应通过容量、文件系统、UUID 和控制台操作时间共同确认。

第三步：格式化并挂载数据盘

以下示例假设已经确认 /dev/DEVICE 是新建且没有需要保留数据的空白磁盘，并计划使用 ext4。mkfs 会破坏该设备上的原有数据，只有在完成备份、确认设备无误且明确允许清空时才能执行。

sudo mkfs.ext4 /dev/DEVICE
sudo mkdir -p /data
sudo mount /dev/DEVICE /data
sudo chown APP_USER:APP_GROUP /data

如果业务要求使用其他文件系统，应以应用和操作系统兼容性为准，不要机械套用 ext4。挂载成功后记录 UUID：

sudo blkid /dev/DEVICE
findmnt /data
df -hT /data

将 UUID 写入 /etc/fstab，比直接使用 /dev/vdX 更适合长期挂载：

UUID=实际UUID /data ext4 defaults 0 2

保存后执行：

sudo mount -a
findmnt /data

如果挂载失败，不要直接启动应用。先检查 UUID、文件系统类型、目录权限和系统日志。对关键业务目录谨慎使用 nofail，因为它可能让系统在数据盘未挂载时继续启动，应用随后把数据写入系统盘上的空目录，造成数据位置错误。

第四步：先完成初次同步

确认目标目录已经正确挂载后，再执行初次复制。示例使用 rsync 保留常见的权限、时间、硬链接、ACL、扩展属性和稀疏文件：

sudo rsync -aHAXS --numeric-ids --info=progress2 \
  -e ssh SOURCE_USER@SOURCE_HOST:/SOURCE_DATA/ /data/

初次同步完成后，检查文件数量、目录大小、权限和异常日志。不要在第一次同步时随意加入 --delete，因为该选项可能删除目标端文件。目标目录应尽量保持为空或仅包含明确确认过的内容。

第五步：停写并完成最终同步

进入维护窗口前，先确认所有会写入该目录的应用、后台任务和数据库任务。服务名称不能凭空猜测，可先查看：

systemctl list-units --type=service

停止写入服务后再执行最终同步：

sudo systemctl stop APP_SERVICE

sudo rsync -aHAXS --numeric-ids --info=progress2 \
  -e ssh SOURCE_USER@SOURCE_HOST:/SOURCE_DATA/ /data/

如果包含数据库数据目录，应按照数据库自身的停机或备份流程执行，而不是只依赖上面的文件复制命令。最终同步期间，应确认源目录没有继续发生写入，否则同步完成后仍可能缺少最新数据。

第六步：配置应用并启动目标服务

如果目标数据盘挂载路径与原环境一致，通常可以减少应用配置改动；如果路径不同，则应修改应用配置，并检查配置文件中的权限和连接地址。

启动前先验证目录：

findmnt /data
df -hT /data
sudo -u APP_USER test -r /data
sudo -u APP_USER test -w /data

确认通过后启动服务：

sudo systemctl start APP_SERVICE
sudo systemctl status APP_SERVICE --no-pager

不要只看服务进程是否存在，还要检查应用日志、数据库连接、关键目录读取和实际业务写入。

验收标准和失败处理

迁移成功至少应满足以下条件：

可使用无写入的差异检查辅助核对：

sudo rsync -aHAXS --numeric-ids --dry-run --itemize-changes \
  -e ssh SOURCE_USER@SOURCE_HOST:/SOURCE_DATA/ /data/

该命令只能作为文件层面的检查，不能替代数据库一致性校验和业务验收。对于关键文件，可以结合应用自身校验、文件哈希或数据库校验结果进行确认。

测试应用写入时，应只使用明确的测试文件，并记录删除范围。不要使用通配符清理目录：

sudo -u APP_USER sh -c 'touch /data/.migration_write_test && rm -f /data/.migration_write_test'

这条命令只针对指定测试文件；如果应用用户无权写入，说明权限或挂载配置仍未完成，不应继续扩大迁移范围。

回退条件必须在切换前写清楚

以下情况应触发回退评估：

• 数据盘无法稳定挂载，或重启后挂载丢失；
• 应用启动失败，且短时间内无法定位；
• 应用用户无法访问部分关键数据；
• 数据库无法通过自身一致性检查；
• 关键业务读取或写入失败；
• 最终差量同步未完成，或源目录在同步后仍持续写入；
• 目标盘容量、inode 或实际写入能力无法满足业务；
• 目标端已经产生异常数据，无法确认其与源端一致。

建议按以下顺序执行回退：

1. 停止目标服务器上的应用写入，避免回退期间继续产生新数据。
2. 记录目标端在切换后产生的新数据。若目标端已经接受过用户写入，不能直接把源服务器切回并忽略这些数据，应先导出、合并或按业务规则处理。
3. 将业务入口切回源服务器，恢复源端应用和数据库服务。
4. 使用源端进行读取、写入和关键业务验证。
5. 保留目标数据盘、日志和迁移记录，不要立即格式化或删除，便于分析原因和再次迁移。

回退并不等于自动恢复数据。如果切换后源端和目标端都发生过写入，就已经出现数据分叉，必须先确定以哪一端为准，并评估可能的数据丢失范围。

哪些情况说明最小方案已经不够

额外数据盘适合解决“目标服务器缺少持久化数据空间”这一类问题，但它不能自动解决所有迁移瓶颈。出现以下表现时，应考虑升级迁移方案：

• 数据增长速度接近或超过实际同步速度；
• 最终差量大到无法放入计划停机窗口；
• 大量小文件导致 inode 快速耗尽；
• 数据库写入频繁，文件级复制无法保证一致性；
• 日志、缓存和业务数据相互争用同一块盘；
• 应用对存储性能或并发访问有更高要求；
• 回退时无法清晰处理切换后新增数据。

如果只是容量不足，可以优先增加数据盘容量；如果是同步时间过长，应先优化同步流程或降低停机期间的差量；如果是数据库一致性问题，则应采用数据库原生迁移机制。最终判断标准不是“能否挂载一块盘”，而是目标数据盘能否在容量、兼容性、停机窗口、业务验证和回退条件上同时满足要求。