Pritunl Backup: Control State vs the Generated Profile

One archive restores a working Pritunl deployment; the other restores a picture of one. A client profile, a copy of the host configuration, and a tarball of the state directory all look like backups, and none of them alone brings back the organizations, users, and server definitions that Pritunl manages. The difference is ownership: some state belongs to a database, some to the host, and some is regenerated output. Choose the wrong layer and the restore produces a server that starts, listens, and knows nothing. This comparison separates the three layers so the archive you keep matches the failure you are recovering from.

Two objects look like backups and only one restores the service

A downloaded client profile contains a certificate, a key, and an endpoint. It is complete for that one device and useless as a record of the deployment: it carries no organizations, no disabled users, no server routes, and no administrative accounts. Restoring from a folder of profiles gives you clients that cannot authenticate against anything.

A copy of the host configuration is equally partial. /etc/pritunl.conf holds host-level settings, including how to reach the database, and it does not contain the VPN objects themselves.

What the database owns and what the host owns

Pritunl keeps server definitions, users, organizations, and keys in MongoDB. That database is the authoritative control plane, and every generated OpenVPN file on disk is output derived from it. A change made directly to a generated file survives until the next regeneration and then disappears, which is why editing runtime files is not a durable fix. The same rule applies to effective routes and interfaces: they describe what the control plane produced, not what it should produce.

The host contributes a smaller but non-transferable set of values. One is /var/lib/pritunl/pritunl.uuid, the identity of that particular node.

That identity matters most in a cluster. A replacement host needs its own enrollment rather than a clone of an active node's UUID, or the two fight over the same identity. Record the mapping between each host, its UUID, and the database it points at, because a single database dump does not describe which host settings belonged to which machine. Software versions and public endpoint names belong in the same record.

Take a consistent dump, not a directory copy

Copying the MongoDB data directory while the service is writing produces files that may not form a usable database. Use the database's supported dump path instead, run against the topology you actually have:

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

A standalone host tolerates that simple form. A replica set needs a consistent point in time, and an oplog-based dump has requirements that a plain dump does not. The supported procedure depends on your MongoDB version and topology, so do not infer one from the presence of a data directory. Archive the host layer beside the dump, in the same run, with the same timestamp.

Rehearse the restore before you need it

A backup nobody has restored is a hypothesis. Build the service in an isolated network, restore the dump, and put the host files back:

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

Then verify the objects rather than the process: log in, confirm organizations and users are present, and bring up one test client against a server definition you recognize. Keep the restored host from advertising the production endpoint or accepting real connections until addresses and identities are deliberate. This is also where you discover that the archive needs credentials that lived only on the failed machine, so store recovery credentials somewhere independent. A restore that depends on the host you just lost is not a restore plan.

Finally, remember that an old snapshot restores old decisions. If an administrator disabled an identity after the dump was taken, the restore re-enables it. Reconciliation after recovery belongs in the procedure, not in the afterthought.