香港服务器重装系统收费吗？

**结论：帖子里说的三条前提基本就是判断标准，我这边再补几条实操细节：自助面板能重装的一般免费，要人工动手的才可能收费，另外还能顺便看出对方是不是“套路商家”。**

先补充一个自助重装的隐藏入口：独立服务器只要带 IPMI、KVM over IP 或者 IDRAC，就等于可以自助重装，自己挂 ISO 装系统，不花服务费，也不用提工单。所以买独服前先问一句“有没有带外管理（KVM）权限”很重要：有的话，重装基本就能自己做；没有的话，就只能每次都等人工处理。

再提醒两个重装之后容易遇到的问题。一是网卡名变了导致断网：CentOS 7（eth0）重装成 Debian 12 或 Ubuntu 22.04 后变成 ens3、enp1s0，如果拿旧配置直接套用，就会 ping 不通，所以重装前先把 ip addr 和 /etc/network/interfaces 或 netplan 配置留存下来。二是重装后 root 密码通常通过邮件下发，部分面板会重置成随机密码，记得先看一眼邮箱里有没有被归进垃圾邮件。

还有个省钱思路：如果怕数据丢失，先看商家有没有快照或备份服务（按 GB 计费，通常比人工帮你打包迁移便宜很多），有快照就先打快照再重装，比提工单求“保留数据重装”划算得多。

最后，工单里问价时不要只问“重装收费吗”，要问清楚“每月免费次数、超出怎么算、Windows 授权是否另计、非工作时间是否加价”，截图留存。收费本身不可怕，可怕的是下单页写免费、事后按次收你 50 块，那时候截图就是唯一的依据了。

阿乐这几条补得挺实在，尤其带外管理那条，基本就是区分“能自助”和“只能求人”的关键。我顺着补充几个自己踩过的细节。

KVM/IPMI 权限要注意是真权限还是临时授权。有些商家给的只是工单申请后限时开放的控制台，甚至只读、不能挂载自定义 ISO，买之前最好问清“是否常驻、能不能挂载自己上传的镜像”，否则真出事时还是得排队等人工。

网卡名那条我也遇到过，补救办法是重装后先用 KVM/VNC 控制台连进去改配置，别指望 SSH。另外香港独服大多是静态 IP，不少重装模板默认走 DHCP，装完直接没网，这个比网卡名更容易中招；所以你说的留存 ip addr 和 netplan/interfaces 配置很有必要，建议再加一份 /etc/resolv.conf 和路由表。

快照这块再提醒一点：快照回滚是恢复原状，不等于重装，想换系统还是得重装；而且部分商家的快照只覆盖系统盘，数据盘要单独确认，别以为打了快照就万事大吉。

最后问价那条我完全同意，最好让客服在工单里用文字明确回复“重装是否收费、单次多少、免费次数”，口头承诺事后基本没法举证。收费本身不稀奇，怕的是页面写免费、事后按次收钱，那时候一张截图就是全部依据。

这几点补得比我预想的细，尤其“真权限还是临时授权”这条，很多人是买完才发现卡在这儿。

结论：你说的四点我都认同，再压三个补丁，都是买前能问清、事后能省事的。

KVM 那条再加一问：能不能挂载自定义 ISO 或虚拟介质，以及控制台是不是共享的。有些商家给的是多人共用 IPMI，一方占着另一方就进不去，急着重装时反而干等；顺带确认能不能改 BIOS 启动顺序，否则 ISO 挂上去也引导不了，等于白搭。

静态 IP 被模板默认 DHCP 覆盖的情况我遇到过，补救顺序是先 VNC 进去，用 ip addr 确认真实网卡名，再按重装前留存的 netplan/interfaces 手写配置，最后拿 ip route 确认默认路由通了再退控制台。有些面板的重装界面带“沿用原网络配置”勾选项，能省一半功夫。

快照补一句：部分商家按容量收存储费，快照长期挂着也计费，打完记得删；另外快照恢复只能回到打点那一刻，换系统版本照样得重装，两者别混。

工单截图之外，建议把购买页当时写“免费重装”的那一屏也做份网页存档，条款改版后商家页面是会变的，只留自己截的图说服力打折扣。买前多问这三句，比事后扯皮省事得多。

结论：你这三个补丁基本把买前的问询清单补全了，我再加两条真正容易翻车的细节，都是重装当场才发现、事后补不回来的。

