restic vs Kopia

restic and Kopia are two open source backup tools that self-hosters often weigh when they need to get a VPS's data off the box: encrypted, deduplicated snapshots pushed to an S3 bucket, a Backblaze B2 account or another server over SFTP. Both are single Go binaries, both encrypt everything before it leaves the machine, and both only upload the parts of a file that changed. The real differences are in how much each one does for you: restic is a command you run and schedule yourself, while Kopia carries policies, a scheduler, automatic maintenance and a web UI inside the same binary.

The shared foundation

Both split files with content-defined chunking, so an edit in the middle of a large file does not re-upload the whole thing.

• restic cuts files with Rabin fingerprints over a 64-byte sliding window. Its design document says files under 512 KiB are not split and blobs run from 512 KiB to 8 MiB. Everything in the repository is encrypted with AES-256 in counter mode and authenticated with Poly1305-AES, and there is no unencrypted mode.
• Kopia splits with a rolling hash (the default splitter is DYNAMIC-4M-BUZHASH) and packs the pieces into 20-40 MB pack files with random names. You choose AES256-GCM-HMAC-SHA256 (the default) or CHACHA20-POLY1305-HMAC-SHA256 when you create the repository, and its docs say it "does not allow creating unencrypted backups".

Both licences are permissive: restic is BSD-2-Clause, Kopia is Apache-2.0.

The password works the same way in both, and it is the one thing you cannot get back. restic's quick start warns that "losing your password means that your data is irrecoverably lost". Kopia's docs say there is "no way to recover a forgotten password". Store a copy away from the server you are backing up. restic allows several passwords (keys) per repository through restic key add. Kopia's features page says it "allows one password per repository".

Compression

restic compresses with zstandard in repository format version 2, which needs restic 0.14.0 or newer and is now the default for restic init. The level is set per run with --compression (off, fastest, auto, better, max), and auto is the default. A version 1 repository has to be migrated before it gets compression.

Kopia has compression turned off by default. You enable it per policy, with a choice of zstd, s2, pgzip, gzip and deflate variants; its FAQ calls zstd "one of the top algorithms currently". A change only applies to data uploaded afterwards. kopia benchmark compression tests every variant on a sample file. If you forget to set a policy, a Kopia repository stores your data uncompressed. restic compresses from the first backup.

Where the backups can go

The backend lists overlap almost completely:

• restic natively supports a local directory, SFTP, its own REST server, Amazon S3 and S3-compatible storage, OpenStack Swift, Backblaze B2, Azure Blob Storage and Google Cloud Storage, plus anything rclone can reach. For B2, its docs recommend Backblaze's S3-compatible API over the native B2 backend "due to issues with error handling in the current B2 library".
• Kopia supports S3 and S3-compatible storage, Azure, B2, Google Cloud, WebDAV, SFTP, a local directory or NAS, and its own repository server. Its rclone support is marked experimental and needs rclone installed alongside.

Both can protect a backup from a hacked client, but they do it differently. restic's rest-server has an --append-only mode that "allows creation of new backups but prevents deletion and modification of existing backups". Kopia supports S3 Object Lock, and full maintenance can extend the retention dates. Its docs warn that full maintenance must run at least as often as the lock period, or the lock expires. On B2, Kopia needs the S3 API for this.

Retention, scheduling and maintenance

This is where the two tools are most different.

restic keeps each job separate. restic backup writes a snapshot. restic forget applies a policy you pass as flags (--keep-last, --keep-daily, --keep-weekly, --keep-monthly, --keep-yearly, --keep-within and more) and deletes the snapshots that fall outside it. restic prune then removes the data only those snapshots used, or you add --prune to forget. The docs warn that during prune "the repository is locked and backups cannot be completed". They also advise running restic check afterwards; --read-data or --read-data-subset downloads and verifies the pack files as well. Upstream documents no scheduler or daemon, so scheduling is up to you: cron, a systemd timer, or whatever already runs jobs on the box.

