Passbolt Community Edition is frequently deployed first on a traditional **Ubuntu Server**—either bare metal or a VM—before being consolidated into a **Proxmox LXC container** for better density, snapshots, and lifecycle management.
The migration path is straightforward *if* backups are done correctly.
This article documents a **safe, deterministic backup strategy** for a **source-installed Passbolt CE instance on Ubuntu Server 22.04**, designed specifically so the backup can be **restored into a Proxmox LXC** created with the official helper script:
https://community-scripts.github.io/ProxmoxVE/scripts?id=passbolt
The goal is not just to back up Passbolt—but to ensure **cryptographic continuity**, so existing secrets remain decryptable after the move.
—
## Source and Destination Architecture
### Source System (Backup Origin)
* Ubuntu Server 22.04
* Passbolt CE installed from source / Debian packages
* Nginx + PHP-FPM + MariaDB/MySQL
* Live, in-use Passbolt instance
### Destination System (Restore Target)
* Proxmox VE host
* LXC container created via **Proxmox VE Helper-Scripts**
* Ubuntu 22.04–based container
* Passbolt CE already installed and verified working
This guide assumes **Passbolt is already installed on the LXC** before restore. The backup process ensures the data, keys, and configuration align cleanly.
—
## What Must Be Backed Up (and Why It Matters)
A successful migration depends on preserving **three inseparable components**.
### 1. Passbolt Database
The database stores:
* Users and groups
* Resource metadata
* Permissions and sharing relationships
* Audit and history data
Without it, Passbolt has no identity.
### 2. GPG Server Keys (Public and Private)
These keys are the **cryptographic backbone** of Passbolt.
* The public key encrypts secrets
* The private key decrypts them
If the private key is lost or replaced, **all stored passwords become permanently unreadable**—even if the database is intact.
### 3. `passbolt.php` Configuration
This file binds everything together:
* Database credentials * GPG key fingerprints * Application and environment settings
It must match the restored database and keys exactly.
—
## Why the Official Passbolt Export Is Mandatory
Although it is tempting to run `mysqldump`, Passbolt provides a supported export mechanism for a reason:
“`
cake passbolt mysql_export
“`
This command:
* Runs with correct permissions
* Produces restore-ready SQL
* Avoids subtle schema and privilege issues
All backups in this workflow use the **official export path only**.
—
## Backup Strategy (Ubuntu Server → LXC-Safe)
The backup is performed **on the original Ubuntu Server**, not the Proxmox host.
At a high level:
1. Export the Passbolt database using `cake passbolt mysql_export`
2. Copy:
* `passbolt.php`
* `serverkey.asc`
* `serverkey_private.asc`
3. Package everything into a timestamped archive
4. Store the archive on persistent storage
5. Enforce retention automatically
The resulting `.tar.gz` file is **portable** and can be restored into:
* A Proxmox LXC
* A VM
* Another Ubuntu host
—
## Implementing the Backup Script on the Source Server
On the **Ubuntu Server hosting Passbolt**, the recommended approach is a single authoritative script:
“`
/usr/local/sbin/passbolt_backup.sh
“`
The script:
* Runs as `root`
* Executes database export as `www-data`
* Uses the official Passbolt tooling
* Archives database, GPG keys, and configuration together
* Produces deterministic, timestamped backups
A complete, operator-grade implementation—ready for copy/paste and cron execution—is documented in the **Passbolt Backup Run Book** .
This run book is written for real recovery scenarios, not theory.
—
## Transferring the Backup to Proxmox
Once the backup archive is created on the Ubuntu Server, it can be transferred using standard tooling:
* `scp`
* `rsync`
* NFS
* CIFS
* Object storage (if staged)
The archive should be copied into the **LXC container** (or made accessible via a mounted volume) before restoration.
—
## Restoring into the Proxmox LXC
On the destination LXC:
* Passbolt must already be installed via the helper script
* Services must be stopped cleanly
* The database, GPG keys, and configuration must be restored **in the correct order**
A step-by-step, pressure-tested restore procedure—assuming an existing LXC with Passbolt installed—is documented in the **Passbolt Source Restore Run Book** .
That run book covers:
* Database user and privilege alignment
* GPG key restoration and permissions
* Configuration verification
* Migrations
* Health checks
* Functional validation (actual password decryption)
If passwords decrypt successfully, the migration is complete.
—
## Where Proxmox Features Fit (and Where They Don’t)
After migration:
* **Proxmox snapshots** provide fast rollback
* **vzdump** provides host-level disaster recovery
* **ZFS replication** adds resilience
However, none of these replace:
* Application-aware database exports
* Explicit GPG key backups
Proxmox protects *containers*.
Your backup strategy must protect *cryptography*.
—
## Final Thoughts
Migrating Passbolt from an Ubuntu Server to a Proxmox LXC is not difficult—but it is unforgiving if backups are incomplete.
By:
* Backing up from the original source install correctly
* Preserving cryptographic identity
* Using Passbolt’s supported export tooling
* Restoring into a clean, known-good LXC
you end up with a migration that is boring, repeatable, and safe.
That is exactly what you want when handling secrets.