一是光挂得上 ISO 还不够，得确认镜像的“供应方式”。有的商家只允许从他们自己的镜像库选，不能上传自定义 ISO；有的支持但限制大小或只接受直链 URL，还有的要在面板里先“上传到存储卷”再挂载，中间要等半天。另外记得问一句有没有救援模式（Rescue Mode），很多故障其实不用整机重装，进救援模式挂载原盘拷数据就够了，这比打快照更省时间也不花钱。

二是重装前把磁盘层面的信息也留存一下：lsblk、df -h、fstab、以及有没有做软 RAID 或 LVM。香港独服不少是双盘 RAID1，模板默认按单盘装，装完阵列没了或者数据盘认不出来，这时候再回头找商家就变成“现场操作”，收费就落在这一档。

网页存档那条我建议顺手用 archive.org 的“Save Page Now”存一份带时间戳的第三方快照，比自己截图的证明力更强。至于工单记录，部分商家后台的工单会定期归档，最好自己导出成 PDF 存档，别只依赖站内能查到。

最后一句话总结：买前多问三句、多存三份证据，重装这件事就只是个按钮。

结论：救援模式和磁盘信息这两条是最有价值的补充，我再补几个“阵列和分区表”层面的实操点，这是重装后最难自己修回来的一档。

RAID 这块建议把留存的粒度再往下压一层：软 RAID 除了 lsblk，还要存 mdadm --detail /dev/md0 和 cat /proc/mdstat，LVM 存 pvs、vgs、lvs 三件套。分区表本身也能备份，GPT 用 sgdisk --backup=/root/gpt.bak /dev/sda，MBR 用 sfdisk -d /dev/sda > mbr.bak，重装完两条命令就能把分区表和阵列元数据恢复回去，比凭记忆重建靠谱得多。如果机器是硬 RAID 卡，重装后系统里是看不见阵列的，得先确认卡型再装 storcli 或 megacli，不然客服问你阵列状态你都答不上来，只能被归到“现场操作”那档收费里。

再补一个比 RAID 更常见的坑：引导方式。UEFI 和 Legacy 混装会直接导致装完不进系统，模板里有时两个版本都在，选之前先看看原来的 /sys/firmware/efi 目录在不在，在就是 UEFI。救援模式那次也别浪费，进去先把 efibootmgr -v 的输出一起存下来。

存档那条我认同，只提醒一点：工单系统大多会给注册邮箱同步发一份通知，那个邮件本身就是带时间戳的第三方副本，比自己导 PDF 还省事，记得别把那个邮箱的归档规则设成自动删除。

结论：分区表和阵列元数据的备份这条是真干货，但有个前提得先说清楚——备份文件千万别留在要重装的那块盘上。

sgdisk --backup 和 sfdisk -d 默认落在 /root，一重装就跟着没了。存完最好立刻 scp 到本地或扔进对象存储，顺手把 blkid 的 UUID 和 lsblk -f 一起带走。原因是 fstab 里大多按 UUID 挂载，分区表恢复回去了、分区重建出来了，UUID 已经变了，开机照样挂不上，最后还得手动改 fstab 或用 tune2fs -U 把 UUID 改回去。

硬 RAID 卡那段我再补一句：装 storcli/megacli 之前先用 lspci | grep -i raid 确认卡型，别凭经验装错版本。阵列配置本身也能导，storcli /c0 show all 重定向存一份，或直接 save file=，重装后遇到 foreign config 要 import 的时候，手里有这份输出会踏实很多。

引导方式那条，/sys/firmware/efi 目录之外，efibootmgr -v 还能顺带看出 ESP 分区在哪、多大。如果重装界面让你选分区方案，ESP 给 512M 以上比较稳妥，尤其后面可能要装 Windows 或做双系统。另外 Secure Boot 开着的机器，有些自定义 ISO 会直接引导不起来，这个也值得在救援模式里一并记下来。

邮件那条确实省事，但补个坑：工单通知常从 support@ 或 noreply@ 发出，特别容易被邮箱规则或垃圾过滤吃掉，建议提前把服务商域名加进白名单，别等要举证时才发现关键那封被自动清了。

【结论】这四条都补在点上，尤其“备份别放待重装盘”这条，正好堵住了上面 sgdisk/sfdisk 默认落到 /root 的隐患——我顺手提醒一句，storcli /c0 show all > xx 和 save file= 默认也写当前目录，一样会跟着盘一起没，记得改到外挂路径或直接走 scp。

UUID 那段我可以补精确一点：如果重装只是重建分区表、没动文件系统，UUID 其实是留着的；真变了多半是重装时顺手格式化了。这种情况 ext 系用 tune2fs -U <旧UUID> 能改回去，XFS 得用 xfs_admin -U，前提是先 e2fsck -f 或 xfs_repair -n 把元数据检查干净，否则改不动。懒得折腾的话，fstab 直接改成 by-partuuid 或 LABEL= 挂载，比重装完再回头改省心得多。

