Server — Backup Introduction

At some point February will fail. The SD card will corrupt, a config change will go badly wrong, something will happen that leaves the server unbootable or the data inaccessible. This is not pessimism, it is the baseline assumption any honest backup strategy starts from. The question is not whether something will eventually go wrong. It is whether you will be able to recover when it does.

This article is the introduction to a short series on how February’s backup strategy is structured. The implementation details come in follow-on articles. This one is about the thinking.

What actually needs backing up

February runs several things, but not all of them are equally painful to lose. It helps to be explicit about this before designing anything.

Configuration files are the things that took time and thought to get right: WireGuard profiles, NUT configuration, ChirpStack device profiles, Home Assistant configuration, MQTT broker settings, UFW rules, SSH config. Most of this lives under /etc and in various /home and service directories. Individually the files are small. Collectively they represent weeks of work. Losing them and having to reconstruct from memory is unpleasant. Losing them and having no record of what was there is worse.

Application data is the stuff that accumulates over time and cannot be reconstructed: the InfluxDB time-series data from sensors, Home Assistant’s history database, ChirpStack’s device join records. Some of this is more replaceable than others. Sensor history from six months ago is interesting but not critical. The ChirpStack device registry is harder to reconstruct because it contains join keys that were provisioned when the device was first added.

The system itself is February’s operating system, installed packages, and everything else needed to make it boot and run. This is the most recoverable thing on the list. Reinstalling Ubuntu and running through the setup articles in this series is annoying but entirely doable. Rebuilding from a fresh OS is always an option, which is why good configuration backups matter: they are what turns a rebuild from a nightmare into an afternoon.

That ordering is deliberate. Config first, data second, the system a distant third.

The tool: Borgbackup

Borgbackup is a deduplicating, compressing, encrypting backup tool that works natively over SSH. It is the right choice here for a few reasons.

Deduplication means that if a file has not changed between backups, it is not stored again. A daily backup of February’s config files does not consume a full copy of those files every day. Only the changed blocks are added. This keeps the NAS footprint small even with a long retention history.

Encryption means the backup repository on the NAS is encrypted at rest. If the NAS is ever accessed by something or someone that should not have it, the backup data is not readable without the passphrase. This matters more for some things than others, but WireGuard private keys and similar material should not be sitting in plaintext on a network share.

SSH transport means Borg talks to the NAS over SSH rather than mounting a network share. This is simpler to set up securely, avoids the reliability issues that come with SMB or NFS mounts, and means the backup process works the same way whether the NAS is local or remote.

Borgmatic sits on top of Borg and handles the scheduling, retention policy, and notifications through a single YAML configuration file. Rather than writing and maintaining shell scripts to wrap Borg commands, borgmatic gives you a declarative configuration that is easy to read and audit.

The destination: the NAS

Backups go to the NAS over SSH. February pushes to the NAS; the NAS does not pull from February. This is the standard push model and it means the backup process runs on February’s schedule without requiring anything active on the NAS side beyond an SSH server and a Borg installation.

The NAS needs Borgbackup installed and a dedicated user with SSH key access and a home directory where the repository will live. The next article in this series covers that setup in detail.

What is not covered here

This series covers configuration and data backup from February to the NAS. It does not cover:

NAS redundancy. The NAS itself needs its own backup story. Having February’s backups on a NAS that has no redundancy or offsite copy means a NAS failure takes both the server and the backups at the same time. That is a single point of failure. Dealing with it is outside the scope of this series but worth acknowledging.

Full system imaging. February is not imaged. The decision to rebuild from scratch rather than restore a system image is a deliberate one: images of a running system are messy to restore reliably on different hardware, and the combination of a reproducible OS install plus good config backups is more robust. If you want system imaging, tools like Clonezilla exist for that purpose.

Real-time replication. Borgbackup runs on a schedule. There is a window between backups during which new data is not yet protected. For a homelab server this is an acceptable tradeoff. If it is not acceptable for your use case, you need a different tool.

The shape of the series

The following articles cover the implementation:

NAS setup — installing Borgbackup on the NAS, creating the backup user, and initialising the repository.

February setup — installing borgmatic, writing the configuration, defining what gets backed up and how long it is kept.

Scheduling and notifications — running borgmatic on a timer, confirming backups are actually happening, and getting notified when they are not.

Testing restores — the part everyone skips and should not. A backup that has never been tested is a backup you cannot rely on.

The goal by the end of the series is a backup process that runs without intervention, keeps a sensible history, and has been verified to actually restore correctly. That is the minimum bar. Everything else is detail.