Kopia

What is Kopia?

Kopia does encrypted, deduplicated snapshot backups and adds something most command-line tools lack: a real policy engine for schedules and retention, plus desktop and web interfaces.

Best for

Snapshot backups with per-source policies

Why choose Kopia

Kopia sits between the command-line purists and the appliance-style tools, and the policy engine is the reason to pick it. Instead of one global configuration, you define policies per source directory: how often to back up, how long to keep daily, weekly and monthly snapshots, what to exclude, and where the snapshot goes. That granularity matters once you back up more than one thing, because the retention that suits a database is wrong for a media library. It writes encrypted, deduplicated snapshots to many backends, and it ships with desktop and web interfaces rather than requiring you to script everything. It also supports repository servers, so several machines can share one destination cleanly.

Replaces

• Backblaze
• Arq Backup
• Duplicati

Key features

• Encrypted deduplicated snapshots
• Per-source retention and scheduling policies
• CLI, web UI and desktop app
• Repository server mode for central storage

What to watch out for

The initial setup asks you to make choices — repository format, password, backend — with long-term consequences, and the password risk is the same as any encrypted backup tool, where losing it means losing the data. The feature set has grown quickly across versions, so documentation and third-party guides frequently describe an older interface. Running the desktop client and a server for multiple machines is more moving parts than a single-binary tool, and the backup policies need a deliberate design rather than defaults, or you end up with either too much retention or too little. Performance on very large repositories is good but not immune to the usual small-file and cold-cache costs.

How to deploy

• Install CLI or use the Docker server
• Connect a repository and set policies
• Verify with a restore early

Getting started

Create the repository and store the password immediately somewhere durable and separate. Design policies per source before the first run: retention, schedule, and exclusions — especially exclusions, since backing up caches and temporary directories wastes space and time. Start with one source and verify a snapshot completes and appears, then add the rest. If more than one machine is involved, set up the repository server rather than pointing several clients at the same directory. Schedule a verification pass and a restore test, because the only backup that counts is one you have successfully restored from.

Typical setup

A repository created up front with the password stored durably and separately, and policies defined per source rather than globally — separate retention for the database directory, the documents directory and anything large and reproducible. Exclusions for caches and temporary paths are written before the first run. Where several machines share a destination, a repository server is used rather than several clients pointed at the same directory. Verification and a periodic restore test are scheduled, and at least one snapshot has been browsed and restored from to confirm the policies produce usable results.

Who should look elsewhere

If you have one directory on one machine, the policy engine is overkill and a simpler tool will do the job with less configuration. Avoid it if you want zero decisions at setup, because it explicitly asks you to define policies and will not choose sensible ones for you. And if you are not going to store the repository password safely, the encryption is a liability rather than a feature.

Project health

• GitHub stars: 14,233
• Last code push: 2026-10-01
• Open issues: 895
• Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.