Backup

Everything built in the secrets section of this series, GPG keys, SSH keys, certificates, KeePassXC databases, represents a significant investment of time and generates material that cannot be recreated if lost. The same is true of a home directory more broadly: documents, code, configuration, years of accumulated work. Disk failure, accidental deletion, ransomware, a stolen laptop: any of these can happen. The question is not whether to back up but how, and how to verify that the backup actually works when needed.

This section covers the backup strategy for the Kubuntu desktop using BorgBackup and borgmatic. Two separate backup configurations are maintained: one for user data (the home directory) and one for system configuration (everything a fresh install would need to know about this particular machine).

The tools

BorgBackup is a deduplicating backup program. It optionally supports compression and authenticated encryption. The data deduplication technique makes Borg suitable for daily backups since only changes are stored. The authenticated encryption technique makes it suitable for backups to not fully trusted targets.

Borgmatic is a simple, configuration-driven frontend to automate Borg backup on servers and workstations. It handles protecting files with client-side encryption, backing up databases, and monitoring with integrated third-party services.

Vorta is a backup client for Linux desktops. It integrates Borg with the desktop environment to protect data from disk failure, ransomware, and theft.

In practice: borgmatic handles the automated scheduled backups via anacron, and Vorta provides a graphical interface for browsing archives and restoring individual files. Both talk to the same Borg repositories.

The strategy

Two independent backup streams run from the desktop:

User data backup covers the home directory. Runs daily via anacron. Backs up to the NAS on the local network and to a second NAS at a different site via the VPN. Space-efficient storage through deduplication means daily backups do not consume proportionally more storage than weekly ones, so daily is the right default.

System configuration backup covers /etc, /boot, /opt, /root, /usr/local, and /var. Runs weekly via anacron. This is not an image backup: it captures the configuration that makes this machine what it is, not the operating system itself. A fresh Kubuntu install plus a system configuration restore gets back to a working state faster and more cleanly than restoring an image to different hardware.

Both streams encrypt data client-side before it leaves the desktop. The backup server never sees plaintext. This is the correct model for backing up to any destination you do not fully control.

The 3-2-1 rule applied

A backup strategy worth having follows the 3-2-1 principle: three copies of data, on two different media types, with one copy off-site. For this network:

• Copy 1: the live data on the desktop
• Copy 2: backup on the local NAS (Burnage Mad House)
• Copy 3: backup on the NAS at a second site (The Lighthouse) via VPN

This gives two independent backup destinations. If the local NAS fails or the house burns down, the off-site copy survives. If the VPN is down when the backup runs, the local copy still gets written and the off-site copy catches up next time.

What this section covers

• Installation — Installing BorgBackup, borgmatic, and Vorta on Kubuntu 24.04
• User data backup — Borgmatic configuration for the home directory
• System configuration backup — Borgmatic configuration for system files
• Scheduling — Running both via anacron so backups happen even on a machine that is not always on
• Vorta — The graphical interface for browsing and restoring

A note on installation

The source material this series draws on installs BorgBackup and borgmatic via pip as a system-wide Python installation. This approach causes problems on Ubuntu 24.04 due to PEP 668, which prevents pip from installing packages into the system Python environment by default. The installation page covers the current recommended approach, which uses the Ubuntu package for BorgBackup and pipx for borgmatic, avoiding the conflict.

Before you continue

Two things need to be in place before the backup section makes sense.

First, the NAS. The backup destination is a NAS running a Borg backup server. If you do not have a NAS set up yet, the NAS section of this series covers it. The desktop backup section can be read now and implemented once the NAS is ready.

Second, the SSH key for backups. Borg connects to the remote repository over SSH using a dedicated key, not your personal SSH key. This key is generated during setup and its public key is installed on the NAS with a forced command that restricts it to Borg operations only. This is covered in the installation page.

The only backup that matters is one you have tested. Verify a restore works before you need it. The borgmatic extract command does a dry-run extraction. Use it.