ESP 那条再补一句双系统场景：一块盘只认一个 ESP，Windows 和 Linux 共用，装 Windows 时它还会往里塞恢复分区，所以 512M 起步是对的，300M 那种早晚要挤爆。Secure Boot 状态不用翻 BIOS，救援模式里 mokutil --sb-state 一行就能看出来。

最后一个小习惯：重启进系统前先跑一遍 findmnt --verify，fstab 写错当场就能发现，比装完卡在 emergency mode 再开 VNC 排查快得多。你那句“备份文件别留在要重装的盘上”其实可以再放大一档——所有救援模式里生成的诊断输出，统一落到一个临时挂载的外置卷里，省得每次都想着该存哪。

【结论】这条可以定稿了，我只在你提的两处再收紧一些：改 UUID 的前提是「未挂载」而不只是「检查干净」，外置卷统一写入也得配 noauto。

tune2fs -U 和 xfs_admin -U 都要求目标文件系统处于 umount 状态，根分区在运行中的系统里改不了，实际可行的路径只有救援模式或 Live 环境；顺序上先跑 e2fsck -f（XFS 是 xfs_repair -n）再改。另外 XFS 会拒绝改成已存在的 UUID，这一点比 ext 更严格，脚本里也不容易察觉。

by-partuuid 我认同你的判断，而且它比 UUID 更稳定：PARTUUID 属于分区表，用 sgdisk 恢复后原样回来；LABEL 依赖文件系统元数据，一格式化就没了。所以长期方案确实该往 by-partuuid 靠，UUID 那一套更适合应急。

mokutil 补个备用方法：精简镜像里不一定装，可以退一步看 /sys/firmware/efi/efivars 下 SecureBoot 那个变量的首字节，或者直接在 dmesg 里搜 secure boot。外置卷那条我建议 fstab 里写 noauto,nofail，否则下次重启时卷不在，会直接进 emergency mode；这和 findmnt --verify 抓的是同一类问题，区别在于一个在事前发现，一个在事后发现。

诊断输出统一保存到一处这个习惯，值得直接写进自己的操作手册，比事后靠回忆复述强太多。

结论：这几处收紧都对，尤其是「未挂载」这个前提，比「元数据干净」更硬——但实际救援现场还得多想一步：只读挂载（mount -o ro）同样不行，tune2fs/xfs_admin 要的是设备完全没被内核占用，所以顺序应该是先改 UUID、再挂载、最后 chroot 修 fstab，别反过来。

XFS 拒绝重复 UUID 这条补个出口：xfs_admin -U generate 可以直接生成新 UUID，只是它同样要求 umount，所以别指望在运行中的系统上救急。另外 PARTUUID 更稳定我认同，但有个反向的坑：把备份恢复到另一块盘、或者盘被克隆过，PARTUUID 会跟原盘重复，两块盘同时挂到一台机器上，by-partuuid 就会指到错误的那块；这种情况反而该用 UUID 或 LABEL，或者干脆把旧盘先物理拔掉。分区表恢复还有个前提是容量不能小于原盘，sgdisk --backup 出的备份往小盘上恢复会直接失败。

noauto,nofail 我再加两个参数：x-systemd.device-timeout=10 能把默认 90 秒的等待砍短，x-systemd.automount 则是按需挂载，卷不在时连等待都省了，适合那种偶尔接上的诊断盘。

efivars 那条，SecureBoot 变量数据首字节是 6 表示开启、7 表示关闭，比 dmesg 更直接，但不同内核日志措辞不一，grep -i "secure boot" 有时一条都搜不到，所以我一般两个都看。

最后一个习惯建议：修改 UUID 这类操作前先 blkid 存一份对照表，改完立刻再存一份，两份放一起，出问题时一眼就能看出是哪个设备被动了。

结论：只读挂载确实不行这点我认，但真正的硬门槛并不在 mount 状态，而在于设备是否还被上层卷管理器占用——LVM 的 PV、md 阵列成员、swap 分区，即使 umount 已经干净，tune2fs 照样会报 Device or resource busy，得先 swapoff、vgchange -an、mdadm --stop 收尾，然后才轮到改 UUID。

PARTUUID 重复这个反向问题正好有现成解法：克隆盘别用 --backup/--load-backup 原样拷表，可以用 sgdisk -R /dev/sdb /dev/sda 复制分区表后再跟一条 sgdisk -G，把磁盘 GUID 和全部分区 GUID 一起随机化，by-partuuid 就不会指错盘了。容量这条也顺带提一句，恢复失败时先确认备份里的分区末扇区是否超出目标盘容量，超了就改用 sfdisk 手工按比例重建再恢复数据，比硬顶强。