Kopia stores all of this as policies in the repository. You set them per path, per user or host, or globally. The global policy starts with a retention schedule of 10 latest, 48 hourly, 7 daily, 4 weekly, 24 monthly and 3 annual snapshots. A policy can also set when snapshots are taken, what to ignore and whether to compress. Maintenance has been automatic since v0.6: quick maintenance about every hour, and full maintenance (garbage collection and compaction) every 24 hours. One user@hostname is the maintenance owner. Full maintenance also runs kopia snapshot verify, which checks that every blob a snapshot needs exists but does not download it. For a real test restore, add --verify-files-percent. Deleted data is not removed at once: its docs say it "may take several hours and/or multiple maintenance cycles".

Many machines, one repository

restic lets several machines back up to one repository at the same time. Backups take shared (non-exclusive) locks, and only operations such as prune need an exclusive one. But every client holds the repository password and the storage credentials. A client that can write can also delete, unless the storage prevents it (the REST server in append-only mode).

Kopia offers a repository server. Clients log in with a per-user username and password and never see the storage credentials. Each username@hostname sees only its own snapshots and policies. Built-in ACLs give clients APPEND access to content, so they can add data but not delete it. The docs note the limit of this: only snapshot and policy manifests are access-controlled, so a user who knows an object's ID can restore it. Remote clients connect over gRPC, which needs TLS. The docs say --insecure does not work for the repository server, and a reverse proxy needs grpc_pass rather than proxy_pass.

GUI, platforms and install

restic has no GUI upstream. Its README lists support for Linux, macOS and Windows, plus FreeBSD and OpenBSD. On Windows, --use-fs-snapshot backs up from a Volume Shadow Copy. restic mount browses snapshots over FUSE on Linux, macOS and FreeBSD only. Most distributions package restic. The official binaries are reproducible builds, update in place with restic self-update, and the restic/restic image covers Docker use. A web UI does exist as a third-party project: Backrest (GPL-3.0) wraps the restic CLI with scheduling and a browser interface, but it is not part of restic.

Kopia ships KopiaUI, a desktop app for Windows, macOS and Linux. The same UI runs as a web app when Kopia is started in server mode. On a VPS, that means one kopia/kopia container gives you a browser dashboard for repositories, policies, snapshots and restores. Kopia publishes APT and RPM repositories, Homebrew, Scoop and winget packages. On Windows, shadow copies are done with a before/after snapshot action. Actions are off by default and must be enabled on the client.

Neither project publishes a RAM figure. Our 512 MB floor for each is an estimate, not a measurement; memory use grows with repository size, and Kopia's FAQ names compression and parallelism as the main causes of high use. We rate both 2 out of 5 to deploy. restic is one binary and a cron line; Kopia is one container, but its repository server needs TLS before remote clients can use it.

Which to choose

Choose restic if you want the backup to be a script you can read: one binary, flags that state the retention policy, and a timer. It compresses by default and allows several passwords per repository. Add rest-server in append-only mode, or a bucket with object lock, if a compromised server must not be able to delete its own backups.

Choose Kopia if you want the tool to schedule snapshots, apply retention and run maintenance itself, with a GUI or web UI for restores. Also choose it if you are backing up several machines into one place and want a repository server that separates users and keeps storage credentials off the clients. Turn compression on in the global policy on day one. Neither is better for everyone; the question is how much of the backup system you want to write yourself.

Choosing between Kopia and restic

Put the other way round, start with Kopia if a web UI, policies and automatic maintenance matter more than anything else. Move to restic if you would rather have fewer moving parts and wire up scheduling yourself.

What to back up, and what these tools are not

These are file-level tools. A database copied live from its data directory can restore inconsistent, so dump it first. restic can snapshot a dump straight from a command with restic backup --stdin-from-command -- <dump command>. Kopia can run the dump from a before-snapshot action. Sync is not backup either: Syncthing's own FAQ says deletions "will be propagated to all your devices". For a Nextcloud server, AIO has BorgBackup built in; see the Nextcloud deploy guide. Both tools are listed with the other self-hosted backup tools on the category page.