restic vs Kopia

Every comparison of these two ends up praising KopiaUI's screenshots. Set that aside. A backup tool is judged on what happens when you need it and on what quietly rots when you are not watching, and on both of those axes the interesting differences are elsewhere: who owns maintenance, what a version bump can remove, and how many processes are listening on a port.

What the specification table decides#

Services to run shows the real architectural gap: restic is not container shaped at all, it is a binary that exits, while Kopia normally means a long-lived process. Datastore looks identical (both content-addressed repositories, no database service) and hides a difference: Kopia's index is epoch-based and its space reclamation is asynchronous, which is why the maintenance section below exists. Maturity is mature against stable, and that is a real distinction here rather than a label.

Kopia is still 0.x after seven years, and that means something specific#

Kopia's first release was 2019. It is at 0.23.x in 2026. That is not a sign of instability in the sense of crashes, and the code is used in production by plenty of people. What the version number correctly signals is cadence and change policy:

• Two to four releases a year, in bursts rather than on a train.
• Breaking changes land inside minor versions. 0.23.0 (May 2026) removed LZ4 compression outright and restricted unauthenticated server binds to loopback only. If your policy specified an LZ4 variant, it broke. If you had kopia server bound to a LAN address without credentials, it stopped working.
• 0.23.1, a month later, fixed a rare race condition that could lose data.

restic is also technically 0.x, at 0.19.1 released 5 July 2026, and it has been for eleven years. The difference is not the digit, it is that restic does not remove features between minors and newer restic reads older repositories, so upgrades never break restores.

None of this makes Kopia a bad choice. It makes it a choice you should pin a version for, read release notes before bumping, and not run latest in a container against.

The GUI and CLI compatibility question has a boring answer#

This is the question everyone asks and the answer is genuinely reassuring: there is one repository format. KopiaUI bundles a kopia binary and speaks exactly the same format as the CLI. A repository created by a cron job on your server opens in KopiaUI on your desktop, and a repository created in KopiaUI is scriptable from the command line. No import, no conversion, no "GUI edition".

What is separate is connection state. All three shapes (CLI, kopia server --ui, KopiaUI) read *.config files from %APPDATA%\kopia, $HOME/.config/kopia or ~/Library/Application Support/kopia, and KopiaUI attempts to connect to every file ending in .config at startup. Leftovers from testing produce errors and phantom repositories in the interface. Rename them to .config.bak and the noise stops.

The genuinely strict part is version compatibility. Kopia promises to read the current repository format plus at least one previous, refuses to write a format it does not handle, and will never upgrade a repository without an explicit human command:

kopia repository upgrade begin \
  --upgrade-owner-id=laptop@home \
  --io-drain-timeout=5m --allow-unsafe-upgrade

That is a coordinated operation. Every client must already be on the new version and disconnected while it runs, because older Kopia cannot open the upgraded repository afterwards. Upgrading your laptop's Kopia and forgetting the NAS is how you find out, when the NAS starts refusing to write to a repository it can still read.

The maintenance owner is Kopia's real operational trap#

Exactly one client performs full maintenance on a Kopia repository. Quick maintenance runs roughly hourly, full maintenance every 24 hours, and only full maintenance marks unreachable content so blobs can eventually be deleted.

If that owning machine is reimaged, retired or simply left off for a month, every other client keeps backing up successfully, kopia snapshot delete keeps appearing to work, and nothing is ever reclaimed. Your bucket grows forever with no error anywhere. Check it:

kopia maintenance info
kopia maintenance set --owner=nas@home

Put that first command in whatever you use to review your infrastructure quarterly. It is the single most common way a Kopia repository goes wrong, and it is silent.

restic's equivalent is not silent, it is loud in the other direction. restic forget only removes references and restic prune reclaims, and if you never run prune your bill visibly stops falling. The failure is obvious because it is your job to schedule both:

restic forget --host web1 --keep-daily 7 --keep-weekly 4 --keep-monthly 12
restic prune --max-repack-size 20G --retry-lock 10m

Neither model is wrong. Kopia's fails quietly and restic's fails to your cron log. Pick the one whose failure mode you will actually notice.

What Kopia gives you that restic does not#

Three things, and they are worth real money in the right situation:

1. Policies that live in the repository. Compression, exclusions and retention are per-directory with inheritance, stored server side rather than duplicated across everyone's crontab. Changing retention for all laptops is one command, not four cron edits.
2. A repository server. Laptops connect to kopia server with their own credentials and never hold the object storage keys. If a laptop is stolen, you revoke one user rather than rotating a bucket key and updating every other machine. Since 0.23.0 an unauthenticated server may only bind to loopback, so remote access requires credentials plus TLS or a proxy in front. Put Caddy there and read Reverse proxy and TLS.
3. Scheduling inside the tool. No systemd timers, no cron, no wrapper. For a Windows desktop or a Mac in a household, that is the difference between backups happening and not happening.

Kopia has no OIDC or LDAP. Server auth is local users and client certificates only, so if every service in your house must sit behind Authelia or Pocket ID, Kopia's server is an exception you will have to proxy. See Single sign-on for self-hosters.

What restic gives you that Kopia does not#

A smaller thing to be wrong about. No daemon, no listening port, no web application, no auth model, no scheduler. It runs, it exits, it leaves a repository. Backends are compiled in, so a bucket at Backblaze or a Garage cluster is a URL:

export RESTIC_REPOSITORY="s3:s3.eu-central-003.backblazeb2.com/tdg-backups/nas"
restic backup /srv --exclude-caches --compression auto
restic check --read-data-subset=1/10

It also has the stronger immutability story. rest-server with --append-only, or S3 Object Lock on the bucket, means a compromised client cannot delete its own history. Kopia has no equivalent enforcement of its own, and its maintenance model requires delete rights on the destination by design.

The price is genuine. There is no GUI, no dashboard, no schedule you can click, and the third party wrappers are yours to maintain. On a laptop belonging to someone who will never open a terminal, that is a bad trade.

Do not choose on aesthetics#

KopiaUI looks better than a cron log. That is true and it is close to irrelevant, because the interface is not what you interact with when the backup matters. What you interact with then is a restore, and both tools restore fine.

What you interact with the other 364 days is failure notification, and neither tool sends you one by itself. Whichever you pick, wire the exit code somewhere you will see it, and rehearse a restore on a schedule. A pretty dashboard showing green for a repository nobody has ever restored from is worse than an ugly cron job you have tested.

Which one for your situation#

What to do next#

If you are backing up servers, run restic and use Backup planner to size retention against your actual data before you point it at a bucket. If you are backing up a household, run Kopia, and on the same day you set it up run kopia maintenance info and write the owning machine's name down somewhere you will see it again.

Then read Backups that actually restore, because the verification cadence matters more than the tool: restic check --read-data-subset=1/10 or kopia snapshot verify --verify-files-percent=5 monthly, and a real restore of a real file quarterly. If neither of these is the shape you want, restic vs BorgBackup covers the SSH-only option and Duplicati vs restic covers the fully clickable one. The Backup category has rclone for the cases where you do not want snapshots at all.