Pritunl 备份：控制状态与生成的配置文件

一个归档能恢复可用的 Pritunl 部署；另一个只恢复它的一个快照。客户端配置文件、主机配置副本和状态目录的 tarball 看起来都像备份，但它们单独任何一个都无法带回 Pritunl 管理的组织、用户和服务器定义。区别在于归属：一部分状态属于数据库，一部分属于主机，还有一部分是重新生成的输出。选错了层次，恢复出来的服务器会启动、监听，却一无所知。这项比较把三个层次分开，让你保留的归档与你正在恢复的故障相匹配。

两个对象看起来都像备份，但只有一个能恢复服务

下载的客户端配置文件包含证书、密钥和端点。它对那一台设备是完整的，作为部署记录却毫无用处：它不包含组织、被禁用的用户、服务器路由或管理账户。从配置文件文件夹恢复，得到的客户端无法向任何东西认证。

主机配置副本同样片面。/etc/pritunl.conf 保存主机级设置，包括如何连接数据库，却不包含 VPN 对象本身。

数据库拥有什么，主机拥有什么

Pritunl 把服务器定义、用户、组织和密钥保存在 MongoDB 中。该数据库是权威的控制平面，磁盘上每个生成的 OpenVPN 文件都是从它派生的输出。直接修改生成文件会保留到下一次重新生成，然后消失，这就是编辑运行时文件不是持久修复的原因。同样的规则适用于生效的路由和接口：它们描述控制平面产出了什么，而不是它应该产出什么。

主机贡献一组更小但不可转移的值。其中一个是 /var/lib/pritunl/pritunl.uuid，即该特定节点的身份。

这种身份在集群中最重要。替换主机需要自己的注册，而不是活动节点 UUID 的克隆，否则两者会争夺同一身份。记录每台主机、其 UUID 以及它所指向的数据库之间的映射，因为单次数据库转储无法说明哪些主机设置属于哪台机器。软件版本和公共端点名称属于同一条记录。

做一致性转储，而不是目录副本

在服务写入时复制 MongoDB 数据目录，会产生可能无法组成可用数据库的文件。请改用数据库支持的转储路径，并针对你实际拥有的拓扑运行：

mongodump --uri="mongodb://127.0.0.1:27017/pritunl" --out=/var/backups/pritunl/db
sudo tar czf /var/backups/pritunl/host.tgz /etc/pritunl.conf /var/lib/pritunl/pritunl.uuid

独立主机能承受这种简单形式。副本集需要一致的时间点，而基于 oplog 的转储有普通转储没有的要求。受支持的过程取决于你的 MongoDB 版本和拓扑，所以不要从数据目录的存在推断它。把主机层与转储一起归档，在同一次运行中，使用相同的时间戳。

在需要之前演练恢复

没有人恢复过的备份只是假设。在隔离网络中构建服务，恢复转储，并把主机文件放回：

mongorestore --uri="mongodb://127.0.0.1:27017" --drop /var/backups/pritunl/db
sudo tar xzf /var/backups/pritunl/host.tgz -C /

然后验证对象而不是过程：登录，确认组织和用户存在，并用你认识的服务器定义启动一个测试客户端。在地址和身份成为有意为之之前，阻止恢复的主机宣传生产端点或接受真实连接。你也会在这里发现，归档需要只存在于故障机器上的凭据，因此要把恢复凭据存放在独立的地方。依赖你刚刚丢失的主机的恢复，不是恢复计划。

最后，请记住旧快照会恢复旧决定。如果管理员在转储之后禁用了某个身份，恢复会重新启用它。恢复后的核对属于流程，而不是事后想法。