Kopia

Last reviewed Aug 26, 2026 · 933 words

Kopia is what I recommend to someone who wants restic's model, encrypted content-addressed snapshots to any storage backend, but also wants a scheduler, a GUI and retention rules that do not depend on a cron job they wrote at midnight. Under the hood the two tools are cousins: snapshots deduplicate at the block level, every byte is encrypted client-side, and a repository can live on a local disk, SFTP, S3, Backblaze B2, Azure, GCS or anything rclone can reach. The differences are in what happens around the snapshots.

Same model as restic, three things restic does not ship

First, policies are stored in the repository itself. kopia policy set --keep-daily 30 --keep-weekly 8 --keep-monthly 24 /home/aidan records retention against that path, and every client that connects sees and applies it. In restic, retention is an argument to forget that lives wherever your script lives. Second, scheduling: the same policy can carry --snapshot-interval 1h, and the KopiaUI desktop app or kopia server honours it, so a laptop backs itself up without launchd or systemd timers. Third, the interface. KopiaUI is a proper desktop app on Windows, macOS and Linux with a snapshot browser and restore-by-click, and kopia server puts the same UI in a browser for a headless box. If you have been running restic with a wrapper like Backrest purely to get those three things, Kopia has them natively. The BorgBackup vs restic comparison covers the two older tools; Kopia sits closer to restic than to Borg.

First repository in five commands

kopia repository create filesystem --path /mnt/backup/kopia
kopia policy set --global --compression=zstd --keep-daily 30 --keep-monthly 12
kopia snapshot create /home/aidan
kopia snapshot list
kopia restore k1a2b3c4d5 /tmp/restore-test

repository create asks for a password and writes the repository format; swap filesystem --path for s3 --bucket backups --endpoint s3.eu-central-1.wasabisys.com or b2 --bucket for off-site. Compression is off by default, so the second line matters for anything that is not already compressed; zstd is the sane choice. The last line is not optional. A restore you have never run is a hypothesis, and Kopia makes the test cheap: kopia mount all /mnt/kopia exposes every snapshot as a browsable filesystem too. Encryption is AES-256-GCM by default, and the repository password is the only key. Store it in your password manager and somewhere offline, because there is no recovery path and that is the point.

Snapshots are keyed by user, host and path

Kopia identifies a snapshot source as user@host:/path. That is convenient until you rebuild a machine with a different hostname, at which point the new box appears to have no history and the old one's snapshots stop being pruned. The fix is to connect with --override-hostname and --override-username so the identity stays stable across reinstalls, and to write those flags down in the same place as the password. The catalogue's con, "advanced options can confuse", is mostly this class of thing: sensible defaults with a long tail of flags whose consequences show up months later.

Maintenance runs as one owner, on a schedule

Deduplication leaves garbage behind when snapshots expire. Kopia cleans it in two tiers, quick maintenance roughly hourly and full maintenance daily, and it runs automatically from whichever client is the repository's designated owner. Only that owner runs it; other clients skip it silently. If you set up a repository from a laptop that then spends a month closed, no maintenance happens and the repository grows. On a server-centred setup, make the always-on machine the owner with kopia maintenance set --owner user@server, and check kopia maintenance info now and then. This is the one operational habit Kopia asks for that restic's explicit prune does not, and I prefer it, because a scheduled job that runs is better than a manual one that does not.

Where it sits in a self-hoster's backup stack

Kopia is a client-side tool, not a backup server. The natural layout is Kopia on every machine that has data worth keeping, all pointing at one repository on the NAS or an S3 bucket, with the NAS copy itself replicated off-site: the shape my 3-2-1 for self-hosters piece recommends. For Docker hosts, kopia/kopia in a container with the volumes mounted read-only does the same job on a schedule. If you are leaving Backblaze Personal Backup, Kopia to a B2 bucket gives you the same off-site destination at a per-GB price rather than a per-machine one, and it backs up the server that Backblaze's client never supported. The backup category covers the server-side and Windows-image tools this does not replace.

What I'd do

One repository on the NAS, zstd compression, a global policy of 30 daily, 8 weekly and 24 monthly, every machine connecting with an explicit --override-hostname, and the NAS's own Kopia client set as maintenance owner. KopiaUI on the laptops for hourly snapshots, the container on the Docker host nightly, and the NAS repository synced to B2 with rclone. A kopia restore of one directory to /tmp on the first of every month. Kopia is younger than restic and the catalogue is right to say so, but it has been stable for years, and the workflow it gives ordinary humans is the one that actually gets run.