I Built a Bulletproof Backup System for Passbolt in 30 Minutes (And You Can Too)


The Backstory
So there I was, staring at my shiny new Passbolt installation on Ubuntu 24.04, when that familiar dread crept in: "What happens when (not if) something goes wrong?" After one too many "I'll set up backups tomorrow" moments, I finally decided to build a proper backup system. Spoiler: it was easier than debugging a CSS flexbox issue.
The Problem
Passbolt stores critical password data across multiple locations:
MySQL database (the crown jewels)
Configuration files in
/etc/passbolt
GPG keys and data in
/var/lib/passbolt
User avatars and uploads
Manually backing up each component? That's a recipe for 3 AM disaster recovery panic attacks.
# The manual nightmare nobody wants
mysqldump passbolt > backup.sql
tar -czf config.tar.gz /etc/passbolt
# ...20 more commands you'll forget in a crisis
The Insight
Instead of reinventing the wheel, I created three scripts that work together like a well-oiled DevOps machine:
Backup Script: Handles all components with proper error handling
Restore Script: One-command restoration with safety checks
Systemd Timer: Automated backups every 6 hours
#!/bin/bash
# The magic happens here
BACKUP_DIR="/srv/backup/passbolt"
RETENTION_DAYS="${PASSBOLT_BACKUP_RETENTION_DAYS:-30}"
# Backup everything atomically
mysqldump --single-transaction --routines --triggers "$DB_NAME" > "$TEMP_DIR/database.sql"
cp -a /etc/passbolt "$TEMP_DIR/etc_passbolt"
# ... collect all the pieces
# Create timestamped archive
tar -czf "$BACKUP_DIR/${BACKUP_NAME}.tar.gz" "$BACKUP_NAME"
# Auto-cleanup old backups
find "$BACKUP_DIR" -name "passbolt_backup_*.tar.gz" -type f -mtime +$RETENTION_DAYS -delete
Why It Matters
This setup gives you:
Automated backups running every 6 hours (configurable)
Point-in-time recovery with timestamped archives
Automatic cleanup keeping only the last 30 days
One-command restore that even works during coffee-deprived emergencies
Systemd integration with proper logging and error handling
The restore script even backs up your current data before restoring, because we've all been that person who "fixed" something into oblivion.
Pro Tips I Learned the Hard Way
Always test your restore process - A backup you can't restore is just wasted disk space
Use systemd's
ProtectSystem=strict
- It saved me from accidentally backing up to the wrong directoryInclude version info in backups - Future you will thank present you when dealing with migrations
Set up monitoring - Add
OnFailure=
to your systemd service to get notified when backups fail
TL;DR
Three scripts + systemd timer = automated Passbolt backups with configurable retention. Install with one command, sleep better at night. (I know it’s in French but… TODO: Translate logging to english
)
DON’T TRUST STRANGERS ON INTERNET
# The whole setup in one line
./setup-passbolt-backup.sh
Your passwords are now safer than a JavaScript developer's node_modules folder (and significantly smaller).
What's your backup horror story? Drop a comment below - misery loves company, and we all learn from each other's "learning experiences"! 🎢
Subscribe to my newsletter
Read articles from Hermann Kao directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by

Hermann Kao
Hermann Kao
Software developer documenting my journey through web and mobile development. I share what I learn, build, and struggle with—from React to SwiftUI, architecture decisions to deployment challenges. Not an expert, just passionate about coding and learning in public. Join me as I navigate the tech landscape one commit at a time.