rustic: a restic-compatible backup CLI written in Rust

The restic format without the restic release cadence

rustic is a backup tool that writes the restic repository format described in restic's own design document. That single decision defines who it is for. If you already run restic and you are frustrated by how slowly the upstream project moves, rustic is a drop-in candidate: the README states that both projects implement the identical repository format and that you can access every repository with restic as well as with rustic, so a restic binary can verify backups made by rustic and the reverse also holds. The README is explicit about the origin story, describing rustic as created by a heavy restic contributor who was annoyed at the slow speed of change, and as a complete new implementation aiming to be the better restic with respect to features and development speed. That is a candid framing, and it also tells you the risk: a project that optimizes for development speed accepts more churn than one that optimizes for conservatism. The README does not pretend otherwise. It says the best advice is to test both and see which fits your requirements, and it links to a comparison page rather than making the argument itself. Treat that as a signal about where the project's confidence lies: in the format compatibility, not in a claim of superiority. The intended user is someone who already understands restic's model of snapshots, deduplication and repository locks, and who wants the same artifacts with different operational ergonomics.

Deduplication, encryption, and what concurrent access actually means

The mechanism is the restic repository format. Data is deduplicated and encrypted before it lands in the repository, and the README lists local and cloud storage, including cold storage, as valid targets, with cloud storage also usable as a backup source. Snapshots carry metadata and are organized by hostname, backup paths, label and tags. Two claims in the feature list deserve attention because they shape how you run the tool. First, the README states that multiple clients can access a backup repository concurrently using lock-free operations. Second, it states that backups are append-only on the repository by default. Together those two properties mean the common failure mode of concurrent backup tools, a client holding a lock that blocks every other client, is designed away rather than mitigated. The README also states that operations are designed to be safely aborted and efficiently resumed, and that follow-up backups only process changed files while still producing a complete snapshot. That last part matters operationally: an incremental run does not produce an incremental artifact you have to chain, it produces a full snapshot that references existing data. In-place restore is described as modifying only files that changed, which is a different guarantee from restoring into a clean directory. The project is split into three crates: the rustic binary, rustic-core for the core library, and rustic-backend for backend support. If you are embedding backup logic rather than running a CLI, the split is the relevant part of the architecture; if you are not, the binary is the whole story.

Installing rustic and taking a first snapshot

The README lists several install paths. On macOS, Homebrew is the shortest route:

brew install rustic

On Windows, Scoop carries it:

scoop install rustic

If you already have cargo-binstall, the crate installs a prebuilt binary rather than compiling:

cargo binstall rustic-rs

For a container-based setup, the published image is pulled from GitHub Container Registry:

docker pull ghcr.io/rustic-rs/rustic

Building from source is possible but the README warns that this installs the latest development version, which might be unstable:

cargo install --git https://github.com/rustic-rs/rustic.git rustic-rs

For a locked release build from crates.io, the README gives:

cargo install --locked rustic-rs

The README points to the documentation site for getting started rather than walking through repository initialization itself, so the exact first-run commands are not in the repository README. What the README does establish is that every-day commands can be configured through config files, with example config files kept in the config directory of the repository. That is the workflow to plan around: rather than assembling long command lines, you write the command configuration once and invoke it by name. The README does not document rollback of a snapshot, so if rollback semantics matter to you, that is something to confirm against the project's documentation before you rely on it.

Where rustic is the wrong choice

The most honest limitation is stated by the project itself: restic is older and more mature. If your environment requires a backup tool whose behaviour has been stable across years of releases, rustic's stated goal of faster development is the opposite of what you want. A project that ships features quickly will occasionally change behaviour, and the README's own advice to test both tools is an admission that the choice is not obvious. The second limitation is the minimum Rust version. The README states the minimum supported rustc is 1.91.0, and the policy allows that minimum to rise in minor version updates. Concretely, crate 1.0.z would keep requiring Rust 1.20.0 or newer, but crate 1.y for y greater than 0 may require a newer minimum. If you build rustic from source inside a pinned toolchain image, that policy means a minor version bump can break your build even though the patch versions stay compatible. The third limitation is documentation depth. The README describes features at the level of bullets, and the getting started path lives on an external documentation site. For a tool that will hold your backups, that is a real gap: the repository README alone does not tell you how to initialize a repository, how to configure credentials for cloud backends, or what happens when a backup is interrupted mid-upload beyond the statement that operations can be safely aborted and efficiently resumed. None of that makes rustic unsuitable, but it means the evaluation cost is higher than the install cost.

rustic against restic: the same format, different bets

The obvious alternative is restic, and the difference is not the repository format, which is shared, but the development posture. restic is described in rustic's own README as older, more mature, slow with new developments and conservative with changes. rustic is described as a complete new implementation aiming to be the better restic with respect to features and development speed. Those are two coherent strategies, and they produce different day-to-day experiences. With restic you get a tool whose interface changes rarely and whose documentation reflects years of accumulated operational knowledge. With rustic you get a Rust implementation with the feature set listed in the README, including config-file driven command configuration, lock-free concurrent repository access, retention policies and cleaning that the README calls highly customized, and optional features compiled in by default such as jq filtering, Prometheus metrics, OpenTelemetry, a TUI and WebDAV. Because the format is shared, the migration risk is unusually low for a tool swap: you can point rustic at an existing restic repository, and you can point restic at a repository rustic created. That property means the decision is reversible in a way most backup tool migrations are not. The cost of being wrong is lower than usual, which is probably why the README can afford to tell you to test both. What you cannot do is mix the two tools mid-operation and expect coordination beyond what the format guarantees; the README's claim is about repository access, not about running both against the same repository simultaneously.

Licence, maintenance and the cost of upgrading

Licensing is dual and permissive. The README states the project is licensed under either the Apache License, Version 2.0 or the MIT license, at your option, and the Cargo.toml records the same as Apache-2.0 OR MIT. For most users that means no obligation beyond the usual attribution requirements of whichever licence you pick, and the choice is yours rather than the project's. This is not legal advice; if you redistribute rustic inside a product, read the licence text in the repository rather than this summary. On maintenance, the repository is not archived and the last push was on 2026-09-01. Recent releases are v0.11.4 on 2026-08-18, v0.11.3 on 2026-06-03 and v0.11.2 on 2026-04-05, and the Cargo.toml for v0.11.4 pins rust-version to 1.91.0. The upgrade cost that matters is the Rust toolchain, not the crate version, because of the minimum version policy described above. If you install from a package manager or a prebuilt binary, that cost disappears; if you compile from source, budget for toolchain bumps on minor releases. Note also that the Cargo.toml depends on rustic_core and rustic_backend from a git URL rather than a published crates.io version, so a source build pulls library code from the repository rather than from the registry. That is a detail worth knowing if you vendor dependencies or pin them for reproducible builds.

Editorial conclusion

Adopt rustic if you want the restic repository format with a Rust implementation and a config-file driven workflow, and you are willing to track a project whose README itself points you to a comparison page before committing. Do not adopt it if you need a long-stable interface or if your team has no appetite for testing two tools against the same repository. Before rolling it out, verify two things yourself: that your restic version can open a repository rustic created, and that your minimum supported rustc is at least 1.91.0 if you build from source.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. rustic-rs/rustic on GitHub