外观
抢救 /etc/pve 与重建节点
/etc/pve 看起来是个普通目录，其实是 pmxcfs——一个由 SQLite 数据库支撑、通过 FUSE 挂载出来的文件系统。虚拟机和容器的定义、存储配置、用户权限，全部存在这里。这篇讲清楚 pmxcfs 数据库在哪、官方文档给出的恢复方法覆盖哪些场景，以及配置彻底丢失但磁盘数据还在时怎么重建。
为什么需要它
/etc/pve 和虚拟机/容器的磁盘数据是两个独立的东西：前者是"这台机器上有哪些虚拟机、配了什么硬件、连了哪个存储"的元数据，后者是实际的磁盘内容，通常放在单独的存储（ZFS 池、LVM、NAS）上。宿主机系统损坏时，磁盘数据可能完好无损，但如果没有 /etc/pve 的备份，你会失去"这些磁盘属于哪台虚拟机、该用什么硬件配置启动"的信息——数据还在，但不知道怎么把它们重新组织成能开机的虚拟机。
先分清楚丢的是配置还是数据
zpool status、lsblk、存储管理界面能看到虚拟机磁盘文件/卷本身还在，说明数据没丢，丢的只是 /etc/pve 里的配置——这种情况可以按本文重建，不涉及数据恢复。如果磁盘本身也损坏或丢失，那是另一个问题，属于备份与恢复的范围，本文帮不上忙。
开始之前
pmxcfs的数据库文件在/var/lib/pve-cluster/config.db，只在本地磁盘上，不在虚拟机存储里。这意味着重装宿主机系统盘（即便虚拟机磁盘在独立的盘上完好无损）也会连带丢掉它，除非你单独备份过。- 本文的恢复步骤以官方《Proxmox VE Administration Guide》pmxcfs 章节的 Recovery 一节为准，只介绍该节明确写出的方法：把
config.db搬到新宿主机。集群环境下把某台失效节点的客户机配置转移给其他在线节点，也是官方文档里的场景，但依赖集群仍有法定人数(quorum)，单机环境不适用，这里不展开。 - 官方文档没有给出"
config.db本身损坏、且没有任何备份副本"时的数据库级修复步骤。遇到这种情况，不要在生产数据库文件上尝试未经验证的 SQLite 修复操作；本文最后给出一条不依赖config.db的重建路径。 - 需要 root 权限，以及能同时接触到问题宿主机（或它的磁盘）和目标宿主机。
这篇涉及的操作会整体替换 /etc/pve 的内容
替换 config.db、或者用新建配置覆盖已有配置，都会影响目标节点上全部虚拟机/容器/存储/用户的定义，不是针对单台虚拟机的操作。
影响范围：目标宿主机原有的 /etc/pve 内容会被覆盖。 前置条件：目标宿主机上没有你还需要的虚拟机/容器/存储配置（全新装好的机器，或者你已经确认可以放弃它现有的配置）。 回退方式：操作前用 cp -a /var/lib/pve-cluster/config.db /root/config.db.bak-$(date +%F) 先备份目标宿主机现有的数据库文件。发现替换错了，pve-cluster 停止后把备份文件换回去，再重启服务即可回退。
操作步骤
场景一：宿主机硬件报废，把配置搬到新宿主机
这是官方文档明确写出的完整流程，适用于"旧机器硬件坏了，数据要转移到一台新装好的 Proxmox VE 机器上"。
在旧宿主机（如果还能开机，哪怕只是临时的）上取出数据库文件：
sh
# 旧宿主机 shell,或者救援模式下挂载了旧系统盘之后
cp /var/lib/pve-cluster/config.db /path/to/外部介质/config.db在新宿主机（全新安装、还没有配置任何虚拟机）上：
sh
# 新宿主机 shell
systemctl stop pve-cluster
cp /path/to/外部介质/config.db /var/lib/pve-cluster/config.db
chmod 0600 /var/lib/pve-cluster/config.db然后修改 /etc/hostname 和 /etc/hosts，把主机名改成和旧节点一致（pmxcfs 里的很多路径按节点名组织，主机名对不上会导致虚拟机配置文件"挂"在一个找不到的节点名下面），改完重启：
sh
reboot重启后检查虚拟机/容器列表是否已经出现（见下文「检查结果」）。虚拟机磁盘本身不在这个数据库里，如果磁盘在独立存储上且存储配置(storage.cfg，也包含在 config.db 里)正确指向同样的路径/池，磁盘会被正常识别；如果存储介质也换了，还需要按新的路径调整 storage.cfg 或重新添加存储。
场景二：集群里一台节点失效，把它的客户机转移给在线节点
官方文档给出的另一种场景：集群里某节点确认已经关机或被隔离(fenced)，它名下只用共享存储、没有其他仅在该节点可用资源的非 HA 客户机，可以手动把配置文件搬到别的在线节点：
sh
# 在集群里任意一台在线且有法定人数的节点上执行
mv /etc/pve/nodes/<失效节点名>/qemu-server/<vmid>.conf /etc/pve/nodes/<在线节点名>/qemu-server/必须先确认失效节点真的已经关机
如果失效节点其实还在运行（只是网络分区，和集群其他部分失联），这条 mv 会破坏 pmxcfs 的锁机制假设，导致同一台虚拟机在两个节点上同时被启动，继而造成磁盘数据损坏。官方文档特别强调这一点。确认的方法包括物理断电确认、IPMI 确认关机状态，而不是仅凭"ping 不通"下结论。
单机环境没有这个场景，只有多节点集群才用得上，列在这里是为了和场景一（单机/整机迁移）区分开，避免混用。
场景三：config.db 损坏且没有备份，只能靠磁盘上的数据重建
如果 /etc/pve 彻底进不去、也没有 config.db 的备份副本，但虚拟机/容器的磁盘文件本身还在存储上，可以用官方文档化的 rescan 机制把它们重新"接"回配置里，而不是尝试修复数据库本身：
确认存储还在、还能被 PVE 识别：
数据中心 → 存储，或者pvesm status。存储配置(storage.cfg)如果也随/etc/pve一起丢了，要先按原来的类型和路径重新添加一遍。对每一个要找回的虚拟机，在 Web UI 里用同样的 VMID 新建一台最小配置的虚拟机（不加磁盘，机型、BIOS 等先随便填，后面会核对调整）。VMID 必须和原来的完全一致，
rescan是按 VMID 关联磁盘文件命名规则(vm-<vmid>-disk-*)找回归属的。宿主机 shell 里先干跑一次，确认能找到哪些磁盘：
shqm rescan --vmid <vmid> --dryrun输出会列出类似
VM <vmid> add unreferenced volume '<storage>:<vmid>/vm-<vmid>-disk-0.qcow2' as 'unused0' to config的内容，确认这是你期望的磁盘。确认无误后正式执行：
shqm rescan --vmid <vmid>磁盘会被加入这台虚拟机的 Hardware 列表，标记为 Unused Disk。
回到 Web UI，虚拟机 → Hardware，把找回的 Unused Disk 双击，选择挂载为磁盘（需要手动确认总线类型，原来是 SCSI 就选 SCSI），再按记忆或历史文档补上网络、CPU、内存等其他配置。
容器用
pct rescan --vmid <ctid>，流程相同。
这条路径找不回原来的硬件配置细节
rescan 只能重新关联磁盘文件，找不回原来的 CPU 类型、内存大小、网卡型号、启动顺序这些配置项，这些需要你凭记忆、监控历史数据或者其他文档手动重新填写。这也是为什么强烈建议平时就单独备份 /etc/pve(或者至少导出关键虚拟机的 qm config <vmid> 输出留档)。
检查结果
sh
# 宿主机 shell
systemctl status pve-cluster # active (running)
pvecm status # 单机也应正常输出
qm list # 虚拟机应重新出现
pct list # 容器应重新出现
qm config <vmid> # 核对硬件配置是否符合预期对每一台找回的虚拟机，实际开机验证一次：能正常启动、磁盘里的数据可读、网络配置正确，才算真正恢复，而不是只看列表里有名字。
常见问题
pve-cluster 服务启动失败，日志提示数据库相关错误。 先用 journalctl -u pve-cluster -n 100 看具体报错。如果有近期的 config.db 备份，直接按场景一的步骤"搬回"当前机器本身（路径相同，不需要换宿主机）通常比排查数据库内部问题更快。
改了 /etc/hostname 之后虚拟机配置还是找不到。 检查 /etc/pve/nodes/ 下的目录名和新的主机名是否一致，不一致的话虚拟机配置文件"挂"在旧节点名的目录下，Web UI 按当前节点名找不到它们，需要把目录内容移到匹配当前主机名的目录下。
qm rescan 没有找到任何磁盘。 确认存储确实是 active 状态(pvesm status)，以及磁盘文件命名符合 vm-<vmid>-disk-* 的约定——用第三方工具重命名过的磁盘文件，rescan 认不出来，需要先手动改回标准命名。
磁盘本身也已经损坏或找不到了。 这不是配置问题，本文帮不上忙，回到恢复演练里的备份路径。