Kopia: encrypted, deduplicated snapshots you point at your own storage

The problem Kopia solves, and the people it is built for

Most backup products decide two things for you: where the bytes live and who can read them. Kopia inverts that. The README states that you pick the storage provider, provision and pay for it, and then tell Kopia where it is. The repository holds encrypted snapshots, and the keys stay with you. That model suits a specific reader: someone with a NAS, an S3 bucket, a Backblaze B2 account or a spare server who wants versioned copies of selected directories without handing a vendor a readable copy of their files.

The scope is deliberately narrow. The README says Kopia does not image your whole machine; it backs up and restores any files and directories you decide matter. That is a different product category from disk imaging tools, and it changes what recovery looks like. You get files back, not a bootable system. For a home directory, a source tree, a photo library or a document folder, that is usually the right unit. For a machine you need running again in twenty minutes from bare metal, it is not.

Kopia ships both a CLI and a GUI, which the README frames as serving advanced and regular users from the same codebase. The CLI is the reference surface: snapshots, policies, repository maintenance and verification are all exposed there. The GUI is a wrapper over the same repository, useful for browsing snapshots and restoring individual files.

How snapshots, deduplication and encryption fit together

A Kopia repository is the unit of storage. You create it against a backend (S3-compatible object storage, Azure Blob, Backblaze B2, Google Cloud Storage, WebDAV, SFTP, a local path, or an Rclone remote), and every snapshot from every connected machine goes into it. The README notes that multiple machines can back up to the same storage location, which is where deduplication starts to pay: identical file content across machines is stored once.

Deduplication works at the content level. Kopia splits file data into chunks, hashes them, and stores each unique chunk once, so a second snapshot of a mostly unchanged directory writes only the new chunks. The repository layout reflects this: the top-level entries include repo/, snapshot/, fs/ and cli/, with the chunking and repository logic living under repo/ and filesystem traversal under fs/. The go.mod file lists github.com/chmduquesne/rollinghash, which is the rolling-hash dependency you would expect for content-defined chunking, and github.com/klauspost/compress and github.com/klauspost/pgzip for the compression side.

Encryption is client-side and end-to-end per the README's feature list. The repository password you set at creation time is what unlocks the data; the storage backend sees ciphertext. That is the whole security argument, and it is also the whole risk: lose the password and the snapshots are unreadable by anyone, including the project maintainers. Error correction is listed as a feature as well, and the dependency list includes github.com/klauspost/reedsolomon, which is the erasure-coding library that would back such a claim. The README does not spell out how error correction is configured, so treat that as something to confirm in the documentation rather than assume is on by default.

Installing Kopia and taking a first snapshot

The README points to the installation page at kopia.io/docs/installation/ for downloads, and the Getting Started Guide at kopia.io/docs/getting-started/ for a walkthrough. If you would rather build from source, the Makefile provides an install target that runs go install against github.com/kopia/kopia:

make install

There is also a variant that skips the embedded HTML UI, which produces a smaller binary with no GUI assets:

make install-noui

The Makefile defines KOPIA_BUILD_TAGS as empty by default and the noui target sets it to nohtmlui, so the difference is a single build tag. Building requires the Go toolchain version declared in go.mod, which is Go 1.26.0 with a toolchain line of go1.26.8.

Once the binary is on your PATH, the README directs you to the Getting Started Guide for the step-by-step walkthrough of creating a repository and taking a snapshot. That guide is where the exact command syntax lives; the README itself gives no command examples beyond the build targets above. What the README does establish is the shape of the workflow: you choose one of the supported storage locations, tell Kopia where it is, and Kopia writes encrypted, compressed snapshots into it. The repository password is set at creation time, and the README documents no recovery path if it is lost, so store it somewhere you can actually retrieve it before you point Kopia at data you care about.

Where Kopia is the wrong tool

The clearest boundary is stated by the project itself: no machine imaging. If your recovery plan is a bare-metal restore of an operating system, Kopia does not do that, and no amount of snapshot configuration will turn it into an imaging tool. You would back up the data and reinstall the system separately.