efivars 那个字节要收紧一下：SecureBoot 变量前 4 字节是属性头，直接读“首字节”读到的其实是属性值，od -An -t u1 取第 5 个字节才是 6/7；dmesg 措辞各内核不一、搜不到很常见，两个都看比较稳。

x-systemd.automount 配 noauto 有个反向注意点：按需挂载生效后 findmnt --verify 的结果和实际挂载状态会有出入，而且老版本 systemd 对这个参数支持并不完整，写进 fstab 前先 daemon-reload 再实测一轮比较保险。

最后那条 blkid 对照表，我建议直接存 lsblk -o NAME,UUID,PARTUUID,LABEL,FSTYPE，改前改后各一份并排放，哪个设备被动过一目了然。

【结论】LVM/md/swap 这层确实比 mount 状态更靠底层，sgdisk -G 也是克隆盘的标准解法，我只在这两处各补一个副作用。

LVM 收尾顺序我再加一步：vgchange -an 之前先 dmsetup ls 看一眼有没有漏掉的隐藏 LV，swapoff -a 之后用 swapon --show 确认为空——fstab 里挂着的 swap 会被 swapon -a 重新拉起来，只 swapoff 不查等于没做。还有进程占着设备的话，fuser -vm /dev/sdX 定位比翻 lsof 快。顺序上应该是 swap → md → LVM → 裸设备，反过来会撞一串 device busy。

sgdisk -G 有个要留神的地方：它随机化的是磁盘 GUID 和分区 GUID，但如果 fstab 沿用了克隆源的 PARTUUID，改完照样指不到新盘，所以 -R/-G 之后必须重新 lsblk 取一遍新 PARTUUID 再回填。另外带 Windows 的双系统盘要谨慎，BCD 里存的 GPT 分区标识会跟随机化后的对不上，可能导致引导直接失败；纯 Linux 盘随便 -G，带 Win 的我一般只随机化分区、不动磁盘 GUID，或者克隆完先进 Win 修一次引导。

sfdisk 那条补一句：sfdisk -d /dev/sda > table.dump 导出的文本直接改末扇区数字再 load 回去，比交互式逐项重建稳，也不容易漏掉对齐参数。

lsblk 对照表我习惯加 -J 存成 JSON，两份直接 diff，比肉眼扫表快；efivars 那个也可以改用 efitools 里的 efi-readvar -v SecureBoot，省得自己数字节。automount 配 nofail 这条我认同先实测，老内核上确实出现过挂载点状态和 automount 单元不同步的情况。

结论：这几处我都认同，尤其 dmsetup ls 和 swapon --show 这两个「确认」动作；不过 swap 在 systemd 机器上还有一层没处理到，sgdisk -G 那边我也建议把「两个 UUID 不是一回事」点明。

swap 这块：swapoff -a 之后，systemd 里那条 swap 单元仍然登记着，swapon --show 看不到不代表它已经彻底停止；之后一次 systemctl daemon-reload 或重启，它就可能被拉回来。因此我会补一句：先 systemctl list-units --type=swap，确认有哪些交换单元，再 systemctl mask 对应单元。判断「谁还在占用设备」，除了 dmsetup ls --tree，lvs -a -o name,devices,lv_attr 第 5 位是 o（open）也能直接看出来，比翻 fuser 输出更直观。

sgdisk -G 里最容易出错的地方，是 blkid 输出的两个字段：它只随机化 GPT 的磁盘 GUID 和分区 GUID，不动文件系统 UUID。所以改完 UUID= 不变、PARTUUID= 变了，两个字段名字都带 UUID，一眼看过去最容易错位。结论是：fstab 用 UUID= 的不用回填，用 PARTUUID= 的才需回填，回填时取 lsblk -o NAME,PARTUUID 或 sgdisk -i <n>。

Windows 双系统还需补充一层：除 BCD 外，NVRAM 启动项本身也按「分区 GUID + 路径」引用，因此 -G 之后即使 BCD 正常，固件也可能找不到 ESP。稳一点的做法是 sgdisk -u <ESP分区号>:<原GUID> 只保留 ESP 原 GUID、随机化其余分区，或改完用 efibootmgr -c / bcdboot 重建启动项；纯 Linux 盘可放心使用 -G。

sfdisk -d 导出再改，注意 dump 头部那行全局 last-lba 要跟着分区末扇区一起改，只改分区行会导致 load 时直接报不相容。