备份宿主机配置

配置备份任务与保留策略 的最后提到过：vzdump 备份的是客户机，宿主机自己的配置不在任何客户机备份里。这篇把这件事展开讲清楚：/etc/pve 里到底有什么、为什么"集群里有好几份"不等于"有备份"，以及具体怎么把这些东西也存好。

开始之前

• 已经按 配置备份任务与保留策略 把客户机备份配好。
• 理解"冗余不是备份"这条本站反复强调的原则——这篇要讲的正是它在配置层面的具体体现。

/etc/pve 里有什么，为什么"多份拷贝"不算备份

/etc/pve 不是普通目录，它是 pmxcfs（Proxmox 集群文件系统）挂载出来的一个数据库驱动的文件系统。单节点时它也在跑，只是没有别的节点可同步；集群模式下，corosync 会把这里的改动实时同步到每一个节点。底层数据实际存在 /var/lib/pve-cluster/config.db 这个 SQLite 文件里，同时常驻内存，因此总大小有 128 MiB 的上限——对绝大多数环境够用。

/etc/pve 下大致包含：

路径	内容
storage.cfg、user.cfg、domains.cfg、datacenter.cfg	存储定义、用户与角色、认证域、数据中心全局设置
firewall/	集群级和每台客户机的防火墙规则
ha/	高可用的资源、规则、状态
nodes/<节点名>/qemu-server/*.conf、nodes/<节点名>/lxc/*.conf	每台虚拟机、容器的配置文件
nodes/<节点名>/ 下的证书	该节点的 Web UI 证书和私钥
priv/（仅 root 可读）	集群 CA 私钥、authkey.key、用户密码影子文件、双因素配置、API Token、各节点 SSH 密钥、Ceph 密钥、存储密码明文等

集群同步的是"错误"，不是"历史版本"

错误的改动、误删除会实时同步到集群里的每一个节点。多节点意味着你手上有很多份"一模一样的错误"，而不是很多份可以回退的历史版本。这就是冗余不是备份在配置层面的具体体现——你需要的是某个时间点的独立快照，而不是"别的节点上也有一份"。

哪些东西不在 /etc/pve 里，需要单独备份

/etc/pve 只管 PVE 认识的这部分配置，操作系统层面的东西要自己留意：

• /etc/network/interfaces：网卡、网桥、Bond、VLAN 的定义。
• /etc/hosts、/etc/hostname、/etc/resolv.conf：主机名与 DNS。
• /etc/apt/sources.list.d/：软件源配置，尤其是你按 配置软件源 调整过的部分。
• /etc/ssh/：SSH 主机密钥（丢了会导致客户端提示"主机密钥变了"）；/root/.ssh/：你自己的密钥和 authorized_keys。
• root 的 crontab、systemd timer 里自定义的任务。
• ZFS 池、LVM 卷组的布局（zpool status、vgs/lvs 的输出）——这不是能直接"恢复"的备份，但灾难发生后，知道原来的池是几块盘做的什么级别，能省下大量猜测时间。

备份方法：归档 + 异地存放

在宿主机上定期打包，存到已经准备好的备份存储（和客户机备份用同一个目标，或者更保守地另外存一份）：

# 宿主机 shell
mkdir -p /mnt/backup/host-config
tar czf /mnt/backup/host-config/pve-etc-$(date +%F).tar.gz \
  /etc/pve /etc/network/interfaces /etc/hosts /etc/resolv.conf \
  /etc/hostname /etc/apt/sources.list.d/ /etc/ssh /root/.ssh

# 顺带把当前的存储布局记录下来，方便灾难后核对（这不是可还原的备份，只是文档）
zpool status > /mnt/backup/host-config/zpool-status-$(date +%F).txt 2>/dev/null
vgs > /mnt/backup/host-config/lvm-vgs-$(date +%F).txt 2>/dev/null
crontab -l -u root > /mnt/backup/host-config/root-crontab-$(date +%F).txt 2>/dev/null

把它写成一个每天或每次改动后触发的 systemd timer / cron 任务，保留几个历史版本即可（配置变动频率通常远低于客户机数据，不需要像客户机数据那样保留很多份）。

这份归档里全是敏感信息

它包含集群 CA 私钥、用户密码的影子文件、API Token、以及各存储的访问密码（明文）。必须和你最敏感的数据同等对待：加密存放、严格限制谁能读到，绝不要传到不受信任的共享目录或网盘里。

真正丢失整个宿主机之后怎么办

官方文档给出的恢复路径，是把 config.db 复制到一台全新、干净、还没有跑任何客户机的 PVE 主机上：停止 pve-cluster 服务，替换这个文件（权限设为 0600），把 /etc/hostname 和 /etc/hosts 改成和原来那台一致，再重启。这一步只恢复了配置数据库本身，客户机的磁盘数据要另外从 vzdump/PBS 备份里找回。

不要在正常运行的集群节点上直接覆盖 /etc/pve

在一台还保有仲裁（quorum）、正常工作的集群节点上，把旧归档解压出来直接覆盖 /etc/pve，会让这台节点的配置和集群里其它节点的实时状态发生冲突，行为没有文档保证，可能连累整个集群的配置错乱。

上面"复制 config.db"的恢复流程，只适用于这台机器已经彻底重装、还没有加入任何集群、也没有正在跑的客户机这种干净状态。详细的分步骤操作会在 抢救 /etc/pve 与重建节点 里展开，这篇只负责把材料先备份好。

检查结果

1. 归档任务按计划定时执行，能在备份存储上看到最近生成的归档文件。
2. 归档文件确实存在了另一个物理位置，不是宿主机本身的盘。
3. 能列出归档内容并确认包含了 /etc/pve 的关键子目录：tar tzf pve-etc-<日期>.tar.gz | head。
4. 归档的加密/访问方式不是只有你一个人知道（团队场景下尤其重要，避免"人走了密码也没了"）。

常见问题

单节点也需要备份这些吗？ 需要。单节点的 /etc/pve 一样是所有存储定义、客户机配置、用户权限的唯一来源，系统盘坏了照样要重建全部配置。

能不能直接把 /var/lib/pve-cluster/config.db 当备份对象？ 可以作为对官方"替换文件"恢复流程的补充思路，但对大多数人来说，直接归档 /etc/pve 这个通过 FUSE 层读出来的目录内容更直观，也更容易验证内容对不对。

这份归档要多久做一次？ 配置变动很少的家庭实验室，改动后手动跑一次，加上每周定时兜底就够；配置经常变的环境（频繁调整存储、加新用户）建议按天算。

参考资料

• 配置备份任务与保留策略
• 恢复演练 场景三：整台宿主机没了
• 抢救 /etc/pve 与重建节点
• 官方文档：pmxcfs