Backups, updates & basic security

Every tool guide on this site points back here with some version of "back this up." The classic rule for how: three copies of your data, on two different types of storage, with one of those copies somewhere else entirely.

Each part covers a different way of losing data. Three copies means no single failure wipes out your only version. Two storage types means one failure mode, a bad drive, a ransomware infection that encrypts every mounted disk, a RAID controller giving up, can't take out both copies at once. One copy off-site means a fire, theft, or your server provider having a genuinely bad day doesn't take out everything you have.

One common trap worth naming directly: RAID is not a backup. A mirrored disk protects against a drive failing. It does nothing against you, or malware, deleting or corrupting a file, because the mirror faithfully copies that deletion too. People have lost everything trusting RAID alone.

You've probably noticed a pattern across this site: Nextcloud, Immich, Vikunja, and BookStack all treat their files and their database as two separate things to back up. That's not caution for its own sake.

The database holds the relationships, which photo is in which album, who owns what, what's shared with whom, while the files hold the raw content itself. Back up only the files and you'll have a folder of photos with no albums, tags, or shares left. Back up only the database and you'll have a list of files that no longer exist. You need both, captured at roughly the same moment.

One more detail worth getting right: don't just copy a database file while the app is running. A database being actively written to can be caught mid-write, producing a backup that looks fine and fails to restore. Use the tool's own export command instead, pg_dump for Postgres, mysqldump for MySQL/MariaDB, which several of the tool guides on this site already show for their specific database.

The lowest-effort option is your provider's automated snapshots, mentioned in the get-started guide. Worth turning on, but it only covers "two different types of storage" loosely, a snapshot still lives on the same provider's infrastructure as the server it's protecting.

A more complete routine doesn't need to be elaborate: a scheduled task that dumps each app's database, bundles the relevant folders into an archive, and copies the result somewhere off-server. A cron job running a couple of commands once a day covers most of this, for example dumping a database and syncing a folder to an off-site storage service with a tool like rclone:

0 3 * * * docker compose exec -T db pg_dump -U app app_db > /backups/app-$(date +%F).sql
0 4 * * * rclone sync /backups remote:my-backups

The exact commands change per app and per storage provider, but the shape stays the same: dump, bundle, copy elsewhere, on a schedule you don't have to remember to run by hand.

A backup nobody has ever restored from is a hope, not a backup. The failure mode is specific and common: a backup job silently breaks weeks or months before you actually need it, and you only find out when it's too late to matter.

The fix is simple to describe and easy to keep putting off anyway: every so often, actually restore from your latest backup, onto a throwaway server or a fresh container, and confirm the app comes back with real data in it. If that works, you have a backup. Until you've tried it, you have a folder you're hoping is one.

Backups protect you after something goes wrong. Updates are what make that less likely in the first place, and they're easy to let slide once a server is quietly working.

On the operating system side, Ubuntu's unattended-upgrades package installs security patches automatically, in the background, without you needing to remember. For the containers themselves, the habit from every tool guide on this site still applies: docker compose pull && docker compose up -d every so often, per app, rather than letting an image sit untouched for years.

Tools exist to automate that last step too, Watchtower is the common one, but automatic container updates can also automatically break something if a new version changes its configuration format. For anything higher-stakes, a password manager, a wiki with real content, reading the release notes and updating on your own schedule is usually the safer habit.

Everything this series has taught piece by piece, gathered here: SSH keys instead of a password, a firewall enabled before anything else starts, a non-root user with sudo for anything that needs admin rights, a reverse proxy instead of exposed ports, default passwords and admin tokens changed immediately, images kept reasonably current, and backups that have actually been restored at least once. None of it is exotic. Doing all of it consistently is the entire job.