Pritunl: estado de control frente al perfil generado

Un archivo restaura una implementación de Pritunl en funcionamiento; el otro restaura una imagen de ella. Un perfil de cliente, una copia de la configuración del host y un tarball del directorio de estado se parecen todos a copias de seguridad, y ninguno de ellos por sí solo devuelve las organizaciones, los usuarios y las definiciones de servidor que gestiona Pritunl. La diferencia es la propiedad: parte del estado pertenece a una base de datos, parte al host y parte es salida regenerada. Elija la capa equivocada y la restauración producirá un servidor que arranca, escucha y no sabe nada. Esta comparación separa las tres capas para que el archivo que guarde coincida con el fallo del que se recupera.

Dos objetos parecen copias de seguridad y solo uno restaura el servicio

Un perfil de cliente descargado contiene un certificado, una clave y un punto de conexión. Es completo para ese único dispositivo e inútil como registro de la implementación: no lleva organizaciones, ni usuarios deshabilitados, ni rutas de servidor, ni cuentas administrativas. Restaurar desde una carpeta de perfiles da clientes que no pueden autenticarse contra nada.

Una copia de la configuración del host es igualmente parcial. /etc/pritunl.conf contiene ajustes de nivel de host, incluida la forma de llegar a la base de datos, y no contiene los objetos VPN en sí.

Qué posee la base de datos y qué posee el host

Pritunl guarda las definiciones de servidor, los usuarios, las organizaciones y las claves en MongoDB. Esa base de datos es el plano de control autoritativo, y cada archivo OpenVPN generado en disco es una salida derivada de ella. Un cambio hecho directamente en un archivo generado sobrevive hasta la siguiente regeneración y luego desaparece, por eso editar archivos en tiempo de ejecución no es una corrección duradera. La misma regla se aplica a las rutas e interfaces efectivas: describen lo que produjo el plano de control, no lo que debería producir.

El host aporta un conjunto de valores más pequeño pero no transferible. Uno de ellos es /var/lib/pritunl/pritunl.uuid, la identidad de ese nodo concreto.

Esa identidad importa sobre todo en un clúster. Un host de reemplazo necesita su propia inscripción en lugar de un clon del UUID de un nodo activo, o los dos se pelearán por la misma identidad. Registre la correspondencia entre cada host, su UUID y la base de datos a la que apunta, porque un solo volcado de la base de datos no describe qué ajustes del host pertenecían a qué máquina. Las versiones de software y los nombres de punto de conexión públicos pertenecen al mismo registro.

Haga un volcado consistente, no una copia de directorio

Copiar el directorio de datos de MongoDB mientras el servicio escribe produce archivos que pueden no formar una base de datos utilizable. Use en su lugar la ruta de volcado admitida por la base de datos y ejecútela contra la topología que realmente tenga:

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

Un host autónomo tolera esa forma simple. Un conjunto de réplicas necesita un punto en el tiempo consistente, y un volcado basado en oplog tiene requisitos que un volcado simple no tiene. El procedimiento admitido depende de su versión y topología de MongoDB, así que no lo deduzca de la presencia de un directorio de datos. Archive la capa del host junto al volcado, en la misma ejecución y con la misma marca de tiempo.

Ensayé la restauración antes de necesitarla

Una copia de seguridad que nadie ha restaurado es una hipótesis. Construya el servicio en una red aislada, restaure el volcado y devuelva los archivos del host a su sitio:

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

Después verifique los objetos en lugar del proceso: inicie sesión, confirme que las organizaciones y los usuarios están presentes y levante un cliente de prueba contra una definición de servidor que reconozca. Evite que el host restaurado anuncie el punto de conexión de producción o acepte conexiones reales hasta que las direcciones e identidades sean deliberadas. Aquí también descubre que el archivo necesita credenciales que solo vivían en la máquina fallida, así que guarde las credenciales de recuperación en algún lugar independiente. Una restauración que depende del host que acaba de perder no es un plan de restauración.

Por último, recuerde que una instantánea antigua restaura decisiones antiguas. Si un administrador deshabilitó una identidad después de tomar el volcado, la restauración la vuelve a habilitar. La reconciliación tras la recuperación pertenece al procedimiento, no a la ocurrencia tardía.