The second boundary is operational. A Kopia repository is a living thing that needs maintenance. The search data around this project includes people asking what Kopia maintenance is, which suggests the concept is not obvious from the surface. Repository maintenance, snapshot verification and password handling are all things you own. If nobody runs maintenance, the repository accumulates pack blobs that are no longer referenced, and if nobody tests a restore, you find out whether the snapshots are good at the worst possible moment. That is true of every backup tool, but Kopia makes it explicit by giving you the repository rather than a managed service.

The third boundary is the Rclone path. The README describes Rclone support as experimental, notes that not all cloud storage products supported by Rclone have been tested with Kopia, and says Kopia has been tested with Dropbox, OneDrive and Google Drive through Rclone. That is a narrow tested set. If your storage only exists through Rclone and is not one of those three, you are outside what the project claims to have validated.

Finally, cost. Kopia itself is free, but the README is direct that you must provision and pay for the storage provider. The search question about monthly cost has no answer inside the project, because the project does not charge anything.

Restic and Borg: what actually differs

Restic is the closest comparison and the one people search for most often. Both are Go tools that write encrypted, deduplicated snapshots to backends you own, and both ship a single CLI binary. The practical differences show up in the surfaces around the core: Kopia ships a GUI alongside the CLI, and it offers a repository server mode plus a policy system that lets different sources share one repository with different retention rules. Restic's model is a flat repository with snapshots and forget/prune policies applied per invocation. If you want a graphical browser or a central repository that many machines write into, Kopia's shape fits better. If you want the smallest possible surface and a single command to reason about, Restic is leaner.

Borg is a different animal. It is Python, it is primarily oriented around a repository accessed over SSH, and it has a long history of append-only mode for repositories on untrusted hosts. Borg's deduplication and encryption goals overlap with Kopia's, but the deployment model does not: Borg expects you to reach a repository, typically on a server you control, while Kopia treats the backend as dumb object storage and does the work on the client. If your storage is S3 or B2 rather than an SSH host, that difference decides the choice. The README's list of supported backends is the concrete artifact here: S3 and S3-compatible, Azure Blob, B2, GCS, WebDAV, SFTP, Rclone, local, or a Kopia Repository Server.

Licence, build cost and what upgrading involves

Kopia is licensed under the Apache License, Version 2.0, with the full text in the LICENSE file. For most users that is a permissive licence with no obligation to publish modifications, and the README points security disclosures at [email protected] rather than a public issue tracker. None of this is legal advice; read the licence yourself if you plan to redistribute a modified build.

The dependency set is large. go.mod pulls in cloud SDKs for Google, Azure and MinIO, a FUSE binding (github.com/hanwen/go-fuse/v2) for mounting snapshots, chromedp for browser automation in tests, Prometheus client libraries, and an embedded HTML UI package (github.com/kopia/htmluibuild) that is versioned by date. That last one matters for upgrades: the GUI is delivered as a prebuilt asset referenced by a pseudo-version, so a source build gets whatever UI build that pseudo-version pins.

The build itself is a plain Go build. The Makefile's install target passes -trimpath and strips symbols, and injects BuildVersion, BuildInfo and BuildGitHubRepo via ldflags, which is why a released binary can report its exact commit. The last push to the default branch was on 2026-06-16, which is also the date of the v0.23.1 release, so the release and the branch tip line up. The project is not archived. Upgrade cost for a CLI user is close to zero: replace the binary. The real cost is repository compatibility, which the release notes for any version you jump across are the place to check, and the README does not document rollback, so plan upgrades as one-way unless you have verified otherwise.

Editorial conclusion

Adopt Kopia if you want file-level snapshots that you encrypt yourself and store on storage you already pay for, and you are comfortable running a repository and a maintenance schedule. Do not adopt it if you need bare-metal image restore, or if you want a vendor to hold both the storage and the keys. Before trusting it with data, verify three things on your own machine: that you can read the repository password back from wherever you stored it, that snapshot verification completes without errors, and that a restore of a single file from an old snapshot returns the bytes you expect.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes