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

Hermann KaoHermann Kao
3 min read

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:

  1. Backup Script: Handles all components with proper error handling

  2. Restore Script: One-command restoration with safety checks

  3. 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

  1. Always test your restore process - A backup you can't restore is just wasted disk space

  2. Use systemd's ProtectSystem=strict - It saved me from accidentally backing up to the wrong directory

  3. Include version info in backups - Future you will thank present you when dealing with migrations

  4. 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)

Run as root BUT READ IT BEFORE

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"! 🎢

0
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.